TIA Programmstruktur

[DeBa]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Leute,

In unserer Firma verwenden wir aktuell die Siemens Steuerung 1516TF und Programmieren auf SCL. Alles ist auf der Statemachine PACKML OMAC aufgebaut und

Zu aller erst möchte ich sagen, dass ich seit kanp 2 Jahren in dieser Branche als Anlagenprogrammiere arbeite und somit nur etwas Grundwissen habe.
Also wir arbeiten Hauptsächlich mit den Siemens S7-1500 Steuerungen und programmieren auf dem TIA V16. Das Model PACKML OMAC verwenden wir als State Machine und bauen die Software nach dem Leitfaden von Siemens auf (UNIT, EM und CM). So gut wie alles wird auf SCL programiert, bis auf die übergeordneten Bausteinaufrufe (FUP).

Siemens Leitfaden: https://support.industry.siemens.com/cs/ww/de/view/109756737

Wir verwenden meistens die SEW Movidrive MDX 90A Serie zum einfachen Positionieren der Motoren, welche über Profinet angesteuert werden.

Das war eine kurze Zusammenfassung über unser System, falls weitere Fragen noch vorhanden sind, könnt ihr sie gerne stellen.


Nun zu meiner Frage:

Also wir verwenden Hauptsächlich Schrittketten, damit wir einen bestimmten Ablauf haben können, jedoch habe ich gesehen, dass es auch möglich ist, nur mit Sensoren und Positionen von den Servoachsen die ganze Anlage zu programmieren ohne eine Schrittkette. Dadurch fand ich es einfacher für einen unwissenden, im Fehlerfall die Achsen auf einen position manuell zu fahren und die Anlage kann weiter gestartet werden. Ich als aussenstehende musste dadurch nicht in die Software schauen, auf welchem Schritt wir uns befinden und konnte nur durch das Sehen den Fehler erkennen und weiter machen.

Gibt es einen Leitfaden oder eine gute Dokumentation, wie man eine komplexe Anlage so aufbauen kann als Alternative zu den Schrittketten? Haben sie irgend welche Nachteile?

Einer der letzten Anlagen hatten ca. 25 Servoachsen mit einem Absolutgeber und 25 Frequenzumrichter. Ca. 200 Sensoren und 100 Ventile / Zylinder waren z.B. verbaut.

Ich freue mich sehr auf eure Antworten.

 

[Ralle]

Ich war früher einmal ein einer Firma beschäftigt, da haben wir das auch so programmiert. Das war noch zu S5-Zeiten, Graph etc. kostete damals Geld und SPS-Performance.
Das Programmieren einer Zustandsgesteueren Anlage (so nenne ich das mal) ist m.E. nach aufwendiger, einen Standard oder eine Vorlage dafür kenne ich nicht, außer dem, was wir damals so gemacht haben.

Im Grund war das Prinzip folgendermaßen:

Für Jeden Aktor und für jede Endlage wurdeen zwei Zustände (Damals Merker pogrammiert.
1. Hubwerk ist gesenkt (ohne Ausgang des Aktors Aktors).
2. Hubwerk steht gesenkt (mit Ausgang des Autors).

Selbiges für gehoben etc.

Dann gab es für jede Bewegung einen Merker:

Hubwerk Heben/Senken.
Dieser Merker war ein R/S-Merker, wobei für heben und senken jeweils ALLE Startbedingungen angegeben werden mußten.
Es gab jeweils einen Automatik- und einen Handzweig.

Bsp HW Heben/Senken:
Das Hubwerk sollte in Automatik heben, wenn ein Karton am Platz war, die Horizontalachse vorn oder hinten stand.
(Nur mal schnell so aus dem Kopf)

U(
U(
U Automatik
U #Karon_vorhanden
U #Hubwerk_steht_gesenkt
U (
O Horizontal_steht vorn
O Horizontal_steht_hinten
)
)
O
U(
U Hand
U HAND_heben
U (
O Horizontal_steht vorn
O Horizontal_steht_hinten
)
)
)
U Anlage_ist_Ein
U Not_Aus_ist Frei
S M 10.0    (Hubwerk HEBEN/SENKEN)
NOP 0
U(
U(
U Automatik
UN # Karton vorhanden
U #Hubwerk_steht_gehoben
U (
O Horizontal_steht vorn
O Horizontal_steht_hinten
)
)
O
U(
U Hand
U HAND_senken
U (
O Horizontal_steht vorn
O Horizontal_steht_hinten
)
)
)
U Anlage_ist_Ein
U Not_Aus_ist Frei
R M 10.0    (Hubwerk HEBEN/SENKEN)
NOP 0

Weiterhin gab es dann den Ausgangszweig, in welchem der Aktor geschalten wurde, Darin waren sämtliche Freigabe/Sperren etc. enthalten, die den Aktor auch im Fehlerfall abschalten.

Fehlermeldungen, wei Zeitüberwachung, gleichzeitiges schalten von Inputs etc.

Nachteil:
Das Ganze wird recht schnell komplex, wenn viele Aktoren ineinandergreifen.

Vorteil:
Man konnte per Hand die Anlage irgendwie stellen, bei Einschalten der Automatik lief sie korrekt weiter.
Es gab auch Fälle, da war das nicht erwünscht --> Halt und Fehlermeldung.

Ich mache jetzt seit vielen Jahren nur noch Schrittketten und empfinde das als wesentlich strukturierter, einfacher und vor Allem schneller umzusetzen.
Insbesondere, wenn unterschiedliche Varianten/Abläufe/Rezepte benötigt werden, ist das in einer Schrittkette einfacher.
Schrittketten programmieren wiir aber auch so, dass nach einer Grundstellungsfahrt da weitergemacht wird, wo es logischerweise weitergehen muß, also nichts per Hand irgendwie gestellt werden muß!

 

[codemonkey]

Zuviel Werbung?
-> Hier kostenlos registrieren

....

Ich mache jetzt seit vielen Jahren nur noch Schrittketten und empfinde das als wesentlich strukturierter, einfacher und vor Allem schneller umzusetzen.
Insbesondere, wenn unterschiedliche Varianten/Abläufe/Rezepte benötigt werden, ist das in einer Schrittkette einfacher.
Schrittketten programmieren wiir aber auch so, dass nach einer Grundstellungsfahrt da weitergemacht wird, wo es logischerweise weitergehen muß, also nichts per Hand irgendwie gestellt werden muß!

Handhabe es genauso, wie es Ralle beschrieben hat. Neben den Sensoren und Aktoren kommt es je nach Anlage auch noch auf den Prozessfortschritt an. Bauteil bereits geklebt, verschraubt, verpresst, usw. ja/nein

Dieser zustandsabhängige Ablauf den @DeBa anspricht war doch im Prinzip HiGraph, oder irre ich mich?

 

[Sir Steel]

Ich persönlich bevorzuge die Zustandsprogrammierung gegenüber den Schrittketten. Mir sind die Schrittketten bei komplexeren Prozessen mit mehreren Abzweigen und Sprüngen zu unübersichtlich.

Für mich steht im Kern der Zustandsprogrammierung eine Datenhaltung für alle Bauteile die in der Anlage sind. Da muss man sich den Bearbeitungszustand merken und beim Transport der Teile die Daten entsprechend mit schieben.
Bei Schrittketten wird das manchmal gern vernachlässigt, da es in der Abarbeitung der Schritte bereits enthalten ist.

Eine Dokumentation kann ich leider nicht anbieten, es hängt natürlich von der Anlage und dem Prozess ab wie man da ran geht.

Ich denke der Nachteil ist, das man mehr Hirnschmalz reinstecken muss um z.B. anhand eines PAPs eine Zustandsprogrammierung zu erstellen.
Wie in deinem Beispiel mit 25 Servoachsen muss man sich schon reichlich Gedanken machen, wie man die Achsen gegeneinander verriegelt, wann welche Sollposition angefahren werden soll und wie man das priorisiert damit keine Totalverriegellung auftritt.

Grundstellungsfahrt braucht man dafür keine, Problem beheben, Automatik Start und weiter gehts

 

[ducati]

Grundsätzlich sind so meine Erfahrungen, dass Maschinenbau/Fertigungsautomatisierung eher in Schrittketten denkt, Prozessautomatisierung eher in logischen Verknüpfungen/Zustandsprogrammierung.

diesen Spaghetticode:

U(
U(
U Automatik
U #Karon_vorhanden
U #Hubwerk_steht_gesenkt
U (
O Horizontal_steht vorn
O Horizontal_steht_hinten
)
)
O
U(
U Hand
U HAND_heben
U (
O Horizontal_steht vorn
O Horizontal_steht_hinten
)
)
)
U Anlage_ist_Ein
U Not_Aus_ist Frei
S M 10.0    (Hubwerk HEBEN/SENKEN)
NOP 0
U(
U(
U Automatik
UN # Karton vorhanden
U #Hubwerk_steht_gehoben
U (
O Horizontal_steht vorn
O Horizontal_steht_hinten
)
)
O
U(
U Hand
U HAND_senken
U (
O Horizontal_steht vorn
O Horizontal_steht_hinten
)
)
)
U Anlage_ist_Ein
U Not_Aus_ist Frei
R M 10.0    (Hubwerk HEBEN/SENKEN)
NOP 0

Würde man aber heute so nicht (mehr) machen.

Da gäbe es einen (mehrfach verwendbaren) Baustein für jeden Aktor, der z.B. die Eingänge Verriegelung, Automatik_EIN, Hand/Auto, Hand_Ein sowie einen Ausgang für den Aktor besitzt. Dann ist das auch überhaupt nicht kompliziert/verwirrend...

Umfangreiche Schrittketten würde ich, wenns nach mir geht, nicht mehr händisch mit S/R ausprogrammieren, sondern dafür ein graphisches Tool wie Graph oder SFC oder... benutzen...

 

[ioStart]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich denke der Nachteil ist, das man mehr Hirnschmalz reinstecken muss um z.B. anhand eines PAPs eine Zustandsprogrammierung zu erstellen.
Wie in deinem Beispiel mit 25 Servoachsen muss man sich schon reichlich Gedanken machen, wie man die Achsen gegeneinander verriegelt, wann welche Sollposition angefahren werden soll und wie man das priorisiert damit keine Totalverriegellung auftritt.

Hirnschmalz ist ja eine tolle Sache und als Programmierer kann man das ja auch als Herausforderung sehen.
Ich sehe bei SPAGETTICODE vor allem einen Nachteil darin, dass der Programmierer während des Programmierens weiß was er tut und bezweckt, nach ihm aber niemand mehr im Stande ist, die boolsche Algebra im Kopf wirklich zu realisieren. Weil, und das ist mir ein wichtiger Punkt: bei SPS-Programmen wird die Architektur und vor allem die Überlegungen die dahinter stehen, nur in selten Fällen dokumentiert.
Was uns betrifft: AWL wird nur mehr in einfachen, für jeden verständlichen Fällen verwendet.
Ansonsten kommt bei klaren Abläufen GRAPH zum Einsatz und Schieberegister und ähnliches SCL

 

[ducati]

Ich sehe bei SPAGETTICODE vor allem einen Nachteil darin, dass

Spagetticode ist ja/nein hat ja nix mit der Frage Schrittkette ja/nein zu tun...

Wir (in der Prozessautomatisierung) haben für jeden Aktor erstmal einen mehrfach verwendeten Baustein, der intern alles abhandelt, was man so braucht (Überwachungen, Hand/Auto Umschaltung, HMI-Anbindung...) Extern beschalten wird daran nur, wann er Verriegelt ist bzw. wann er über Automatik EIN sein soll, sowie der DA wird drangeschaltet...

Wenn wir Schrittketten benutzen (müssen) kommt an den Automatikeingang halt die jeweilige Schrittnummer dran, wann der Aktor EIN sein soll.

 

[ioStart]

wie der Themenstarter schreibt, sucht er nach Alternativen zu Schrittketten.
Denke, dass die Umsetzung der Abläufe ohne den Einsatz von Schrittketten komplexer wird.
Wenn jedoch eine gezielte Planung im Vorfeld erfolgt, kann einiges an WirrWarr vermieden werden. Ich denke dabei an klare Formulierungen warum was wie gemacht werden soll und wie die Umsetzung erfolgt.

Leitfaden zu diesem Thema ist mir auch keiner bekannt.

Wenn wir Schrittketten benutzen (müssen) kommt an den Automatikeingang halt die jeweilige Schrittnummer dran, wann der Aktor EIN sein soll.

machen wir ähnlich. Nur dass der Automatikbefehl direkt in der Schrittkette gesteuert wird.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

machen wir ähnlich. Nur dass der Automatikbefehl direkt in der Schrittkette gesteuert wird.

ja, das hat den Vorteil, wenn Schritte hinzugefügt werden, muss man nur an einer Stelle, an der Schrittkette anpassen. Dafür sieht man aber am jeweiligen Aktor nicht, wann und ob und wieso der geschalltet wird...

 

[codemonkey]

Grundsätzlich sind so meine Erfahrungen, dass Maschinenbau/Fertigungsautomatisierung eher in Schrittketten denkt, Prozessautomatisierung eher in logischen Verknüpfungen/Zustandsprogrammierung.
...

Das mit dem Maschinenbau kann gut möglich sein, gerade wenn noch Subsysteme wie Roboter ins Spiel kommen, ist es leichter, die Abfolge der Jobs festzulegen und eine Rückzugsstrategie zu programmieren, wie der Roboter aus der Vorrichtung im Störfall auch wieder rauskommt, ohne einen Experten zu brauchen, der einen Roboter von Hand verfährt.

 

[Sir Steel]

Spaggetiecode kann man auch mit Schrittketten programmieren, das hat mit Zustandsprogrammierung nichts zu tun.

Das man inzwischen diese AWL Monster vermeidet sollte ja soweit klar sein. Wir Arbeiten meistens in KOP, da kann man bei der Diagnose am schnellsten sehen wo Signale fehlen.
AWL nutzen wir nur für einfache Zuweisungen, da es am wenigsten Platz benötigt
SCL wird vorwiegend zur Datenverarbeitung verwendet

Gerade in der Interaktion mit Robotern finde ich die Zustandsprogrammierung besser. Der Roboter arbeitet ja selbst bereits als Schrittkette, da muss ich in der SPS nicht noch eine oben drauf legen.
Der Klassiker bei der IBN ist ja das Roboterprogrammierer in die Zelle gehen, den Roboter in Hand verfahren und ggf. auch Aktoren in Hand verfahren um Teile zu holen oder abzulegen.
Die Handshakes zum Roboter Arbeitsfertigmeldung, Stellungsfreigaben funktionieren in der Zustandsprogrammierung weiterhin sodass, man den Roboter und die Anlage einfach in Automatik stellen kann und weiter gehts.

Die Schrittketten haben das Problem stehen zu bleiben wenn die Zelle offen ist / Automatik Aus ist. Da muss man das Datenhandling manuell nachziehen, in der Schrittkette einige Punkte weiter springen bevor man wieder Starten kann. Setzt voraus das derartige Manipulationsmöglichkeiten überhaupt vorgesehen sind, ansonsten kann man nur eine Grundstellungsfahrt durchführen und von vorn Starten.

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

diesen Spaghetticode:

U(
U(
U Automatik
U #Karon_vorhanden
U #Hubwerk_steht_gesenkt
U (
O Horizontal_steht vorn
O Horizontal_steht_hinten
)
)
O
U(
U Hand
U HAND_heben
U (
O Horizontal_steht vorn
O Horizontal_steht_hinten
)
)
)
U Anlage_ist_Ein
U Not_Aus_ist Frei
S M 10.0    (Hubwerk HEBEN/SENKEN)
NOP 0
U(
U(
U Automatik
UN # Karton vorhanden
U #Hubwerk_steht_gehoben
U (
O Horizontal_steht vorn
O Horizontal_steht_hinten
)
)
O
U(
U Hand
U HAND_senken
U (
O Horizontal_steht vorn
O Horizontal_steht_hinten
)
)
)
U Anlage_ist_Ein
U Not_Aus_ist Frei
R M 10.0    (Hubwerk HEBEN/SENKEN)
NOP 0

Würde man aber heute so nicht (mehr) machen.

Nein, würde man nicht machen, wenn man es umschaltet hat man ja auch KOP oder FUP, das kann das Forum aber nicht.
Als Erklärung sollte es aber reichen, wenn man eine Zustandgesteuerte programmierung will!
War nur zur Erläuterung mal eben aus dem Kopf notiert.

PS @ducati : Wer SPS-Code lesen kann ist klar im Vorteil, wer genau hinsieht, erkennt auch den KOP/FUP-Code!

 

[Thomas_v2.1]

Wird so eine Zustandsprogrammierung komplexer, wird es aber immer schwerer alle möglichen Zustände wirklich vollständig zu erfassen und entsprechend darauf zu reagieren. Der Vorteil bei einer Schrittkette ist zudem, dass für einen Außenstehenden viel schneller ersichtlich ist, was gerade passiert, und auf was gewartet wird. Außerdem lässt sich bei Bedarf die Schrittkette anpassen, ein Schritt einfügen oder löschen. Das wird bei einer Zustandsprogrammierung bei allem was über eine Hand voll Signale hinausgeht schon aufwändiger. Die schlechte Wart- und Nachvollziehbarkeit der Zustandsprogrammierung ist meiner Meinung nach auch der Grund, warum eben Schrittketten in vielen Fällen die bessere Wahl sind.

Ich hatte mal ein S5-Programm in Zustandsprogrammierung umzusetzen, was bisher über ein klassisches Mosaikschaltbild mit etlichen Schaltern gesteuert wurde. Der Bediener hat mir das alte Programm vorgeführt, und dann wie ein wilder beim Anfahren der Anlage an den Schaltern gedreht, und die Steuerung / Automatik hat immer passend darauf reagiert. Das war schon beeindruckend. Aber auch da gab es Fälle wo der Bediener sagte: "Ja wenn das und das passiert, dann bleibt das Programm schon mal hängen und ich muss da auch nochmal schalten um das Zurückzusetzen."

 

[ducati]

Ja wenn halt eine Abfolge mit x Schritten für z.B. das Anfahren notwendig ist, dann macht halt auch ne Schrittkette Sinn.
Wenn ich aber nur auf Freigaben warten muss, z.B. Pumpe wartet dass Klappe auf ist, dann kann man das auch mit logischen Verknüpfungen machen.
Wenns aber unter 5 Schritten ist, bau ich eher nie ne Schrittkette. Kommt aber auch drauf an, wie gut der "Programmierstandard" incl. HMI mit Schrittketten zurecht kommt.

 

[Sir Steel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Frage ist wo du die Komplexität siehst bei Zustandsprogrammierung.
Die Gesamtanlage mag im ersten Moment komplex ausehen wenn da z.B. viele Roboter, mehrere Bauteile bearbeiten. Aber wenn man das runterbricht und jede Station für sich betrachtet und die Handshakes zu den Nachbarn bleibt die Übersicht vorhanden.

Wenn ich mir da überlege bei Komplexen Anlagen zig Schrittketten für Parallelprozesse erstellen zu müssen und diese aufeinader abzustimmen das die nie hängen bleiben, da läuft mir ein kalter schauer über den Rücken.
Dann noch die ganzen Initial Fälle betrachten zum wiedereinstieg nach Störung/ Grundstellungsfahrt weil man eben nicht alle Teile aus der Anlage entnehmen möchte

Natürlich kenne ich auch Beispiele aus Umbauten wo Zustandsprogrammierung versaut wurde, ebenso aber auch Beispiele für schlechte Schrittketten. Da kann ich nicht auf S5 zugreifen so alt waren meine Anlagen noch nie

 

[Ralle]

Die Frage ist wo du die Komplexität siehst bei Zustandsprogrammierung.

Also ich hab beides an Maschinen gemacht, inkl. Programmierung und IBN vor Ort.
Es gibt immer Vor- und Nachteile, aber ich denke Schrittketten liegen in Übersichtlichkeit für Programmierer und Bediener am HMI weit vorne.
Auch das Einbringen von Änderungen (zusätzliche Station, andere Hardware inkl. Beschaltung und Ansteuerung) ist bei Schrittketten schneller und einfacher, mit weniger Fehlern zu realisieren.
Aber wie immer natürlich, Außnahmen bestätigen die Regel

 

[PN/DP]

Wenn ein Programm mit Zustandsprogrammierung von einem anderen Programmierer programmiert wurde, und wie üblich "sparsam" dokumentiert und kommentiert ist, dann braucht man für die Analyse und Einbringung einer kleinen Änderung manchmal 2 Tage, und ist trotzdem nicht ganz sicher, ob sich die Änderung nicht auch in ungewollten Situationen auswirkt.

Bei Schrittketten kann man eine Änderung viel schneller realisieren und ist sich dann sicher, daß die Änderung auch wirklich nur in der gewollten Situation wirkt.

Harald

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es gibt immer Vor- und Nachteile, aber ich denke Schrittketten liegen in Übersichtlichkeit für Programmierer und Bediener am HMI weit vorne.

wenn es denn überhaupt eine ordentliche Visualisierung der Schrittkette gibt...

Auch das Einbringen von Änderungen (zusätzliche Station, andere Hardware inkl. Beschaltung und Ansteuerung) ist bei Schrittketten schneller und einfacher, mit weniger Fehlern zu realisieren.

wenn die Schrittkette händisch per Setze Rücksetze Timer ausprogrammiert ist, dann wird das mit dem Einfügen von Schritten auc nicht so leicht... vorallem wenn man nicht so recht überschaut, wer dann wo warum auf Schrittnummern zugreift...

Meine Bedenken gehen bei Schrittketten eher in die Richtung, dass die häufig hängen bleiben, warum auch immer... Aber wie gesagt, ich mach halt nur Prozessautomatisierung, im Maschinenbau/Fertigungsautomatisierung sind die Anforderungen etwas anders...

 

[ducati]

Wenn ein Programm mit Zustandsprogrammierung von einem anderen Programmierer programmiert wurde, und wie üblich "sparsam" dokumentiert und kommentiert ist, dann braucht man für die Analyse und Einbringung einer kleinen Änderung manchmal 2 Tage, und ist trotzdem nicht ganz sicher, ob sich die Änderung nicht auch in ungewollten Situationen auswirkt.

Naja, wenn ich am Aktor 7 irgendwelche Bedingungen verändere, wirken die sich auch nur auf Aktor 7 aus...

Bei Schrittketten kann man eine Änderung viel schneller realisieren und ist sich dann sicher, daß die Änderung auch wirklich nur in der gewollten Situation wirkt.

glaub wir haben unterschiedliche Vorstellungen von Zustandsprogrammierung und Schrittketten

 

[MFreiberger]

wenn es denn überhaupt eine ordentliche Visualisierung der Schrittkette gibt...

wenn die Schrittkette händisch per Setze Rücksetze Timer ausprogrammiert ist, dann wird das mit dem Einfügen von Schritten auc nicht so leicht... vorallem wenn man nicht so recht überschaut, wer dann wo warum auf Schrittnummern zugreift...

Meine Bedenken gehen bei Schrittketten eher in die Richtung, dass die häufig hängen bleiben, warum auch immer... Aber wie gesagt, ich mach halt nur Prozessautomatisierung, im Maschinenbau/Fertigungsautomatisierung sind die Anforderungen etwas anders...

Ja, deswegen setzen wir bei Schrittketten auf Graph (wir programmieren mit TIA). Da ist das Einfügen, Löschen oder Ändern von Schritten, Transitionen und Verzweigungen (Parallel oder Simultan) ziemlich einfach.