# Firmen-Norm



## Lord Helmchen (23 Juli 2014)

Seid Gegrüßt,

 Ihr Programmierer und Leidensgenossen. Sei geraumer Zeit treibt eine neuer Geist in meiner Firma sein Unwesen. Es wird gemunkelt, „Firmen-Norm“ soll er sich nennen!

 Er verlangt mit den traditionellen Arbeitsweisen zu brechen. In S7 sollen weder S5-Timer noch Merker Verwendung finden. Auch Instanz-Datenbausteine sollen rationiert werden. Der Übersicht wegen, soll alles in „Multi-Instanzen“ verpackt werden.   
 Auch verlangt der „neue Geist“, dass Bausteine zur Wiederverwertung entwickelt werden, an denen später keine Änderungen mehr vorgenommen werden dürfen.

 Wie geht es in Euren Landen?
 Geht jener Spuk von alleine wieder vorüber?
 Habt Ihr solch neue Geister schon vertrieben?

 Eure Lordschaft


----------



## SoftMachine (23 Juli 2014)

.
Na, bis sich der Geist dann so richtig "manifestiert" hat, wird noch so einiges an Zeit und Geld vergehen.

Wenn ihr nicht gerade eindeutige Vorgaben habt, ist da einiges an Entwicklung zu treiben, um alle
Eventualitäten für die Zukunft zu berücksichtigen.

Falls du es bist, der diesen "Geist" realisieren soll, hast du einen Full-Time-Job (und den Stress) auf Jahre hinaus.


Also, erstmal abwarten


----------



## rostiger Nagel (23 Juli 2014)

Hört sich doch gut an, mit den neuen Geist. Der Gedanke und
die Richtung der Ausgestaltung ist der richtige Weg. 
Warum hast du den Angst davor, bist du der Firmenschmierfing?


----------



## Aventinus (23 Juli 2014)

Ich finde die Ansätze auch gut...


----------



## Blockmove (23 Juli 2014)

So schlecht ist das nicht


----------



## AUDSUPERUSER (23 Juli 2014)

Lord Helmchen schrieb:


> Seid Gegrüßt,
> 
> Ihr Programmierer und Leidensgenossen. Sei geraumer Zeit treibt eine neuer Geist in meiner Firma sein Unwesen. Es wird gemunkelt, „Firmen-Norm“ soll er sich nennen!
> 
> ...



Die Umstellung tut etwas weh, aber du wirst es lieben.


----------



## bike (23 Juli 2014)

Wenn eure Firma so groß ist, dass ihr eure Lieferanten in so ein Korsett zwängen könnt, gut.
Aber das haben die Autobastler nicht konsequent geschafft, daher sehe ich es relativ relaxt.
Es wird nicht so heiß gegessen wie es jemand kocht.


bike


----------



## MrSpexx (23 Juli 2014)

Super Sache. :s1:

Hört sich an wie wenn der Programierleitfaden von Siemens umgesetzt wird.
https://www.google.de/url?url=https...QQFjAA&usg=AFQjCNFKGxB6E8LBzar_IT0eluosiBU5Eg


----------



## bike (23 Juli 2014)

Es gab schon einmal vor langen Jahre einmal der Versuch von Big$ mit Transline 2000.
Da fällt mir immer wieder ein, was das Gegenteil von "gut gemacht" ist.
Das ist nämlich nicht schlecht, sondern "gut gemeint".


bike


----------



## AUDSUPERUSER (23 Juli 2014)

bike schrieb:


> Es gab schon einmal vor langen Jahre einmal der Versuch von Big$ mit Transline 2000.
> Da fällt mir immer wieder ein, was das Gegenteil von "gut gemacht" ist.
> Das ist nämlich nicht schlecht, sondern "gut gemeint".
> 
> ...



Trotzdem ist es in der Automobilindustrie gesetzt.

Also bestimmte Körperteile zusammen kneifen und durch


----------



## bike (23 Juli 2014)

Wirklich, gesetzt?
Also ich habe in Sindelfingen, Wolfsburg, Lyon, Turin und Paris und andere Ecken der Welt bei den Autobastlern Anlagen und Maschinen installiert, wo TL gewünscht aber nicht eingesetzt wurde.
Vorgaben an sich sind gut und sinnvoll. 
Wir haben auch unsere Vorgaben, so dass jeder mit dem Programm des anderen etwas anfangen und weiter programmieren kann.


bike


----------



## Lord Helmchen (24 Juli 2014)

SoftMachine schrieb:


> Also, erstmal abwarten


Wie soll ich auf der Arbeit etwas abwarten?



rostiger Nagel schrieb:


> Warum hast du den Angst davor, bist du der Firmenschmierfing?


Angst nicht, aber muss das vor der Einführung von TIA noch sein?



AUDSUPERUSER schrieb:


> Die Umstellung tut etwas weh, aber du wirst es lieben.


Ich liebe meine Arbeit doch sowieso. Man sollte das aber nicht gleich übertreiben!


----------



## rostiger Nagel (24 Juli 2014)

Lord Helmchen schrieb:


> Wie soll ich auf der Arbeit etwas abwarten?
> 
> 
> Angst nicht, aber muss das vor der Einführung von TIA noch sein?
> ...



da ziettiere ich mal ein Kollegen



vierlagig schrieb:


> Kann man sich effektiv(!) gegen die Anforderung eines Vorgesetzten(!) wehren? - Nein.
> Welche Chancen hat man in der aktuellen Situation? - Kröte schlucken und Potentiale für die eigene Arbeit erschließen.
> Welche Chancen hat man in der Zukunft? - selber Vorgesetzter werden, dann kann man die Anforderungen deligieren...


----------



## lilli (24 Juli 2014)

Hallo Lord Helmchen,

deine "Neue Hausnorm" hört sich doch wirklich nicht so schlimm an.
Vor einiger Zeit hatte ich mal eine Bekanntschaft mit ganz alten Geistern!

Mein Vorgesetzter ist mit der Anweisung zu mir gekommen, keine IEC- Timer mehr einzusetzen.
Ebenso sollte ich die ganz schlimmen Sachen, wie "Multiinstanzen" tunlichst unterlassen - das ist Teufelszeug!

Zum Glück hat er nicht bemerkt, dass es außer dem altmodischen Taktmerkerbyte überhaupt keine Merker mehr im Programm gab. Sonnst wäre ich vermutlich exorziert worden. 

Eine Sachliche Diskussion habe ich angestrebt, musste mich aber geschlagen geben.
Gegen Argumente wie "Das haben wir doch immer so gemacht!" und "Was früher Gut war, ist heute nicht Schlecht"  bin ich einfach nicht angekommen.

Inzwischen ist er in Rente und sein Nachfolger ist etwas aufgeschlossener...

Liebe Grüße
Lilli


----------



## Markus (24 Juli 2014)

Ihr seid auf dem richtigen Weg!

Die Stichworte die du genannt hast lassen auf zwei wichtige Eigenschaften des Ergebnisses schließen.

1. Skalierbarkeit - das ist mit Merkern und S5-Timern nicht möglich
2. Wiederverwendung von getestetem und bewährtem Code.

Um das umzusetzen brauchst du weniger den Superprogrammierer der eine Gleitpunktzahl im Hirn in ihr Bitmuster zerlegen kann, vielmehr ist hier jemand nützlich der etwas von Strukturen versteht und vielleicht auch schon mal was von Objektorientiertem Programmieren gehört hat. Es schadet sicher nicht hier auch mal mit ein paar klassischen Hochsprachenentwicklern zu reden und ein paar Inspirationen zu bekommen - aber um Gottes Willen nicht alles so machen wie die es sagen!!! 

Wir haben seit Jahren einen ähnlichen Standard, und ich durfte in den letzten Jahren immer mal wieder Standards von Firmen kennen lernen die völlig anders sind - aber grundsätzlich der selben Philosophie folgen.
Ich fand mich drin recht schnell zurecht, und man braucht keine 5 Minuten um die Stellen zu erkennen an denen ein "Merker Programmierer" gebastelt hat der sich gar nicht erst bemüht hat den Idee des Entwicklers zu verstehen...

Eine der wichtigsten Zutaten für so einen Standard sind Datentypen bzw. UDTs!
Ein UDT der eine Achse mit all ihren Eigenschaften bzw. Variablen beschreibt, einer der Aktoren grundsätzlich beschreibt,...

Wenn du es konsequent durchziehst dann wirst du viel Freude damit haben.
Am Anfang ist er hart, bis du die ersten "bewährten" Standartbausteine in der Praxis erprobt hast auf die du dich zukünftig verlassen kannst.
In dieser Phase musst du konsequent sein, du muss um jeden Preis die Struktur halten - auf keinen Fall "Quick and Dirty" tolerieren!

Hat man erst mal so was, dann kann man ganz schnell darauf aufsetzen, indem man sich z.B. das ganze Grundgerüst mit dem Fehleranfälligen "Copy&Paste" von einer Excel Tabelle mit ein bisschen VBA Fehlerfrei generieren lässt.
Der Programmierer muss sich dann nur noch um die Logik/Schrittketten oder ggf. Regelparameter kümmern.

Wenn du es nicht konsequent durchziehst und dich auf Kompromisse einlässt, dann hast du hinterher weder das eine noch das andere und alles wird schlimmer als es bisher jemals war...
Ach - und vergiss erst mal deinen Laptop (Egal ob TIA oder Step7 oder sonst was) - fang mit einem Blatt Papier an!


----------



## Markus (24 Juli 2014)

Noch was:
Ein guter Standard darf dich keineswegs einschränken.

Angenommen du hast einen UDT in dem alles drin ist was ein Aktor braucht (Tippen+, Tippen-, Sollwert-1,Status,...)
Dann wirst du dir für deine wichtigen Aktoren Standard-FB machen an die du einfach die komplette Struktur parametrierst, der FB holst sich dann dort was er braucht.

Es wird dir aber sicher auch mal passieren das irgend ein Exot oder was Spezielles kommt, dann erlaubt dir ein flexibler Standard immer noch Zugriffe wie z.B.:

U DB_mit_allen_Aktor_UDT-drin.Aktoren_Anlage_Teil_0815.Aktor_UDT_von_Exotischem_Spezial_Weltraumgreifer.Tippen_PLUS
= Ausgang_Speziellen_Spezial_Weltraumgreifer_in_Spezialrichtung_fahren

U Eingang_Spezialendlage_von_Welraumsupergreifer_Quantenzustand_erreicht
U DB_mit_allen_Aktor_UDT-drin.Aktoren_Anlage_Teil_0815.Aktor_UDT_von_Exotischem_Spezial_Weltraumgreifer.Endlage_PLUS
SPBN STA1
L 17 // 17 = Aktor in ?? Position
T DB_mit_allen_Aktor_UDT-drin.Aktoren_Anlage_Teil_0815.Aktor_UDT_von_Exotischem_Spezial_Weltraumgreifer.Status
STA1: nop 0

bei deinen Standardsachen kannst dir den Aufwand natürlich sparen, da verschaltest du nicht jedes Signal einzeln sondern setzt einmal die gesamte Struktur (UDT) an den FB.



=


----------



## WinniePooh (24 Juli 2014)

oha.... ja sowas kann lange dauern.
Ich bin an meiner Strukturierung schon seit halben Jahr dran. Alleine!

Da wünsche ich dir besonders viel Spaß, wenn es mit Siemens gemacht wird.
Kriegst viele spannende Aufgaben von Siemens automatisch gestellt, wie
Bereichsgrenzen.


----------



## Lipperlandstern (24 Juli 2014)

keine Merker, keine S5-Timer , Multiinstanzen ???? .... Ich bin raus ....  wie will man da auf der Baustelle "mal eben" was basteln ?


----------



## Blockmove (24 Juli 2014)

Lipperlandstern schrieb:


> keine Merker, keine S5-Timer , Multiinstanzen ???? .... Ich bin raus ....  wie will man da auf der Baustelle "mal eben" was basteln ?



Tja, erst basteln und dann in Ruhe bereinigen


----------



## Markus (24 Juli 2014)

Lipperlandstern schrieb:


> keine Merker, keine S5-Timer , Multiinstanzen ???? .... Ich bin raus ....  wie will man da auf der Baustelle "mal eben" was basteln ?



Ein guter Standard schließt solche Sachen für Sonderfunktionen ja auch nicht zwingend aus.
Im Gegenteil, gerade im Sondermaschinen oder Anlagenbau darf ein Standard auf keinen Fall einschränken sondern muss die Arbeit erleichtern.
Aber es sollte halt nicht die Regel sein - bzw. die Grundstruktur einer Software muss einfach, skalierbar, instanzierbar und effizient bzw. automatisiert sein.

Ein Standard der nur aus "Blackboxen" besteht ist hier Selbstmord.
Eine Lösung z.B. mit UDTs die mir über den Standard hinaus jederzeit an jeder Stelle Zugriff auf alle Signale und Zustände erlaubt kann hier sehr viel Freude machen.
Dann sind die meisten Merker gar nicht mehr nötig, da es fast alles in den Strukturen vom Standard schon gibt.


----------



## rostiger Nagel (24 Juli 2014)

Lipperlandstern schrieb:


> keine Merker, keine S5-Timer , Multiinstanzen ???? .... Ich bin raus ....  wie will man da auf der Baustelle "mal eben" was basteln ?



Axel mal ehrlich, du kennst doch nur S5 Timer und Merkergräber.


----------



## MrSpexx (24 Juli 2014)

Zu den Bausteinen fällt mir ein: Jedes Ding an seinem Ort, spart manch Zeit und böses Wort.

Zum Beispiel


Steuerspannung 
Luft 
Schrittkettenaufrufe 
Fehlerauswertung 
Parameter 
Betriebsart 
Buttons 
Motor Firma XY 
Motor Firma abc 
Motor Sollwert 
Zylinder 
Ventil
    und dazu noch eine gute Strukkturierung nach Anlagenteile mit Schnittstellen zwischen den einzelnen Programmteilen.


----------



## Lord Helmchen (24 Juli 2014)

Seid Gegrüßt,

 auch wenn Ihr mir den erhofften Zuspruch schuldig geblieben seid.

 Kann es sein, dass niemand mehr S5-Timer verwendet?
Sehr Ihr Merker als alte Relikte an?
Oder sind die Erfahrenen Programmierer einfach viel weniger im Forum unterwegs?

 Habt Ihr keine Angst, dass Ihr euch durch zu viel Automatismus selbst wegrationalisiert?

 Eine gute Zeit
 Eure Lordschaft


----------



## rostiger Nagel (24 Juli 2014)

Lord Helmchen schrieb:


> Kann es sein, dass niemand mehr S5-Timer verwendet?



Genau, Sie heißen ja S5 und diese Steuerungen setzen die meisten schon lange nicht mehr ein.



Lord Helmchen schrieb:


> Sehr Ihr Merker als alte Relikte an?



Ja definitiv, für mich gibt es da noch sehr wenig einsatzzwecke,
vielleicht als Taktmmerkerbyte.

Aber sagt jetzt nicht du nutzt noch Schmiermerker?


----------



## Lipperlandstern (24 Juli 2014)

Lord Helmchen schrieb:


> Seid Gegrüßt,
> 
> auch wenn Ihr mir den erhofften Zuspruch schuldig geblieben seid.
> 
> ...




Ich nutze S5-Timer und auch Merker ... und ja Helmut .... Ich hab sogar noch Schmiermerker in meinen Programmen


----------



## rostiger Nagel (24 Juli 2014)

Lipperlandstern schrieb:


> Ich nutze S5-Timer und auch Merker ... und ja Helmut .... Ich hab sogar noch Schmiermerker in meinen Programmen



Du bist ja auch ein Lipper und sparst sogar an Weiterendwicklung .


----------



## SoftMachine (24 Juli 2014)

Lord Helmchen schrieb:


> Geht jener Spuk von alleine wieder vorüber?     Habt Ihr solch neue Geister schon vertrieben?       Eure Lordschaft





Lord Helmchen schrieb:


> ... aber muss das vor der Einführung von TIA noch sein?     Ich liebe meine Arbeit doch sowieso.  Man sollte das aber nicht gleich übertreiben!


 


Lord Helmchen schrieb:


> Seid Gegrüßt,
> 
> auch wenn Ihr mir den erhofften Zuspruch schuldig geblieben seid.
> 
> ...




TIA ist bereits präsent und Zuspruch hast du hier auch erhalten, auch von erfahrenen Programmierern.

Mal abgesehen von deinem Avatar aus den 80er-Jahren: 
Kann es sein, dass du noch auf einem C64 programmiert hast ?


----------



## winnman (24 Juli 2014)

Schmiermerker -> NEIN!!!!

aber was spricht gegen Merker?

bin auch in Schneider, . . . unterwegs, Merker wird es auch in 100 Jahren noch geben, müssen nur Sinnvoll verwendet werden.

S5Timer verwende ich auch noch (warum auch nicht?) aber werden immer weniger 

Die Umstellung solcher Systematik wird nicht von heute auf morgen erfolgen.

Man muss auch noch an übermorgen denken  (ist zwar nicht mein direktes Ansinnen, aber wenn mal was drinnen bleibt, kann das auch in Zukunft nicht schaden jemand mit Wissen zu erfordern.

Was ich unbedingt fordere sind sauber kommentierte Programme, da fordere ich auch mich selber immer wider heraus!
Stolpere schon mal auf selber geänderte Teile die nach 2 Jahren offensichtlich immer noch noch zu wenig kommentiert sind. -> mehr Kommentar kann nicht schaden. 
Eein S5Timer  stört da eher weniger.

Wenn ich über Schmiermerker von Vorgängern stoße, versuche ich die so nach und nach zu entsorgen (ist aber langwierig und aufwändig, wird wohl noch die nächsten 30 Jahre immer noch irgendwo so was geben)


----------



## Blockmove (25 Juli 2014)

Ich verwende Merker in meinen Programmen.
Genau 10 Stück:
7 Taktmerker, feste 0, feste 1 und SPS-Anlauf.

Beim Einsatz von F-Steuerungen kommen gelegentlich noch ein paar hinzu.

Gruß
Dieter


----------



## Aventinus (25 Juli 2014)

Wenn ich bei der Entwicklung von TIA gefragt worden wäre gäbs da keine S5-Timer, keine Zähler keine Merker und vor allem keine Bausteinnummern.

Und bevor die Frage kommt, ich programmiere fast ausschließlich S7, ab und an noch S5 und hab einen kurzen Ausflug zu PCWorX hinter mir.


----------



## AUDSUPERUSER (25 Juli 2014)

Da ist doch jeder schon mal auf die Schnautze gefallen:

Mehr S5-Timer verwendet, oder gebraucht als die Steuerung hatte.
Die Timernummern werden auch nicht mit der Hardwarekonfig abgeglichen --> Ich kann im Programm den Timer 266 verwenden, auch wenn die Steuerung nur 254 hat.
Das Erwachen kommt dann beim Download.


Deshalb nur Ton und Tof (Bei Rockwell RS-Logix 5000 gibt es meines Wissens nix anderes)

Merker haben aber Vorteile:

MB0 = "TaktMerkerByte"
M0.0 = "TaktMerker_01"
usw.


----------



## Larry Laffer (25 Juli 2014)

Lord Helmchen schrieb:


> Kann es sein, dass niemand mehr S5-Timer verwendet?
> Sehr Ihr Merker als alte Relikte an?



Hallo,
ich habe auch noch Merker und S5-Timer - aber nicht so, wie du denkst ...
Meine Bausteine sind wahrscheinlich ähnlich strukturiert, wie es dein "böser Geist" haben will. Ein FB kapselt ein Aggregat und erhält alle seine externen Informationen über die Baustein-Schnittstelle. 
Manchmal müssen nun aber zwischen 2 Aggregaten Informationen ausgetauscht werden. Dafür verwende ich dann die Merker oder auch gerne (wenn sinnvoll machbar) die TEMP-Deklarationen im aufrufenden Baustein.
Manchmal müssen Eingänge (Ini's etc.) ein bißchen verzögert werden. Dafür kommt dann im aufrufenden Baustein ein S5-Timer zum Einsatz, der dann an dem Eingang hängt und aus ihm im Prinzip einen Merker bildet, den dann der Aggregate-FB wieder aufnimmt.
Alles andere bleibt in dem FB und wird, wenn möglich, dort auch in der Instanz mit eingebunden - das läßt sich eigentlich sehr schön umsetzen.
Also keine Panik ... 8)

Gruß
Larry


----------



## Aventinus (25 Juli 2014)

AUDSUPERUSER schrieb:


> Merker haben aber Vorteile:
> 
> MB0 = "TaktMerkerByte"
> M0.0 = "TaktMerker_01"
> usw.



Und genau da bekomm ich Brechreiz. Das wär mir als Struktur lieber, da kann man die ganze Sturkur und jedes Einzelne Element adressieren und bleibt immer konsistent. Wenn bei deiner Vorgehensweise jemand in der Symboltabelle zwar die Aressen für die einzelnen Merker verschiebt aber nicht merkt dass das Byte komplett ein anderes Symbol hat und dies nicht umadressiert geht´s in die Hose....


----------



## bike (25 Juli 2014)

Aventinus schrieb:


> Und genau da bekomm ich Brechreiz. Das wär mir als Struktur lieber, da kann man die ganze Sturkur und jedes Einzelne Element adressieren und bleibt immer konsistent. Wenn bei deiner Vorgehensweise jemand in der Symboltabelle zwar die Aressen für die einzelnen Merker verschiebt aber nicht merkt dass das Byte komplett ein anderes Symbol hat und dies nicht umadressiert geht´s in die Hose....



Gibt es wirklich einen Grund diesen Bereich zu ändern?
Warum nicht IMMER die selben Takt und Taktflanken verwenden?
Ebenso wie die VKE und IBN Merker?

Dann kann man blind tippen, da jeder die Möglichkeit hat symbolisch oder absolut die Adresse eingeben.
Auch so etwas gehört zur Standardisierung von Hard- und Software


bike


----------



## Wutbürger (25 Juli 2014)

lilli schrieb:


> Eine Sachliche Diskussion habe ich angestrebt, musste mich aber geschlagen geben.
> Gegen Argumente wie "Das haben wir doch immer so gemacht!" und "Was früher Gut war, ist heute nicht Schlecht" bin ich einfach nicht angekommen.


 Hallo Lord Helmchen, sind diese Argumente von dir?



lilli schrieb:


> Inzwischen ist er in Rente und sein Nachfolger ist etwas aufgeschlossener...


 Das ist sehr wahrscheinlich als Wink mit dem Zaunpfahl zu verstehen! 



Lord Helmchen schrieb:


> Oder sind die Erfahrenen Programmierer einfach viel weniger im Forum unterwegs?


 Deine erfahrenen Programmierer haben keine Zeit für ein Forum, weil sie das Rad täglich neu erfinden müssen.

 Der Wutbürger


----------



## Aventinus (25 Juli 2014)

bike schrieb:


> Gibt es wirklich einen Grund diesen Bereich zu ändern?
> Warum nicht IMMER die selben Takt und Taktflanken verwenden?
> Ebenso wie die VKE und IBN Merker?
> 
> ...



Mir ging es weniger um Taktmerker. Ich hab das aber auch schon bei Schrittmerkern gesehen. Die Schritte wurden über einen Merkerdoppelwortzugriff gelöscht (Initialisieren) und ansonsten bitweise angesprochen. Nach einer Erweiterung suchte ein Kollege immer wieder sporadisch auftretende Fehler, die nach einer Störung auftraten weil das Doppelwort nicht mehr alle Schrittmerker umfasst hat.

Und sowas kann mit einer Struktur nicht passieren.


----------



## zotos (25 Juli 2014)

bike schrieb:


> Gibt es wirklich einen Grund diesen Bereich zu ändern?
> Warum nicht IMMER die selben Takt und Taktflanken verwenden?
> Ebenso wie die VKE und IBN Merker?
> ...



Auch das ist ja eine Art Firmen-Norm. Es hat halt mal einer angefangen und die Nachfolger mussten sich anpassen. Bei Taktmerkern und VKE0 und VKE1 auch bei dem ein oder anderen Standard Merker hat das ja ganz gut funktioniert, bei Flankenmerkern leidet die Kopierbarkeit deutlich. Auch Timer behindern die Wiederverwendbarkeit, da sind FBs deutlich angenehmer.


----------



## Ralle (25 Juli 2014)

Lord Helmchen schrieb:


> Seid Gegrüßt,
> 
> auch wenn Ihr mir den erhofften Zuspruch schuldig geblieben seid.
> 
> ...



Ich nutze auch noch Timer und Merker, allerdings sind die in unseren Programmen aufgeteilt und werden nur für bestimmte Zwecke eingesetzt. (Merker für Schnittstellen zu anderen Stationen z.Bsp.)
Wenn ich FB programmiere, dann natürlich ohne Merker und mit IEC-Timern, also im Instanz-DB. 
Alles dort, wo es hingehört. 
Allerdings muß ich dazusagen, unser Programmiersystem ist inzwischen über 15 Jahre alt und von mehreren Programmierern stetig weiterentwickelt worden. Was das heißt ist klar, wir müssen das ganz sicher mal wieder neu aufsetzen, denn zu viele Dinge darin sind "gewachsen"!


----------



## bike (25 Juli 2014)

zotos schrieb:


> Auch das ist ja eine Art Firmen-Norm. Es hat halt mal einer angefangen und die Nachfolger mussten sich anpassen. Bei Taktmerkern und VKE0 und VKE1 auch bei dem ein oder anderen Standard Merker hat das ja ganz gut funktioniert, bei Flankenmerkern leidet die Kopierbarkeit deutlich. Auch Timer behindern die Wiederverwendbarkeit, da sind FBs deutlich angenehmer.



Es ging mir darum, warum an solchen Grundlagen von Projekt zu Projekt gedreht werden muss.
Wenn eine Funktion in einem FB ausprogrammiert wurde, dann werden da IEC verwendet.
Doch bei der Übergeordneten bzw der Aufruffunktion sind S5 Timer und Merker nach meiner Meinung die bessere Lösung.
Es ist einfacher bei laufender Maschine eine S5 Timer oder einen Merker zu verwenden, als übersetzen und dann eine neuen IDB nachzuschieben.

Daher jeder nach seiner Art.(bevor ein Glaubenskrieg in voller Größe aufbricht ;-) )


bike


----------



## Lord Helmchen (25 Juli 2014)

Seid Gegrüßt,

 bei dem Gegenwind hier, sollte ich wohl doch meine Richtung hinterfragen. 

 Was mir halt wirklich widerstrebt ist, dass diese Änderungen angegangen werden sollen, bevor wir auf TIA umstellen.  
 Sollte es ansprechende Neuerungen in TIA geben, so können diese auf den neuen Standard von Klassik, trotz aller Bemühungen, doch nicht angewandt werden.

 Dann haben wir nicht ein einheitliches System, sondern drei verschiedene:
 - Klassik alt
 - Klassik neu
 - TIA

 Eure Lordschaft


----------



## rostiger Nagel (25 Juli 2014)

Aber der Gedanke ist gut vor Einführung von TIA die
die Alte Arbeitsweise zu hinterfragen und das auf einen
System was man beherrscht, die classic Welt. 
Außerdem wird wahrscheinlich TIA sehr schnell auf euch
zukommen, weil im Oktober sieht es mit den Panels schlecht
aus. Also bleibt euch doch garnicht soviel Zeit eine Firmen 
Norm zu erarbeiten. 

Was ich mal von dir hören möchte ist eine Einziger Grund der
Objektiv dagegen spricht, zur zeit sind es ja nur subjektive Gründe. 

Eine Firmen Norm muss doch auch kein eng geschnürtes Korsett
sein, sondern kann doch eine Hilfe sein, wenn du mal ein Programm
deines Kollegen vorgesetzt bekommst und findest dich darin zurecht.


----------



## Wutbürger (26 Juli 2014)

rostiger Nagel schrieb:


> Aber der Gedanke ist gut vor Einführung von TIA die
> die Alte Arbeitsweise zu hinterfragen und das auf einen
> System was man beherrscht, die classic Welt.



Ist das nicht eher so, wie ein Haus vor dem Abriss noch einmal zu streichen?



rostiger Nagel schrieb:


> Außerdem wird wahrscheinlich TIA sehr schnell auf euch
> zukommen, weil im Oktober sieht es mit den Panels schlecht
> aus. Also bleibt euch doch garnicht soviel Zeit eine Firmen
> Norm zu erarbeiten.



 Zu erarbeiten?  
 Geht das mit TIA nicht in 10 Minuten von alleine?

 Der Wutbürger


----------



## Lipperlandstern (26 Juli 2014)

Aventinus schrieb:


> Mir ging es weniger um Taktmerker. Ich hab das aber auch schon bei Schrittmerkern gesehen. Die Schritte wurden über einen Merkerdoppelwortzugriff gelöscht (Initialisieren) und ansonsten bitweise angesprochen. Nach einer Erweiterung suchte ein Kollege immer wieder sporadisch auftretende Fehler, die nach einer Störung auftraten weil das Doppelwort nicht mehr alle Schrittmerker umfasst hat.
> 
> Und sowas kann mit einer Struktur nicht passieren.




So so ein Fehler ist in der Regel aber in Sekunden gefunden und behoben. Kann das mit einer Struktur wirklich nicht passieren ? Auch bei Erweiterungen nicht ?


----------



## Wutbürger (26 Juli 2014)

Lipperlandstern schrieb:


> So so ein Fehler ist in der Regel aber in  Sekunden gefunden und behoben. Kann das mit einer Struktur wirklich  nicht passieren ? Auch bei Erweiterungen nicht ?



So ein Fehler wird nur dann schnell gefunden, wenn es zur Regel wird, dass er auftritt.
 Strukturen allein sind kein Allheilmittel, schaffen aber, wenn es gut gemacht ist, Übersicht.

 Alles was global angelegt ist, aber nicht global sein müsste, raubt Übersicht.

 Gewisse Ansätze in der Skalierbarkeit und Wiederverwendbarkeit konnte ich schon umsetzen.
Eine vernünftige und einfache Versionsverwaltung habe ich leider noch keine gefunden.

 Kennt da wer was richtig gutes?
Vorzugsweise nicht ausschließlich für Siemens?

Der Wutbürger


----------



## rostiger Nagel (26 Juli 2014)

Wutbürger schrieb:


> Ist das nicht eher so, wie ein Haus vor dem Abriss noch einmal zu streichen?
> 
> 
> 
> ...



sehe ich nicht so krass, zur einer Firmen-Normierung können doch die ganz einfachen dinge Zählen
die sich bei der umstellung auf TIA nicht unterscheiden müssen. Es sind schon die kleinen Dinge, die
so etwas ausmachen z.b.:


Das ein Taktmerkerbyte immer das gleiche ist und die einzelnen Bits immer die gleiche Symbolik hat.
Grundsätzlich, wie eine Symbolik auszusehen hat.
Wie ein Programm strukturiert werden soll.
Nummernbereiche für Programmbausteine und Biblotheken
und und und.

Außerdem kann man sich ja bei der Endwicklung TIA paralell anschuen und schon darauf eingehen


----------



## MrSpexx (26 Juli 2014)

Interressant wäre eine Diskussion über Programmstrukkturen, anstatt sich  hier über den Sinn un Unsinn von Merkern zu streiten. Wobei mich doch eher die Programmstrukktur ohne Merker interessieren würde.


----------



## bike (26 Juli 2014)

Ist die Diskussion inzwischen nicht nur noch akademisch?
Das Standardisieren und Vereinheitlichen der Programmierung wurde doch bei den Hochsprachen versucht.
Hat es geklappt?

Ist das Gleichschalten der Programmierung wirklich der richtige Weg?
Was macht denn "Made in Germany" aus?
Beruht der Fortschritt nicht darauf, dass anders gedacht, produziert und programmiert wird?

Grundlagen können und sollen standardisiert sein.
Doch alles über einen Kamm scheren?

Muss nicht sein.


bike


----------



## MrSpexx (26 Juli 2014)

Ich bin dafür noch eine Kategorie "*Programmierideologien*" einzuführen!


----------



## MrSpexx (26 Juli 2014)

bike schrieb:


> Ist die Diskussion inzwischen nicht nur noch akademisch?
> Das Standardisieren und Vereinheitlichen der Programmierung wurde doch bei den Hochsprachen versucht.
> Hat es geklappt?
> 
> ...



Interessant diese Diskussion hatte ich vor ein paar Wochen auch schon im Geschäft. Es geht ja nicht da drum jedes Fitzelchen zu standardisieren. Ich empfehle dir den Programmierleitfaden von TIA. 
Warum soll ich jedes mal das Rad neu erfinden und mir Tagelang die Finger wund tippen oder aus unterschiedlichen Programm zusammen kopieren um nachher alles zu testen ob ich mich nirgends vertippt habe? Meistens hat eine Firma ja ähnliche Maschinen bzw. ist auf was spezialisiert. und da kann der größte Teil mit einem guten Standard erschlagen werden. Und der Rest ist dann wirklich anders und da kann man Gehirnschmalz reinstecken.

Fängt man immer wieder von vorne an z.B. Zylinderfehler dort, Ansteuerung dort, Verriegelung mal so und so, wird man über ein bestimmtes Level nie hinaus kommen, bzw. länger brauchen oder schlechtere Programme abliefern oder man ist richtig gut. Aber wenn ein neuer Kollege bei Euch anfängt wird er froh sein bestimmte Dinge eben eine Firmennorm vorzufinden.

Mal abgesehen waren Lochkarten auch lange Zeit Stand der Technik. Also Sachen nur gut finden ohne Begründung zählt nicht.


----------



## zotos (26 Juli 2014)

Ich wollte dazu auch noch was schreiben um hervorzuheben wie Sinnvoll und notwendig ich solche Richtlinien finde, wo die Vorteile und Gefahren bestehen usw. Beim überfliegen dieses Threads ist mir dann aber aufgefallen das die wichtigsten Punkte bereits geschrieben wurden.

es wird schwer fallen Argumente aufzulisten die gegen die Einigung auf einen gemeinsamen Programmierstil in einer Firma sprechen. Beim dem Thema wie eine solche Richtlinie zu gestallten ist gibt es hingegen genügend Diskussionsbedarf. Wenn das Klima in der Entwicklungsabteilung passt wird man sich da aber auch einigen könnten.

Ich finde den Standard den wir verwenden super. Er erleichtert das Programmieren sehr da Standardfunktionen bereits vorhanden sind und einheitlich zur Verfügung stehen. Die Wiederverwendbarkeit ist auch ein riesen Vorteil. Die Programme von den Kollegen kann man wie ein Buch lesen dessen Sprache man versteht ohne sich erst ewig einarbeiten zu müssen. Das ganze dient keinem Selbstzweck und ist auch kein Gesetz man hält sich bei uns deshalb an di gemeinsam definierten Standards da diese enorme Vorteile bringen.


----------



## Blockmove (26 Juli 2014)

MrSpexx schrieb:


> Interressant wäre eine Diskussion über Programmstrukkturen, anstatt sich  hier über den Sinn un Unsinn von Merkern zu streiten. Wobei mich doch eher die Programmstrukktur ohne Merker interessieren würde.



Programmstrukturen sind eigentlich eher selten ein Thema (Falls du damit meinst, wie ein Programm gegliedert ist)

Die Diskussionen gehen eigentlich immer um die gleichen Themen:

Verwenden von Merkern und S5-Timer
Übergreifende Zugriffe auf Instanz-DB oder Verwendung von Global-DB
Schnittstellen-DB für Visualisierungen oder Integration der Visualiserung im Instanz-DB.

Meines Erachtes ist das "WAS" egal. Das "WIE" ist der Punkt!
Ich hab sowohl beschiessene als auch hervoragende Programme in jeder Form / Sprache gesehen.

Einer unserer Instandhalter sagte mal zu mir:
"Ich hab deine Telefonnummer und weiß wo du und deine Familie wohnen ... Programmier entsprechend" 

Gruß
Dieter


----------



## MrSpexx (26 Juli 2014)

zotos schrieb:


> Ich finde den Standard den wir verwenden super. Er erleichtert das Programmieren sehr da Standardfunktionen bereits vorhanden sind und einheitlich zur Verfügung stehen. Die Wiederverwendbarkeit ist auch ein riesen Vorteil. Die Programme von den Kollegen kann man wie ein Buch lesen dessen Sprache man versteht ohne sich erst ewig einarbeiten zu müssen. Das ganze dient keinem Selbstzweck und ist auch kein Gesetz man hält sich bei uns deshalb an di gemeinsam definierten Standards da diese enorme Vorteile bringen.



Ganz geanu. Wenn man die Zeiten mal zusammen zählen würde, wie lange es dauert sich in die unterschiedlichen Programme einzudenken (egal ob gut oder schlecht, aber halt immer anders). 

In dieser Zeit hätte man sich LOCKER einen Standard schreiben und testen können.


----------



## MrSpexx (26 Juli 2014)

Blockmove schrieb:


> Programmstrukturen sind eigentlich eher selten ein Thema (Falls du damit meinst, wie ein Programm gegliedert ist)



Genau das meine ich. Hab hierim Forum bisher keine Diskussion dazu entdeckt. Und dabei ist es doch ein wichtiges Thema.


----------



## vierlagig (26 Juli 2014)

MrSpexx schrieb:


> Genau das meine ich. Hab hierim Forum bisher keine Diskussion dazu entdeckt. Und dabei ist es doch ein wichtiges Thema.



Hier wurde 2008 mal ansatzweise darauf eingegangen: http://www.sps-forum.de/simatic/20768-erstellung-von-programmen-fb-fc-usw-symbolisch-moeglich.html

Und dann vermag ich mich noch an einen Thread eines Berufsschullehrers erinnern, ein Klassiker: http://www.sps-forum.de/simatic/18651-wie-programmiert-der-praktiker.html


----------



## bike (27 Juli 2014)

MrSpexx schrieb:


> Interessant diese Diskussion hatte ich vor ein  paar Wochen auch schon im Geschäft. Es geht ja nicht da drum jedes  Fitzelchen zu standardisieren. Ich empfehle dir den Programmierleitfaden  von TIA.
> Warum soll ich jedes mal das Rad neu erfinden und mir Tagelang die  Finger wund tippen oder aus unterschiedlichen Programm zusammen kopieren  um nachher alles zu testen ob ich mich nirgends vertippt habe? Meistens  hat eine Firma ja ähnliche Maschinen bzw. ist auf was spezialisiert.  und da kann der größte Teil mit einem guten Standard erschlagen werden.  Und der Rest ist dann wirklich anders und da kann man Gehirnschmalz  reinstecken.
> 
> Fängt man immer wieder von vorne an z.B. Zylinderfehler dort,  Ansteuerung dort, Verriegelung mal so und so, wird man über ein  bestimmtes Level nie hinaus kommen, bzw. länger brauchen oder  schlechtere Programme abliefern oder man ist richtig gut. Aber wenn ein  neuer Kollege bei Euch anfängt wird er froh sein bestimmte Dinge eben  eine Firmennorm vorzufinden.
> ...



Bitte nicht TIA, ich bin kein Masochist. :wink:
Du schreibst das wie wir es auch sehen.
Symbole, die Programmstruktur sowie Standardfunktionen sind in allen Programmen gleich.
Bei allem das besonders bzw spezifisch ist, kann der Entwickler sein Wissen und auch teilweise seine Vorlieben umsetzen.
Damit sind wir bisher und werden auch in Zukunft gut gefahren und wenn  einer zu Kreativ wird, dann kann mit dem beim Kaffee dies bereden und  einen gemeinsamen Nenner finden.


bike


----------



## ducati (27 Juli 2014)

Lord Helmchen schrieb:


> Was mir halt wirklich widerstrebt ist, dass diese Änderungen angegangen werden sollen, bevor wir auf TIA umstellen.
> Sollte es ansprechende Neuerungen in TIA geben, so können diese auf den neuen Standard von Klassik, trotz aller Bemühungen, doch nicht angewandt werden.
> 
> Dann haben wir nicht ein einheitliches System, sondern drei verschiedene:
> ...



sehe ich auch so... aber kommt halt drauf an, wieviele Anlagen Ihr noch mit Classic bauen wollt/könnt/dürft...

macht halt wenig Sinn, ne einheitliche Standardbibliothek für 2 Anlagen mit Classic zu entwickeln, wenn davon für TIA das meiste nicht mehr läuft und nochmal entwickelt werden müsste...

Gruß.

PS: ich sehe Classic noch lange nicht tot... und ob TIA sich durchsetzen wird, wäre noch abzuwarten. Von daher: kommt eben drauf an.


----------



## miasma (27 Juli 2014)

MrSpexx schrieb:


> Interressant wäre eine Diskussion über Programmstrukkturen, anstatt sich  hier über den Sinn un Unsinn von Merkern zu streiten. Wobei mich doch eher die Programmstrukktur ohne Merker interessieren würde.



2 Möglichkeiten nutze ich selber.



Multiinstanzen nutzen wo es nur geht und als Schnittstelle für die einzelnen Bausteine den TEMP Bereich des FB nutzen. Somit werden Funktionen komplett gekapselt und Copy und Paste fähig.
Seine Bausteine so anlegen das Sie einen InOut als STRUCT haben wo alle relevanten Daten für Schnittstellen übergeben werden. Funktioniert gut erzeugt aber unnötigen Code und erschwert die Lesbarkeit des Programms.


----------



## miasma (27 Juli 2014)

Lord Helmchen schrieb:


> Seid Gegrüßt,
> 
> Ihr Programmierer und Leidensgenossen. Sei geraumer Zeit treibt eine neuer Geist in meiner Firma sein Unwesen. Es wird gemunkelt, „Firmen-Norm“ soll er sich nennen!
> 
> ...



Was spricht dagegen in einer S7 Steuerung ein S7 Programm mit dessen Möglichkeiten ablaufen zu lassen und nicht nur alten S5 Code ? 

Ich entwickle gerade auch eine neue Standardbibliothek für TIA da setze ich auch die ganzen Neuerungen ein die TIA mitbringt.
Ich will keinen STEP 7 Klassik Code im TIA Portal. Sonst kann ich ja gleich bei Klassik bleiben was ja auch Problemlos möglich bleiben wird.
Sich auf die Möglichkeiten eines neuen Systems einzulassen kann durchaus einen großen Schritt nach vorne bedeuten.
Auch wenn es für das Gewohnheitstier Mensch oftmals einfach nur eine sinnlose Änderung von bewährten Dingen zu sein scheint.


----------



## Blockmove (27 Juli 2014)

miasma schrieb:


> 2 Möglichkeiten nutze ich selber.
> 
> 
> 
> ...



Was mich an beiden Lösungen stört ist, dass bei keiner ein Querverweiss richtig möglich ist.
Man muss sich unter Umständen bei der Fehlersuche durch x-Aufrufschnittstellen hangeln.
Unsere Instandhalter (und ich denke auch viele andere) fluchen bei sowas kräftig.


Gruß
Dieter


----------



## miasma (27 Juli 2014)

Methode 1 nutze ich immer wenn ich die Software Programmiere. Dann brauche ich auch keine Querverweise bzw. ich nutze gehe zur lokalen Verwendungsstelle (Shift+STRG+ B oder F).

Bei Methode 2 befinden sich die Daten in einem DB wieso sollten da die Querverweise nicht funktionieren ?


----------



## rostiger Nagel (27 Juli 2014)

ducati schrieb:


> PS: ich sehe Classic noch lange nicht tot... und ob TIA sich durchsetzen wird, wäre noch abzuwarten. Von daher: kommt eben drauf an.



Wen man bei Siemens bleibt, wird sich TIA durchsetzen, es sei den man möchte seine
Anlage in Zukunft mit gebrauchten Steuerungskomponenten bauen. Das wird nicht mehr
lange dauern, dann geht es den Classic CPUs an den Kragen.

Ich einer der aller größten Kritiker von TIA werde kein neues Projekt mehr mit der Classic
Welt anpacken. So ein bischen habe ich auch meinen Frieden mit TIA geschlossen. 

Zur Endwicklung der Firmen-Norm, warum nicht das was in beide Welten passt, nicht
schon sofort anpacken, so hat man doch einen sanften Umstieg und es kommt nicht
alles geballt. Es ist ja sowieso kein Prozess der innerhalb 3 Wochen abgeschlossen ist,
das wird schon mehrer Jahre dauern.


----------



## Blockmove (27 Juli 2014)

miasma schrieb:


> Methode 1 nutze ich immer wenn ich die Software Programmiere. Dann brauche ich auch keine Querverweise bzw. ich nutze gehe zur lokalen Verwendungsstelle (Shift+STRG+ B oder F).
> 
> Bei Methode 2 befinden sich die Daten in einem DB wieso sollten da die Querverweise nicht funktionieren ?



Für wen schreibst du deine Programme? Für dich oder den Kunden?
Wir haben Anlagen x-Herstellern und jeder hat seinen eigenen Stil ...

Wenn ich an einen FB eine komplette Struktur übergebe, was bekomme ich dann im Querverweis?

Gruß
Dieter


----------



## miasma (27 Juli 2014)

Ich schreibe die Programme für unsere Kunden. Ich arbeite bei einem Maschinen und Anlagenbauer der die Software für seine Anlagen selber macht. 

Wenn ich einen Querverweis auf einen UDT machen bekomme ich sämtliche Referenzen in der Software angezeigt sofern ich den Hacken setze "Überlappender ...".


----------



## PN/DP (27 Juli 2014)

miasma schrieb:


> Wenn ich einen Querverweis auf einen UDT machen bekomme ich sämtliche Referenzen in der Software angezeigt sofern ich den Hacken setze "Überlappender ...".


Du bekommst lediglich einen Querverweis, daß die Struktur an irgendwas übergeben wird, aber keine Querverweise auf die Zugriffe auf die Member der Struktur.
Außerdem wird die angezeigte Art des Zugriffs (R/W) nur davon abgeleitet, ob die Struktur-Adresse an IN/OUT/IN_OUT übergeben wird. Unabhängig davon was wirklich mit der Struktur veranstaltet wird.

Harald


----------



## miasma (27 Juli 2014)

Dazu kann ich nur sagen bei mir werden immer alle Elemente der Struktur nutze. Ich habe keine Reserven. Deshalb weiß ich das die Daten genutzt werden. 

Also ich kann in meiner Liste sehr wohl sehen auf welches Element lesend und Schreibend zugegriffen wird.
Innerhalb des FB oder des FC kann ich dann über die lokale Verwendungsstelle Querverweise bilden.

Was es Querverweise angeht bin ich ganz einfach der Meinung umso mehr ich die Querverweisliste nutzen muss umso schlechter ist die Software strukturiert bzw. aufgebaut.

Bei einer guten Struktur und einer Symbolik die so aufgebaut ist das die Referenzen klar erkennbar sind komme ich fast vollkommen ohne Querverweise aus. 

Ich verstehe aber worauf Blockmove hinaus will, er muss viele Maschinen mit unterschiedlicher Software betreuen und ist daher auf Hilfsmittel wie Querverweise angewiesen.


----------



## zotos (27 Juli 2014)

Blockmove schrieb:


> Was mich an beiden Lösungen stört ist, dass bei keiner ein Querverweiss richtig möglich ist.
> Man muss sich unter Umständen bei der Fehlersuche durch x-Aufrufschnittstellen hangeln.
> Unsere Instandhalter (und ich denke auch viele andere) fluchen bei sowas kräftig.
> 
> ...



Vielleicht solltet ihr mal andere Maßnahmen ergreifen. Einer meiner Ansprüche an einen Standard ist z.B. das die Instandhalter erst gar nicht zum PG greifen müssen um Störungen zu analysieren.

Wegen einem defekten Sensor oder Aktor sollte man z.B. nicht zum PG greifen müssen. Kommunikation zu Subsystemen oder zur Leittechnik sind zu visualisieren.

Diese "unsere Instandhalter" Aussage geht mir schon seit Jahren auf den Nerv. Ich kenne auch einige Instandhalter und die meisten derer die sich mit einem PG an die Machinen und Anlagen begeben können damit auch gut umgehen und kommen damit klar. Die anderen können ganz gut mit einem Telefon umgehen und sich Unterstützung anfordern. Die Jungs sind doch nicht dumm.

Hinter der Aussage vermute ich eher eine Ausrede die bewirken soll den eigenen Stil zu rechtfertigen.


----------



## Blockmove (27 Juli 2014)

zotos schrieb:


> Vielleicht solltet ihr mal andere Maßnahmen ergreifen. Einer meiner Ansprüche an einen Standard ist z.B. das die Instandhalter erst gar nicht zum PG greifen müssen um Störungen zu analysieren.
> 
> Wegen einem defekten Sensor oder Aktor sollte man z.B. nicht zum PG greifen müssen. Kommunikation zu Subsystemen oder zur Leittechnik sind zu visualisieren.
> 
> ...



Wir haben all die Massnahmen bei unseren eigenen Anlagen umgesetzt.
Es gibt komplette Diagnose von Bewegungen / Schrittketten / Antrieben /Schnittstellen usw.
In dieser Hinsicht teile ich komplett deinen Anspruch, dass ein Instandhalter gar nicht erst zum Notebook greifen muß.

Ich sehe allerdings auch viele Anlagen von anderen Herstellern, bei denen darauf kein großer Wert gelegt wird.
Schliesslich steckt hinter einer vernünftigen Visualisierung eben auch ein erheblicher Zeitaufwand.
Verfahren wie UDT-Übergabe oder Instanz-Zugriffe sparen beim Programmieren extrem viel Zeit, spart man noch zusätzlich an Visualisierung und Diagnose, so ist ein Programm schnell erstellt.
In diesem Fall dienen diese Verfahren dem reinen Selbstzweck. Der Kunde profitiert nicht davon.
Wenn an einer Anlage ein innovativer Programmierer alle Aktoren durch einen einzigen FB über ein Array von UDTs in dem sogar die Hardware-Adressen hinterlegt sind, anspricht, dann wird die Fehlersuche "interessant".

Gruß
Dieter


----------



## Blockmove (27 Juli 2014)

miasma schrieb:


> Ich schreibe die Programme für unsere Kunden. Ich arbeite bei einem Maschinen und Anlagenbauer der die Software für seine Anlagen selber macht.
> 
> Wenn ich einen Querverweis auf einen UDT machen bekomme ich sämtliche Referenzen in der Software angezeigt sofern ich den Hacken setze "Überlappender ...".



Du übergibst in deinem Beispiel keine UDT, sondern gehst z.B. mit den UDT-Elementen von "Plant_Line"._7600_VMX_PU auf die Parameter deines FB "ST Motor".
So mache ich das auch, weil da eben der Querverweis geht.
Du könntest aber auch ganz einfach die komplette UDT an den FB übergeben und so viel Tipparbeit sparen.

Gruß
Dieter


----------



## bike (28 Juli 2014)

zotos schrieb:


> Vielleicht solltet ihr mal andere Maßnahmen ergreifen. Einer meiner Ansprüche an einen Standard ist z.B. das die Instandhalter erst gar nicht zum PG greifen müssen um Störungen zu analysieren.
> 
> Wegen einem defekten Sensor oder Aktor sollte man z.B. nicht zum PG greifen müssen. Kommunikation zu Subsystemen oder zur Leittechnik sind zu visualisieren.
> 
> ...



Denkst du wirklich, auch nur ein Entwickler schreibt seine Programme so, dass ein Programmiergerät angeschlossen muss?
Wenn du die Möglichkeit hast, alle theoretisch und praktisch möglichen Fehler zu analysieren und entsprechenden Meldung auszuprogrammieren und auch alles austesten, dann gehörst du zu den Glücklichen.
Wir können das leider nicht und mich würde interessieren, wer diese Zeit und Gelegenheit hat.

Und es stimmt Instandhalter sind meist nicht dumm und wir können froh sein, dass es viele gute Techniker unter diesen Leuten gibt.


bike


----------



## zotos (28 Juli 2014)

bike schrieb:


> ....
> Wenn du die Möglichkeit hast, alle theoretisch und praktisch möglichen Fehler zu analysieren und entsprechenden Meldung auszuprogrammieren und auch alles austesten, dann gehörst du zu den Glücklichen.
> ...



Eben genau dafür braucht es einen guten Standard. Die Meldungen werden eben nicht von Hand zu Fuß programmiert sondern durch den Standard generiert und augegeben. Die Ansteuerung von Bewegungen sorgt eigenständig für eine Laufzeitüberwachung und Paarüberwachung. Geräte wie Servoregler usw. geben auch häufig ihre Fehlermeldungen ganz bereitwillig an die SPS weiter diese kann man im klartext anzeigen. Schittketten lassen sich je nach eingesetztem Verfahren auch recht gut visualisieren. usw. usw

Mit Merkerschrittketten und S5Timern dauert das alles sicher ewig und genau deshalb setzen wir die nicht gerne ein.


----------



## Larry Laffer (28 Juli 2014)

bike schrieb:


> Wenn du die Möglichkeit hast, alle theoretisch und praktisch möglichen Fehler zu analysieren und entsprechenden Meldung auszuprogrammieren und auch alles austesten, dann gehörst du zu den Glücklichen.
> Wir können das leider nicht und mich würde interessieren, wer diese Zeit und Gelegenheit hat.



Wenn du eine Maschine/Anlage das Allererste Mal in der vorliegenden Form baust dann mag das bedingt zutreffen - dennoch gibt es aber schon mal ein paar grundsätzliche Dinge, die man berücksichtigen kann (Endlagen, Timeouts, Meldungen etc.).
Die Meißten bauen allerdings ihre Maschinen/Anlagen in ähnlicher Form immer wieder - da sollte man dann so nach und nach schon Erfahrungen gesammelt haben, was alles außer dem genannten noch so vorkommen kann und es mit berücksichtigt haben.
Das hat allerdings mit Standard nur bedingt etwas zu tun ... das gehört nach meiner Meinung so oder so dazu ...

Gruß
Larry


----------



## bike (28 Juli 2014)

Du hast bedingt recht.
Wenn es um eine schwarz / weiß Bewegung geht.
Da kann man problemlos die entsprechenden Meldungen und Alarme anzeigen.
Aber z.B. bei einer Achse, die etwas positionieren oder fügen soll.
Die Endposition wird nicht erreicht. 
Wie soll die Steuerung wissen, warum die Mechanik oder der Regler Mist bauen oder warum sonst die Position nicht erreicht wird?
Wenn es Probleme mit dem Datenaustausch mit intelligenten Komponenten gibt, was soll angezeigt werden?

Daher ist es ab und an notwendig, ein Programmiergerät anzuschließen.
Denn besser keine, als eine falsche Meldung anzeigen.


bike


----------



## Markus (28 Juli 2014)

Wenn du unbedingt Gründe gegen einen Standard suchst, man kann es auch falsch machen.
Ich habe schon "Standards" gesehen, da wäre es wirklich schneller gewesen den Code einfach stumpf runter zu tippen.

Da sind schlecht durchdachte System die gewachsen sind, inzwischen muss man das Signal halt hier und da und dort auch noch verschalten und zur Übergabe an einen anderen Teil noch mit einer bestimmten Logik versehen.
Dann muss man die REAL Istwerte aber mit dem einen Teil als DINT verrechnen und das Ergebnis für die Übergabe an 5 verschiedene Übergeordnete Systeme auf 5 verschiedene Arten aufbereiten...

Es ist alles mehr oder weniger schlecht so dokumentiert, und alle müssen es so machen weil es Standard ist, aber eine Erleichterung ist das auf keinen Fall.

Solche Beispiele sprechen aber letzten Endes nicht gegen einen Standard an sich, sie zeigen nur auf das man in nicht von jedem Idioten entwickeln bzw. pflegen lassen darf...


----------



## zotos (28 Juli 2014)

bike schrieb:


> ...
> Aber z.B. bei einer Achse, die etwas positionieren oder fügen soll.
> ...


Positionierungstimeout, Überstrom, Schleppfehler, was auch immer mir der Regler verrät. Da kommt man mit der SPS Software auch nicht weiter. Auch wenn es an der Mechanik hängt kann man das schlecht aus dem SPS Code rauslesen.




bike schrieb:


> ...
> Denn besser keine, als eine falsche Meldung anzeigen.
> ...


Gar keine Meldung ist oberkacke. Eine Maschine die ohne Meldung einfach den Dienst verweigert ist peinlich. Sie sollte wenigsten einen Hinweis liefern auf was sie wartet oder was den Ablauf stört.


----------



## bike (28 Juli 2014)

Markus schrieb:


> Wenn du unbedingt Gründe gegen einen Standard suchst, man kann es auch falsch machen.
> Ich habe schon "Standards" gesehen, da wäre es wirklich schneller gewesen den Code einfach stumpf runter zu tippen..



Jetzt habe ich mich entweder falsch ausgedrückt oder wurde falsch verstanden.
Ich bin für Standards.
Bei uns sind alle Standardfunktionen mit Meldungen und Anbindung an ein Programm in  Bibliotheken. 
Da ist HMI, Netzanbindung und Protokolle auch dabei. 

Die Aussage wegen Alarmen und Meldungen war wegen den Aussagen, dass man jeden Fehler ohne Programmiergerät findet.
Wer garantiert, dass alle Quereinflüsse richtig decodiert und angezeigt werden?
Man kann viele Meldungen und Überwachungen ausprogrammieren, doch alles geht meist aus verschiedenen Gründen nicht.

Darum ging / geht es mir.


bike


----------



## Markus (28 Juli 2014)

@bike
das war an den treadstarter gerichtet - er hat sich ja eher Gegenargumente gewünscht


----------



## zotos (28 Juli 2014)

Hilf mir mal auf die Sprünge und zeig mir die Stelle wo ich folgendes behauptet habe:


bike schrieb:


> ...
> Die Aussage wegen Alarmen und Meldungen war wegen den Aussagen, dass man *jeden* Fehler ohne Programmiergerät findet.
> ...






bike schrieb:


> ...
> Wer garantiert, dass alle Quereinflüsse richtig decodiert und angezeigt werden?
> ...


Niemand. Wenn man sich bemüht und die Einsätze vom PG zur Fehlersuche bis auf ein Minimum reduziert, ist an den Grenzfällen eh meist der Programmierer gefordert der die Scheiße verbockt hat.
IMHO sollte die Instandhaltung sich mit Fehlern beschäftigen die durch Ablaufstörungen wie defekte Bauteile (Sensoren, Aktoren, Mechanik und Co.) beschäftigen wenn Du noch Bugs in Deinen Programmen hast sollte das nicht die Instandhaltung ausbügeln.



bike schrieb:


> ...
> Man kann viele Meldungen und Überwachungen ausprogrammieren, doch alles geht meist aus verschiedenen Gründen nicht.
> ...


Nun habe ich das Glück fast ausschließlich Maschinen und Anlagen zu programmieren die Ablaufgesteuert sind und man kann die IO-Abläufe, NIO-Abläufe, Grundstellungsfahrt mit Schrittketten abbilden. Hier kann man zwar nicht zu 100% sagen warum die Maschine zum Stillstand gekommen ist, wenn etwas von der Mechanik zu Bruch geht weis das die Steuerung halt nicht aber sie kann visualisieren worauf die Maschine wartet und das auch anzeigen.

Wenn aber irgend ein Stift abbricht und deswegen die Kiste nicht läuft nutzt Dir auch kein PG weiter.


Wenn man sein System aber dementsprechend aufbauen möchte kommt man schnell an den Punkt wo ein unerfahrener Programmierer oder Instandhalter den Quellcode halt nicht mehr versteht. Im Fall des Instandhalters ist es nicht schlimm da die Kiste ihm in der Regel die nötigen Hinweise vermittelt. Jetzt hinzugehen und die gesamte Kiste mit Merkern und S5 Timern unter Verzicht auf SCL zusammen zuschustern nur für den Fall das der Instandhalter doch mal mit dem PG dran muss, macht die Umsetzung eines ordentlichen Fehlermanagment sehr aufwendig und teuer.


----------



## bike (28 Juli 2014)

@zotos:
Kann es sein, dass wir an einander vorbei schreiben?

Es ist schön wenn du deine Abläufe so aufbauen kannst, dass alle  Störungen angezeigt werden und nach IB kein PG mehr gebraucht wird.

Bei uns sind die Maschinen und Anlagen eben komplexer, da geht es nicht  und das stört auch bisher keinen, nicht einmal die Kunden.
Wie soll der Programmierer mal eben nach Chile oder sonst wo hin, um einen Fehler zu beheben?
Nicht alle Maschinen stehen mal eben um die Ecke.

Die Aussage wegen Merkern und Timern passt nicht wirklich.
Standard sind gekapselte Einzelfunktionen, so weit möglich.
Aber auch du darfst zugeben, dass einfacher ist bei der IB S5t und  Merker zu verwenden und nicht immer wieder IDB und Global DB zu  übertragen.
Denn beim Übertragen werden leider auch die aktuellen Werte überschrieben, was nicht immer gewollt ist.


bike


----------



## zotos (29 Juli 2014)

Gerade bei komplexen Anlagen hilft doch ein gut strukturierter und dokumentierter Standard.

Auch wenn die Anlage nicht gerade um die Ecke steht, sollte der Maschinen- / Anlagenbauer seine Fehler selbst beheben und dies nicht dem Kunden überantworten. Auch wenn man dafür anreisen muss. Bei sooo.. komplexen Anlagen wie die die Ihr baut lohnt sich da schnell eine ordentliche Fernwartung.


----------



## Larry Laffer (29 Juli 2014)

bike schrieb:


> ... dass einfacher ist bei der IB S5t und  Merker zu verwenden und nicht immer wieder IDB und Global DB zu  übertragen.
> Denn beim Übertragen werden leider auch die aktuellen Werte überschrieben, was nicht immer gewollt ist.



Da hast du bestimmt Recht - auf der anderen Seite erzeugt genau das eben keine wiederverwertbaren Bausteine und falls man einen dieser Bausteine dann noch ein zweites Mal instanziert hat schon gewonnen ... 8). Im Grunde sind solche Mischbausteine sogar für den Ersteller irgendwann einmal ein Problem ...

Ich habe auch das Problem, dass sich meine FB's so mit der Zeit (bei der IBN und in der Folge) in der Instanz vergrößern - ich habe dann aber auch immer die Möglichkeit, so etwas wie Parameter etc. in die neue Instanz wieder hinein zu bekommen.

Gruß
Larry


----------



## bike (29 Juli 2014)

Larry Laffer schrieb:


> Da hast du bestimmt Recht - auf der anderen Seite erzeugt genau das eben keine wiederverwertbaren Bausteine...



Nicht jeder Baustein muss einen grünen Punkt haben. ;-)
Mir ist noch keine Anlage untergekommen, die 1:1 kopiert werden konnte / wurde.

Ein Chef von mir hat einmal gesagt:
Programmierer sind Künstler und welcher Künstler lässt sich alles für sein Kunstwerk diktieren?


bike


----------



## Markus (29 Juli 2014)

@Zotos
Ich ziehe den Hut vor deinem Versuch zu helfen.
Was das betrifft bin ich inzwischen sehr abgestumpft und habe nicht mehr die Kraft und die Nerven für solche Diskussionen.
Es freut mich das es in diesem Thread z.B. Leute wie dich gibt die einen sauberen strukturierten Stil folgen.
Andere können das geschriebene aufnehmen oder nicht, was nützt es anderen etwas aufzuzwängen das ein Großteil der Bitschubser vermutlich niemals begreifen wird?

Wenn sie so glücklich mit ihren Merkern und S5-Timern sind, dann sollen sie halt.
Und Leute wie wir sind glücklich - weil wir zumindest in dem Glauben sind - es besser zu können.


----------



## Larry Laffer (29 Juli 2014)

@Markus:
Das hast du wirklich schön geschrieben ...


----------



## MrSpexx (29 Juli 2014)

Um nochmal die Diskussion über die Strukktur anzukurbeln!!!

Ist es z.B. besser möglichst alles aus einer Hauptschrittkettezu starten oder die einzelen Schrittketten aus Zuständen zu starten?

Welche Diagnosemöglcihkeiten außer Profibus/Profinet abfrage /Systemfehler / Schrittkettenanzeige gibt es noch?


----------



## rostiger Nagel (29 Juli 2014)

MrSpexx schrieb:


> Welche Diagnosemöglcihkeiten außer Profibus/Profinet abfrage /Systemfehler / Schrittkettenanzeige gibt es noch?



Grundsätzlich das normale Meldeverfahren die auf der HMI angezeigt wird.
Da mir Meldungen nicht geizen, schauen was ist eine Störmeldung die Quittiert
werden muss und was ist eine Betriebsmeldung die einen Zustand anzeigt.

Beispiel:
Störung Luft, ist eine Meldung die Quittiert werden sollte, weil die grundlegend ist
weil es ohne der Luft nicht weiter geht.

Endlage erreicht, ist eine Betriebsmeldung die einen Bediener zeigt, die Achse kann
in die Richtung nicht weitergefahren werden, fahr Sie gefälligst in die andere Richtung.


----------



## zotos (29 Juli 2014)

Man sollte sich auch die Mühe machen und die Fehlercodes die z.B. Antriebe liefern auch in der Visu anzuzeigen. Hierfür kann man in eine Meldung eine Textliste integrieren welche den Fehlercode in Klartext verwandelt.

Auch ein sehr interessantes Konzept finde ich die Umrechnung von E/A Adressen in Fehlermeldungen. Wenn man z.B. einen Bewegungsbausteinschreibt kann dieser direkt mitteilen auf welchen Eingang er wartet und wechen Zustand dieser denn nun haben soll.


----------



## Blockmove (29 Juli 2014)

MrSpexx schrieb:


> Ist es z.B. besser möglichst alles aus einer Hauptschrittkettezu starten oder die einzelen Schrittketten aus Zuständen zu starten?


Das lässt sich nicht pauschal beantworten.
Wenn es die Anlage ermöglicht, dann bevorzuge ich den Start aus den Zuständen heraus.
Damit ist der Wiederanlauf nach Störungsbeseitigung in der Regel wesentlich einfacher.
Ich arbeite damit sogar in den einzelnen Schrittketten und gliedere die Abläufe in Teilablaüfe und starte diese über Alternativverzweigung aus dem Initschritt heraus.
Da wir generell Schrittketten in Graph programmieren ist der Mehraufwand minimal.
Wenn du clever die Abläufe gliederst, dann bekomst die Vorteile von Schrittkette und Verknüpfungssteuerung ohne deren jeweiligen Nachteile.
Aber wie gesagt muss die Anlage auch dazu passen.

Gruß
Dieter


----------



## cosmomaster (31 Juli 2014)

miasma schrieb:


> ... als Schnittstelle für die einzelnen Bausteine den TEMP Bereich des FB nutzen.


Was meint er damit? Hört sich sehr interessant an. Kann mir das jemand näher erklären oder einen Beitrag nennen wo das gezeigt wird.

Danke.


----------



## Markus (31 Juli 2014)

cosmomaster schrieb:


> Was meint er damit? Hört sich sehr interessant an. Kann mir das jemand näher erklären oder einen Beitrag nennen wo das gezeigt wird.
> 
> Danke.



Naja alle FB nutzen den selben Temp Bereich, wenn der zuvor aufgerufene da was ablegt, dann hat es der nächste direkt verfügbar.
Ist gemein wenn es nicht sauber dokumentiert und ersichtlich ist, ist aber sehr schnell 7 laufzeitoptimiert.




miasma schrieb:


> 2 Möglichkeiten nutze ich selber.
> 
> 
> Seine Bausteine so anlegen das Sie einen InOut als STRUCT haben wo alle relevanten Daten für Schnittstellen übergeben werden. Funktioniert gut erzeugt aber unnötigen Code und erschwert die Lesbarkeit des Programms.



Nachteil bei INOUT UDT sind die ganzen Pointer die bei jedem Zugriff dafür gerechnet werden muss.
Das haut Extrem auf die Zykluszeit!
Optimaler ist ein IN ANY, das was an dem Pointer steht am Anfang vom Baustein mit SFC20 in den Temp/Stat Bereich. Damit zur Laufzeit arbeiten und im letzten Netzwerk den Inhalt von Temp/Stat wieder auf den Pointer mit SFC20.
Das ist WESENTLICH schneller als INOUT UDT! Dafür wird im MC7 Code für JEDEN!!! zugriff ein Pointer mit AR1 und AR2 eingefügt.
Wenn du die Deklaration von INOUT UDT genau anschaust, dann ist das intern nämlich auch nix anderes als ein ANY...


----------



## Wutbürger (2 August 2014)

zotos schrieb:


> Man sollte sich auch die Mühe machen und die Fehlercodes die z.B. Antriebe liefern auch in der Visu anzuzeigen. Hierfür kann man in eine Meldung eine Textliste integrieren welche den Fehlercode in Klartext verwandelt.


 
Diese Idee hatte ich auch schon. Leider gibt es bei vielen Herstellern derart viele Fehlercodes, dass dieser Programmteil mehr als der Rest der Maschine ausmachen würde. Wenn dann nach jeweils einem halben Jahr neue Fehlerauswertungen hinzukommen, gibt das eine Dauerbaustelle.

Schöner fände ich, wenn die Komponenten einen "Fehlersting" ausspucken würden!

Der Wutbürger


----------



## Markus (2 August 2014)

Wutbürger schrieb:


> Diese Idee hatte ich auch schon. Leider gibt es bei vielen Herstellern derart viele Fehlercodes, dass dieser Programmteil mehr als der Rest der Maschine ausmachen würde. Wenn dann nach jeweils einem halben Jahr neue Fehlerauswertungen hinzukommen, gibt das eine Dauerbaustelle.
> 
> Schöner fände ich, wenn die Komponenten einen "Fehlersting" ausspucken würden!
> 
> Der Wutbürger



String ist böse - Erde ist ein Kugel...

Wir haben für Antriebe in den SW Standard eine Motion-Control Bibliothek integriert.
An dem Motion Controller kann ich verschieden Ausgangstreiber verwenden (SEW FU, S120, Analogausgang,...)

Die Treiber übergeben die Fehlernummer von ihrem Gerät über den Achs-UDT an den Motion-Controller zurück.
Dieser generiert eine Sammelstörung für die Achse und gibt eine aufbereitete Störnummer an die Visu.

Aufbereitet bedeutet das einfach nur ein Offset addiert wird.

Störung-1 vom SEW MC07 ist dann halt 100001
Störung-1 vom S120 ist dann halt 200001
...

Das gleiche gibt's für die Eingangstreiber (PN, SSI, 1COUNT,...)
Die liegen halt dann von 501-1000, von 1001-1500,...

Oben in der Visu gibt es dann für jede Achse noch eine Störung, und eine Textliste in der alles drin ist.
Der MC-Baustein hat noch eine Art FIFO drin falls mehrere Störungen gleichzeitig auftreten.


----------



## rostiger Nagel (2 August 2014)

Markus schrieb:


> String ist böse - Erde ist ein Kugel...
> 
> Wir haben für Antriebe in den SW Standard eine Motion-Control Bibliothek integriert.
> An dem Motion Controller kann ich verschieden Ausgangstreiber verwenden (SEW FU, S120, Analogausgang,...)
> ...



Und genau das ist eine wirklich sinnvolle Standardisierung, sich alleine über die Fehler Nr. Gedanken 
zu machen kann von großen Nutzen sein. Gibt am Telefon die Fehler Nr durch, weiß ein Projekt unbeteiligter
sofort wovon gesprochen wird. Auch Service am Telefon kostet Zeit und Geld.


----------



## Wutbürger (2 August 2014)

Markus schrieb:


> String ist böse - Erde ist ein Kugel...


Es gibt Steuerungen, bei denen die Standard- IEC- Funktionen keine Probleme machen. Dort kann man mühelos mit Strings arbeiten. 



Markus schrieb:


> Oben in der Visu gibt es dann für jede Achse noch eine Störung, und eine Textliste in der alles drin ist.


Wenn diese Textliste vollständig sein soll, umfasst sie mehrere Seiten! :-?
Beispiel: Beckhoff AX5000  (links scrollen...)
Und gleich noch die Änderungen dazu: ax5000_diagmessages_version (leider ohne Datum!)


----------



## Markus (2 August 2014)

Wutbürger schrieb:


> Es gibt Steuerungen, bei denen die Standard- IEC- Funktionen keine Probleme machen. Dort kann man mühelos mit Strings arbeiten.



Ja, aber das Handling vom mehren Sprachen in der Steuerung wird schon komplizierter, oder?




> Wenn diese Textliste vollständig sein soll, umfasst sie mehrere Seiten! :-?
> Beispiel: Beckhoff AX5000  (links scrollen...)
> Und gleich noch die Änderungen dazu: ax5000_diagmessages_version (leider ohne Datum!)



Ja, sieht beim S120 auch nicht besser aus, macht doch nichts.
Das geht in die meisten Visus mit einer Importfunktion, ggf. etwas Copy&paste oder im schlimmsten Fall ein Excelmakro...


----------



## rostiger Nagel (2 August 2014)

Wenn es den String sind, wie macht ihr das mit Fremdsprachen?


----------



## Wutbürger (2 August 2014)

Was sind Fremdsprachen?


----------



## rostiger Nagel (2 August 2014)

Wutbürger schrieb:


> Was sind Fremdsprachen?



Alles andere als die Ländersprache, ist eine Fremdsprache.

Nutzt du zb Englisch und denkst, das ist International, ist
deinen Maschine in Italien vielleicht nicht mehr CE-Konform.


----------



## zotos (2 August 2014)

Wutbürger schrieb:


> ...
> Leider gibt es bei vielen Herstellern derart viele Fehlercodes, dass dieser Programmteil mehr als der Rest der Maschine ausmachen würde. Wenn dann nach jeweils einem halben Jahr neue Fehlerauswertungen hinzukommen, gibt das eine Dauerbaustelle.
> ...


Das stimmt alles. 

Für einen Standard muss man in Vorleistung treten. Die ersten Maschinen und Anlagen werden aufwendiger dafür kann man die folgenden Maschinen um so leichter realisieren. Das ganze wächst und entwickelt sich von Maschine zu Maschine und Anlage zu Anlage weiter. 

Die Fehlermeldungen werden wenn möglich, automatisch generiert und aus bereits vorhandenen Textlisten zusammen kopiert. Im Fall einer E-Achse wird der Name aus einer Textliste mit der Fehlermeldung aus einer anderen, in Abhängigkeit vom Typ der Achse, Text liste zusammen kopiert und angezeigt. Das ganze ist für Standard Bewegungen (Pneumatik Zylinder und Co.) ähnlich umgesetzt auch wenn da die Fehlerliste deutlich geringer ausfällt. 

Um dies so umsetzen zu können besteht bei uns ein Eintrag in der Fehlerliste nicht nur aus einer Fehlernummer sondern aus mehreren Nummern und Zusatzfeldern: Typ (Störung/Warnung/Info), Quelle (E/A Adresse, Achsnummer, Bewegungsnummer, usw), Ereignis (der Fehlercode), Info (Zusatzinformationen), Zeit/Datum, Zähler.


Auch wenn ich von der Stringlösung nicht begeistert bin, lässt sich der Wunsch das anstelle von Nummern Strings geliefert werden relativ leicht mit ST/SCL und einer Case umsetzen. Ein Baustein gibt Dir eine Fehlernummer mit dem man einen Baustein ansteuert der mittels einer Case Verzeigung einen entsprechenden String als Rückgabewert liefert. Mit etwas Übung kann man dies mit Strg+C und Str+V und einem halbwegs guten Editor (z.B. Notepad++) relativ schnell aus dem Handbuch rauskopieren und in Quellcode verwandeln.


----------



## MrSpexx (4 August 2014)

Eine weitere Möglichkeit wäre aus den ganzen Bibliotheksbausteinen einen  UDT rauszugeben der alle Fehlermeldungen enthält. Dazu eine Excelliste  mit Makro erstellen in der man passend zu dem DB die Fehler einträgt. 

Also 2 Spalten:
BMK/Name .........              | Fehlermeldung ......................                               | Ergibt
23S1 ....................                                  NotHalt BMK gedrücket..............         Nothalt *-23S1* gdrückt

Name Zylinder           ........UDT Zylinder............................                                         * Name Zylinder* Fehler 1
.............................................................................Fehler *Name Zylinder* 2
                                                                   .............................................................................Fehler *Name Zylinder* 3

Name Motor............       UDT Motor                                                  *..............................Name Motor *Fehler 1
                                                                                                                                  .............................................................................Fehler *Name Motor *2
                                                                                                                                  .............................................................................Fehler *Name Motor *3
                                                                   .............................................................................Fehler *Name Motor *32

Als  Ergebnis bekommt man die Liste die man in winCCFlexible, Movicon, ...  importiert. Der Vorteil: Sprache und Hilfstexte können einfach editiert  werden, Fehlermeldungen sind in allen Anlagen (fast) gleich, Je mehr  Bausteine um so schneller sind die Fehlermeldungen erstellt, die größe  der UDT (Anzahl der Fehlermeldungen) spielt keine Rolle.


Die UDT Zylinder, ... sind eigne Worksheets. Das Ergebnis auch.


----------



## Drutbluck (23 August 2014)

Lord Helmchen schrieb:


> In S7 sollen weder S5-Timer noch Merker Verwendung finden. Auch Instanz-Datenbausteine sollen rationiert werden. Der Übersicht wegen, soll alles in „Multi-Instanzen“ verpackt werden.
> Auch verlangt der „neue Geist“, dass Bausteine zur Wiederverwertung entwickelt werden, an denen später keine Änderungen mehr vorgenommen werden dürfen.



Standards sind schlecht, wenn sie guten Programmierstil verhindern, oder schlechten erzwingen. Beispiel: Merker verbessern die Wiederverwendbarkeit der Programme, weil sie syntaktisch kompatibel zu (manchmal nicht vorhandenen) Ein- und Ausgängen sind.

In der "richtigen" Programmierung ist es gang und gäbe, dass Datenstrukturen auch verschachtelt werden und Funktionen sich gegenseitig aufrufen, auch ohne eigens entwickelte Buzzwords. Jetzt muss man vielleicht fast jeden FB in einen Dummy-FB wrappen, damit jemand beim Vortrag das Buzzword auf den Flipchart schreiben kann.

Wiederverwertung ist ja schön, aber das "keine späteren Änderungen" muss wohl aus dem "Waterfall-Modell" stammen. Soweit ich weiß, war das ursprünglich eine Parodie, um zu zeigen, wie es nicht gemacht werden soll. Aber das ist in Vergessenheit geraten.

S5-Timer sind durch IEC-Timer ersetzbar. Aber der muss erst in einen eigenen FB gewrappt werden, damit es eine Multiinstanz gibt. Habe ich sogar tatsächlich gemacht, aber aus anderen Gründen.

Nun ja, ich betreibe meinen eigenen Spuk, und verwende auch eigene implizite "Programmierrichtlinien". Beispielsweise sollten bei mir Variablennamen keine Leerstellen, Punkte und dergleichen enthalten.


----------



## Drutbluck (23 August 2014)

Lipperlandstern schrieb:


> So so ein Fehler ist in der Regel aber in Sekunden gefunden und behoben. Kann das mit einer Struktur wirklich nicht passieren ? Auch bei Erweiterungen nicht ?


Wenn die Struktur mit z.B. FILL auf 0 gesetzt wird und mit BLKMOV kopiert wird, gibt es bei Erweiterungen keine solchen Fehler.


----------



## Drutbluck (23 August 2014)

Wutbürger schrieb:


> Ist das nicht eher so, wie ein Haus vor dem Abriss noch einmal zu streichen?



Mein Programmierstil sieht anders aus, d.h. es gibt keinen Abriss. Es muss möglich sein, den gleichen Quellcode in der alten wie in der neuen Version zu verwenden. Dazu sind vielleicht einige Anpassungen nötig, und der Verzicht auf neue vendor-lock-in Features.

Der Hersteller hat natürlich ein entgegengesetztes Interesse. Ein Update alter Maschinen mit neuen Features und neuer Software sollte so beeinflusst werden, dass möglichst viel Umsatz mit neuen SPS und Zubehör erzielt wird.


----------



## norustnotrust (26 August 2014)

Drutbluck schrieb:


> Standards sind schlecht, wenn sie guten Programmierstil verhindern, oder schlechten erzwingen.



Meinst du das ernst?

Edit: Leider haben wir ja einen Standard für Steckdosen sonst könnten wir uns in Europa an 10.000 "guten" Steckdosenlösungen erfreuen und müßten nicht immer mit der einen "schlechten" leben...


----------



## rostiger Nagel (26 August 2014)

Drutbluck schrieb:


> Standards sind schlecht, wenn sie guten Programmierstil verhindern, oder schlechten erzwingen.





norustnotrust schrieb:


> Meinst du das ernst?
> 
> Edit: Leider haben wir ja einen Standard für Steckdosen sonst könnten wir uns in Europa an 10.000 "guten" Steckdosenlösungen erfreuen und müßten nicht immer mit der einen "schlechten" leben...



Den möchte ich mich mal ausdrücklich anschließen, das ist doch geschwafel, weil man weiterhin nicht über den Tellerand schauen möchte.

Warum muss ein Baustein den man zum Ansteuern eines Servos nimmt, z.b. der von SEW, in jeden Programm anders aus sehen. 
Weil auch Merker angesprochen werden, wo es im Prinzip nichts gegen zu sagen gibt, warum können da nicht einige Merker, wie 
zb. das Taktmekerbyte nicht immer das gleiche sein, mit den selbigen Kommentaren und Symbolen.

Auch das ist FIRMEN-NORM....


----------



## Drutbluck (27 August 2014)

Ein Programmierstandard erstellt noch keine Standardbibliothek, sondern schreibt nur vor, wie sie aussehen soll, wenn es sie denn gibt.

Und selbstverständlich meine ich das ernst. Ich konnte z.B. immer sehr gut ohne einen Programmierstandard leben, der vorschreibt, dass in IF-Abfragen keine Negationen vorkommen dürfen. Wo es diese Vorschrift gibt, sind natürlich einige Workarounds nötig. Und diese stehen immer in der Gefahr, dass sie den "Geist" des Standards verletzen, was zu noch sinnloserem Code führt, um diese Tatsache zu verschleiern.

Ich brauche auch nichts, das vorschreibt, dass ein bestimmtes Byte oder sonstiges immer an der gleichen Adresse zu sein hat. Habe ich nie gebraucht. Es hat ja einen Namen ("Symbol"). Ich habe am Anfang meiner Zeit solche informellen "Standards" so lange weiter gepflegt, bis es kam, wie es kommen musste: zwei verschiedene FCs mit gleicher Nummer in einem Programm. Seitdem nicht mehr.

Und genau die, die schlechte Standards entwickeln und vorschreiben, werden sich nicht daran halten, wenn dadurch das Ergebnis noch schlechter werden kann. Eigene Beobachtung.


----------



## norustnotrust (27 August 2014)

Drutbluck schrieb:


> Ich brauche auch nichts, das vorschreibt, dass ein bestimmtes Byte oder sonstiges immer an der gleichen Adresse zu sein hat. Habe ich nie gebraucht. Es hat ja einen Namen ("Symbol").


Wow, he. Hört sich ja verdammt nach God-Mode an. Aber genau da ist je das Problem. 
DU brauchst es nicht, klar aber vielleicht braucht es dein Kunde?
Oder der Typ der mal was wartet/erweitert an der Anlage?
Oder ein neuer MA der was programmieren soll und keine Ahnung hat was gute/schlechte Lösungen sind?
Oder ein Zulieferant der was liefern soll und du sicherstellen willst dass das was er liefern wird auch eine gewisse ausführungstechnische Qualität hat?
Oder der der dein Programm fertig schreibt wenn dich morgen in der Früh der Blitz trifft!
Oder dein ich aus der Zukunft das nach 10 Jahren an die Anlage kommt und sich fragt wo könnte ich das damals wohl reingepackt haben!

Das sind die Gründe warum Standards Sinn machen. Und es macht keinen Sinn in der Argumentation irgendwelche theoretischen Unsinnigkeiten rauszuholen die in einem Standard drinnen stehen könnten. Das ist doch kein Argument für/gegen einen Standard. Klar könnte es den einen oder anderen Unfall verhindern wenn ich mal auf der linken Spur fahre und mal auf der rechten aber in den meisten Fällen macht es schon Sinn sich auf eine Seite zu einigen meinst du nicht?

Es ist für mich zu kurz gedacht zu sagen nur weil "ICH" das nicht brauche braucht es "NIEMAND" und deswegen ist es Unsinn.

Der Inhalt und die Reichweite eines Standards natürlich hängt von vielen Dingen ab. Aber das es Sinn macht sich auf einen gemeinsamen Nenner zu einigen steht für mich außer Frage. Und ich bin auch der Ansicht dass es besser ist je größer der gemeinsame Nenner ist.


----------



## Larry Laffer (27 August 2014)

@NRNT:
Ich habe diesen Thread auch mitgelesen und seit einiger Zeit immer schon überlegt, was man dazu (hier speziell den Statements von Drutbluck) schreiben kann. Irgendwo war ich bei ähnlichen Inhalten angekommen, wie du sie hier so schön zusammen gefasst hast.
So schön wie du hätte ich es aber nicht zu schreiben vermocht.
Deswegen mein DANKE zu deinem Beitrag.

Gruß
Larry


----------



## Drutbluck (28 August 2014)

Hi,

meine symbolische Programmierung führt nicht automatisch dazu, dass es keine sichtbaren Adressen gibt (abgesehen von z.B. RSLogix 5000) oder dass sie überall unterschiedlich sind oder dass sie nicht bekannt sind.

Bei uns stehen eben (Merker-, DB-, FC-) Adressen nicht in einer "Firmen-Norm", sondern in der Symboltabelle und im Projekt. Die sind häufig tatsächlich fast immer gleich, weil ich es für sinnvoll halte, Dinge nicht ohne Grund unterschiedlich zu machen. Nur sind sie eben nicht streng normiert. Die Taktmerker sind also immer gleich nach Name, Kommentar und auch Byteadresse, aber wenn eine Kunden-Firmen-Norm oder eine importierte Bibliothek verlangt, dass das Byte verschoben wird, spricht nichts dagegen. Das Symbol zu ändern, ist etwas unangenehmer (weil das tatsächlich eine Abweichung von einer Art "Norm" sein könnte), aber auch möglich.

Und ich vermute, dass die, die solche Adressen normieren, ihre Norm auch gelegentlich ändern (müssen). Oder man hält sich nicht dran.

Addressen innerhalb DBs ändern sich durch Weiterentwicklung, Änderungen der Maschine, Kundenwünsche, weil sich die Struktur der UDTs und FBs ändert. Wenn das nicht sein dürfte, wäre Weiterentwicklung blockiert oder der Einsatz von UDTs, FBs und Arrays behindert.

So kann ich die Bedenken beantworten:
- Der Kunde hat die Adressen, sie stehen im Step7-Projekt. Globale Adressen (Symboltabelle) bleiben meistens gleich, Adressen tief in Strukturen eher nicht.
- Wer ganz ohne Step7-Projekt die Maschine ändert, kann es etwas leichter haben, wenn die Maschinen eines Herstellers alle gleich sind. Wenn ich keine neuen Kundenwünsche, keine Weiterentwicklung, keine Änderungen und keine Umstellung auf TIA-Portal umsetzen muss, geht das.
- Ein anderer MA hat ja Zugriff auf Quellcode und Adressen und kann im übrigen auf Anfrage informelle Programmierrichtlinien haben. Nach meiner Erfahrung, programmieren sie lieber so wie sie es wollen. Ich würde da nur nachbessern, wenn es "zu weit" abweicht oder fehlerhaft ist.
- Bei Kunden und Lieferanten werden Schnittstellen entwickelt, ich denke das ist nichts besonderes und liegt in der Natur der Sache.
- Bei Übergabe der Codebasis ist meines Erachtens ein Code, der auf Bezeichnern basiert statt Adressen, besser verständlich. Aber wie gesagt, die Adressen sind auch da (zumindest bei Step7 classic). Gleiches für "in 10 Jahren".
- Wenn ich nach 10 Jahren nur Adressen und Nummern vor mir sehen würde, würde ich da nichts finden. Gibt es Namen und Kommentare, sieht es besser aus. Das ist dann wohl "God-Mode".

Mein Beispiel für eine weniger wünschenswerte Richtlinie ist nicht theoretisch, sondern habe ich selbst so gesehen und anwenden müssen. Die gesamte Richtlinie, in der das enthalten war, hat auf weniger als 1 Blatt gepasst.

Wenn ich irgendwo programmiere, versuche ich mich an bestehende Standards zu halten, ob dokumentiert oder de facto ersichtlich. Nur wenn ich sehe, dass es so nicht funktioniert, dann bemühe ich mich um Verbesserung. Wenn es Programmier-Standards von mir geben soll, dann wird wohl weniger geregelt als manchen hier lieb ist, zumal ich sie ohnehin nicht durchsetzen kann.


----------



## norustnotrust (28 August 2014)

Fällt dir auf dass wir voneinander vorbeischreiben?
Ich schreibe: "Ein Programmierstandard macht Sinn"
Du schreibst: "Ein Programmierstandard der XY vorgibt macht keinen weil YZ besser ist"
Fein, wenn du YZ auf ein Blatt Papier schreibst was hast du dann? Einen STANDARD!



> Und ich vermute, dass die, die solche Adressen normieren, ihre Norm auch  gelegentlich ändern (müssen). Oder man hält sich nicht dran.


Ja man muß halt abwiegen ob/wann es wert ist vom Standard abzuweichen und wann es das nicht wert ist. Es wird immer Ausnahmen geben in denen es Sinn macht vom Standard abzuweichen, das  stellt aber den Standard als solchen für mich nicht in Frage. Wir haben ja auch einen Standard names "Rechtsfahrgebot" und das heißt eben aus gutem Grund nicht "Linksfahrverbot". 



> Nur wenn ich sehe, dass es so nicht funktioniert, dann bemühe ich mich um Verbesserung.


Ja, natürlich ist kein Standard für die Ewigkeit. Die Technik ändert sich, Prozesse entwickeln sich weiter, uvm. Damit ist der Standard auch immer einer ständigen Evolution unterworfen. Wir z.B. halten regelmäßig interne Kurz-Workshops ab in denen wir prüfen wo/was/warum wir etwas ändern wollen.


----------



## Larry Laffer (28 August 2014)

Wenn sich das Eine oder das Andere nicht unmittelbar standardisieren läßt (soll es ja geben - kenne ich sogar auch) dann kann man aber immer noch mit Vorlagen (also ggf. Bausteine, die man dann abwandelt und anpasst) arbeiten.

Gruß
Larry


----------

