TIA Programmstruktur

Zuviel Werbung?
-> Hier kostenlos registrieren
glaub wir haben unterschiedliche Vorstellungen von Zustandsprogrammierung und Schrittketten ;)
Ich habe meine Erfahrung aus dem Maschinenbau, wo z.B. mehrere Achsen kreuz und quer fahren und sich gegenseitig in die Quere kommen. Da kann sich auch (unvorhergesehen) derselbe Zustand/Stellung der Aktoren in verschiedenen Situationen einstellen und darf dann nicht gleich behandelt werden. Meine Erfahrung: ein komplexes Programm mit Zustandsprogrammierung enthält potentiell mehr Fehler als ein Programm mit Schrittketten.

PS: unvorhergesehene Situationen führen bei Schrittketten meistens zum Stillstand einer Maschine, bei Zustandsprogrammierung führen sie meistens zu einem Crash, oft mit Maschinenschaden und Produkt versaut.

Harald
 
Zuletzt bearbeitet:
glaub wir haben unterschiedliche Vorstellungen von Zustandsprogrammierung und Schrittketten ;)
Also die Zustandsprogrammierung ist stark von der Maschine/Anlage abhängig. Bei Schrittketten ist das Grundgerüst immer das selbe. Also für Änderungen muss man bei der Zustandsprogrammierung eine Maschine/Anlage detailliert verstehen. Bei Schrittketten nur diesen einen Schritt (ggf. noch vorhergehenden/nachfolgenden Schritt).
Wenn man die Anlagen einer Branche prinzipiell verstanden hat, kann man die Zustandsprogrammierung auch einfacher umsetzen.

Ich programmiere RBGs/Fördertechnik. Abfüllanlagen, Produktionsprozesse, Wärmebehandlung, Spritzgußmaschinen, Holzverarbeitung, ... ist nicht mein Metier.

VG
MFreiberger
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
ja, hab ich ja weiter oben auch schon geschrieben, dass es bei Schrittketten am besten ist, nen Tool zu verwenden...

Ich setzte für alle Aktoren halt Standardbausteine ein, wo intern schonmal alles mögliche zu dem jeweiligen Aktor abgehandelt wird. In diesen Baustein schaut normal niemand rein. Von aussen wird der Baustein mit Verriegelungen bzw. Automatikfunktionen beschaltet, oder auch ne Schrittnummer dran, wenn der aktor in nem bestimmeten Schritt Ein sein soll...

Das ist jetzt nicht wirklich verwirrend.

Schrittketten nutze ich nur, wenns auch längere Abläufe git, die nacheinander ablaufen (müssen)...
 
Bei Schrittketten nur diesen einen Schritt (ggf. noch vorhergehenden/nachfolgenden Schritt).
wenn ich Vorgaben für Schrittketten von dem Verfahrenstechniker bekomme, sind die in der Regel ziemlich mies... Da wird dann in Schritt 10 auf ne Rückmeldung von Pumpe 3 gewartet, die niemals vorher eingeschaltet wurde... Wenn ich da nicht die Anlagenzusammenhänge verstehe, krieg ich die Schrittkette nie so angepasst, dass die Anlage jemals losläuft.
Bei "Zustandsprogrammierung" läuft per se ja erstmal alles, was nicht expliziet verriegelt ist...
Wenn man die Anlagen einer Branche prinzipiell verstanden hat, kann man die Zustandsprogrammierung auch einfacher umsetzen.
Ohne Prozessverständnis geht bei uns per se garnichts...
 
Ohne Prozessverständnis geht bei uns per se garnichts...
Genau das meine ich ja.
Aber für Schrittketten braucht man IMHO weniger Detailwissen um die Abhängigkeiten. Man muss einen parallel ablaufenden Prozess vielleicht nicht unbedingt verstehen. In der Zustandsprogrammierung können Parallelprozesse aber (stärker) zu Problemen führen, weil es stärkere Abhängigkeiten untereinander gibt.

Keiner sagt, dass das Eine (Schrittketten) geht und das Andere (Zustandsprogrammierung) zu verwerfen ist. Beides hat so seine Vor- und Nachteile. Aber, wie @PN/DP schon schrieb, ist die Schrittkettenprogrammierung bei Änderungen weniger Fehleranfällig, weil Zustände, die erstmal die gleichen Eingangsinformationen enthalten nicht zu einer Aktion an einer anderen Stelle führen, da der vorhergehende Schritt erstmal gesetzt sein muss. Damit erhält man in der Schrittkettenprogrammierung eine Zusatzinformation. Nämlich an welcher Stelle man sich im Programm befindet. Diese Information hat man in der Zustandsprogrammierung nicht. Da der Zustand der Anlage ggf. an mehreren Programmstellen abgefragt wird und es ist nicht klar (oder muss über andere Kniffe realisiert werden) an welcher Stelle man sich im Programm befindet.

Ergo:
Schrittkette => enthält eine Zusatzinformation darüber, wo man sich im Programm befindet.
Vorteil: Es braucht keine weiteren Entscheidungskriterien
Nachteil: Wenn man (nach Reset, Ein-/Ausschalten, ...) an eine andere Programmstelle springen will, ist das schwieriger umzusetzen.

Zustandsprogrammierung => Wo man sich im Programm befindet ist von der Eingangsbeschaltung abhängig
Vorteil: Man kann aus jeder Anlagensituation heraus "richtig" starten
Nachteil: Wenn mehrere Programmstellen auf die gleiche Eingangsbeschaltung reagieren, gibt es Probleme

Bei der Schrittkette braucht man sich nur um die Eingangsbeschaltung zu dem jeweiligen (neu einzufügenden) Schritt Gedanken machen. Bei der Zustandsprogrammierung muss man sich Gedanken machen, ob die angefragte Eingangsbeschaltung sonst schon irgendwo im Programm verwendet wird. Wenn ja, muss man weitere Entscheidungskriterien entwickeln (und auch noch an der anderen Stelle einfügen, mit der man eigentlich gar nichts zu tun hat(te)).

VG

MFreiberger
 
Zuletzt bearbeitet:
Aber für Schrittketten braucht man IMHO weniger Detailwissen um die Abhängigkeiten. Man muss einen parallel ablaufenden Prozess vielleicht nicht unbedingt verstehen.
Das verstehe ich nicht... wenn die Maschine Quatsch macht, musst Du doch irgendwie verstehen, warum da jetzt in welchem Schritt welcher Quatsch passiert ist und dann auch noch im richtigen Schritt die richtigen Änderungen machen, damit beim nächsten Probelauf nicht wieder die Milchtüten durch die Halle fliegen...
Ich seh da jetzt im Prozessverständnis nicht unbedingt nen Vorteil.
 
Das verstehe ich nicht... wenn die Maschine Quatsch macht, musst Du doch irgendwie verstehen, warum da jetzt in welchem Schritt welcher Quatsch passiert ist und dann auch noch im richtigen Schritt die richtigen Änderungen machen, damit beim nächsten Probelauf nicht wieder die Milchtüten durch die Halle fliegen...
Ich seh da jetzt im Prozessverständnis nicht unbedingt nen Vorteil.
Genau: Wenn in einem Schritt (einer bestimmten Programmposition) Quatsch passiert, muss ich genau in diesen Schritt gucken.

In der Zustandsprogrammierung kann der Quatsch theoretisch von überall im Programm kommen. Da muss ich den gesamten Prozess überblicken, damit weiß wo ich gucken muss. Wenn jetzt, wegen Sensordefekt ein Zustand eintritt, der an der erwarteten Programmstelle fehlerhaft ist, aber an einer anderen Programmstelle einen gültigen Zustand beschreibt, muss ich überlegen, woran es liegen kann und suche ggf. erstmal an der falschen Stelle.
Bei der Schrittkette kann ich mir merken, bei welchem Schritt ich rausgeflogen bin oder direkt sehen, an welchem Schritt es nicht weitergeht.

Ergo:
Prozessverständnis ist immer wichtig. Aber für die Fehlersuche brauche ich bei der Zustandsprogrammierung auch den Überblick über den Gesamtprozess. In der Schrittkettenprogrammierung komme ich auch zurecht, wenn ich nur einen Teilprozess verstehe.

VG

MFreiberger
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Was ich auch schon ein paar mal gesehen habe:
Da hat jemand Zustandsgesteuert programmiert.
Dann mussten aber halt bestimmte Aktoren nacheinander oder in Abhängigkeit zueinander angesteuert werden.
Also wurden dann Hilfsbits verwendet, die dann je nach Zustand gesetzt/rückgesetzt wurden.
Diese Hilfsbits hingen dann wieder an Bedingungen der Aktoren.
Was dann aber eigentlich logisch einem Ablauf (Schrittkette) entsprach.
Nur halt, eine "dreckig" programmierte Schrittkette.
 
Naja 😉
Woher weisst Du, nachdem die Milchtüten durch die Halle geflogen sind, dass es am Schritt 58 gelegen hat?

Wenn bei mir nen Behälter leer ist, oder überläuft, Weiss ich dass es wohl an der Zuförderpumpe liegen wird. Da schau ich mir halt im Netzwerk für die Zuförderpumpe an. Was da am Automatikeingang dranprogrammiert ist 😉
 
Was ich auch schon ein paar mal gesehen habe:
Da hat jemand Zustandsgesteuert programmiert.
Dann mussten aber halt bestimmte Aktoren nacheinander oder in Abhängigkeit zueinander angesteuert werden.
Ja, wenn man halt mehr als 5 Schritte hat, die wirklich nacheinander passieren müssen, dann macht ja auch ne Schrittkette Sinn 😉
Oft müssen aber die Dinge auch garnicht wirklich nacheinander passieren...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Naja 😉
Woher weisst Du, nachdem die Milchtüten durch die Halle geflogen sind, dass es am Schritt 58 gelegen hat?
Unsere Standard Schrittkette(SCL bzw. ST) (wenn keine grafische Sprache verwendet werden soll/will/kann) besitzt eine Schritthistorie. Da kann ich die letzten x Schritte anschauen. Mit Bezeichnung, Schrittnummer und Dauer.
Ja, wenn man halt mehr als 5 Schritte hat, die wirklich nacheinander passieren müssen, dann macht ja auch ne Schrittkette Sinn 😉
Oft müssen aber die Dinge auch garnicht wirklich nacheinander passieren...
Das musst du nicht mir sagen ;)
Ich wollte damit auch nicht sagen das Schrittkette immer die bessere Wahl ist.
Du hast aber bestimmt auch schon so Konstrukte gesehen.
 
Naja 😉
Woher weisst Du, nachdem die Milchtüten durch die Halle geflogen sind, dass es am Schritt 58 gelegen hat?
Unsere Standard Schrittkette(SCL bzw. ST) (wenn keine grafische Sprache verwendet werden soll/will/kann) besitzt eine Schritthistorie. Da kann ich die letzten x Schritte anschauen. Mit Bezeichnung, Schrittnummer und Dauer.
Das sieht bei uns ähnlich aus. U.a. werden bei Störungen (und nur dann werden die SK verlassen), die Schrittnummer in die Störmeldung hineingeschrieben.


Wenn bei mir nen Behälter leer ist, oder überläuft, Weiss ich dass es wohl an der Zuförderpumpe liegen wird. Da schau ich mir halt im Netzwerk für die Zuförderpumpe an. Was da am Automatikeingang dranprogrammiert ist 😉
Da sind wir wieder: Dir ist klar (Weil Du den Prozess kennst), dass es an der Zuförderpumpe liegt. Mir wäre das nicht klar. Kann ja auch am Abfluss liegen. 🤷‍♂️

Aber, wie gesagt: ich sehe ja die Vorteile einer Zustandsprogrammierung.

Beide Programmierarten haben ihre Berechtigung.
Im Fall des Themenstarters würde ich eine Schrittkette bevorzugen.
Im Fall einer Zuförderpumpe wäre mir jetzt nicht klar, wie man sinnvoll eine Schrittkette implementieren würde (es sei denn, dass sich entsprechende Schritte wiederholen würden). Hier arbeitet die Zuförderpumpe wohl wahrscheinlich bedingt autark und regiert nur auf den Füllstand und hat ggf. noch eine Freigabe (es wird gerade nichts entnommen, etc.)?

VG

MFreiberger
 
Na stell Dir mal ne Heizungspumpe zu Hause vor... Da baut auch niemend zum Einschalten oder Ausschalten ne Schrittkette, die minütlich durchläuft und prüft, wie kalt es draussen ist, ob der STB ausgelöst hat oder die Sicherung noch drin ist oder wie warm es im Wohnzimmer ist oder sonstwas.
Das sind alles fixe logische statische Verknüpfungen. In der Prozessautomatisierung ist halt das allermeiste so ähnlich.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das sieht bei uns ähnlich aus. U.a. werden bei Störungen (und nur dann werden die SK verlassen), die Schrittnummer in die Störmeldung hineingeschrieben.
Bei uns ist es so, dass es auch eine Störmeldung gibt, wenn z.B. die Zuförderpumpe ein Problem hat, z.B. weil der FU ne Störung ausgibt, oder Sicherungsfall, oder trotz ansteuerung keine Betriebsmeldung kommt, oder der Druck nicht stimmt oder der Durchfluss nicht stimmt oder nen Sensor nen Fehler hat usw... also wenn mal alles in Betrieb genommen ist, muss auch kein Mensch in der Software rumsuchen um nen Fehler zu finden...
 
Ich bin kein Gegner von dem Einen oder dem Anderen, sondern alles sind je nach Einsatz geeignete Mittel zum Zweck eine sauber und gut laufende Maschine zu erstellen oder zu optimieren.

Ich bin für allgemeine Abläufe grundsätzlich ein Freund von Zustandsprogrammierung, auch wenn für einen Zwischenschritt/Zustand/Abfolge eine eigene kleine Schrittkette zum Einsatz kommt.

Was in meiner Branche immer wieder eine Vorgabe ist, dass der Bediener manuell nach einer mechanischen Störung (Brett gebrochen, Stapelleiste eingeklemmt, Spreissel über Sensor, Pneumatik verklemmt etc pp) die Maschine nach Bedarf freifahren, Störung beseitigen und möglichst ohne "Initialfahrt" (oder am Besten ohne aufs HMI sehen zu müssen) einfach die Automatik wieder starten und dann der Ablauf wieder weiterfährt.
Wenn man das "global" in eine Schrittkette verpackt geht das natürlich, aber gut lesbar ist anders.

Was mir aber immer wieder auffällt, wenn ich eine "fremden" Maschine beobachte: Man erkennt zumindest bei Sondermaschinen relativ oft, auch ohne Blick ins Programm, wenn mit Schrittketten gearbeitet wurde, weil dann bestimmte Abläufe eher abgehackt und nicht "verschliffen" aussehen. Dieses "Verschleifen" von Bewegungen ( Wenn Freigabe von Folgeschritt ok + Achse 1 fast in Position, dann Start Aktor, anstelle von: Achse 1 - bremsen - steht in Position - Freigabe ok? -> Start Aktor) geht praktisch einfach besser mit Zustandsprogrammierung.
 
Ich denke, dass es stark auf die Aufgabenstellung ankommt. Bei vielen simplen Prozessen, welche nebeneinander laufen können ist Zustandsbasierte Programmierung super angenehm und auch nachvollziehbar. Vor allem wenn sich die Prozesse nicht gegenseitig schaden können.

Sobald eine Anlage aber komplexer wird, oder gar mechanische Abläufe eingehalten werden müssen, da sonst die Anlage zerstört wird, finde ich eine Schrittkette unabdingbar. Für den ersten Programmierer mag die Programmierung noch einfach sein. Aber im Lebenszyklus einer Anlage kommen gut und gerne an die 10-20 Programmierer und spielen Änderungen ein. Von den Instandhaltern fange ich erst gar nicht an^^...
Aus Unwissenheit werden dann irgendwann Daten von A nach B Rangiert und wieder zurück nach A um bloß nichts kaputt zu machen. Dann kommen noch 200 Handshakes dazu und schon hat so ein Projekt das dreifache an Inhalt wie noch zur BBÜ.

Ich hatte selber das Vergnügen in der Automobilindustrie 2 Jahre Lang Zustandsbasierte Anlagen, welche teilweise aus den 90er waren zu warten und zu ändern. Kennt ihr das Gefühl, wenn ihr nach einer 12 Stunden Schicht im Werk auf dem Heimweg seid und selbst das Aussuchen der Pizzeria fürs Abendessen zu anstrengend ist? So gings mir jedenfalls oft genug in der Zeit^^...

Meine persönliche Meinung zum Thema^^ ->
Alles was in kleinen Grüppchen parallel ohne Beeinträchtigung nebeneinander laufen kann -> Zustandsbasiert
Alles, was größer ist, oder wo etwas mechanisch zerstört werden kann -> Schrittkette

LG Flo
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Schon nach zwei Jahren zu beginn meiner Programmiertätigkeit (S5) musste ich erkennen,
dass bei komplexeren Aufgabenstellungen die Probleme von Verriegelungen und Timeout-Ctrl (Zeitüberwachungen)
die Lösung mittels Schrittketten die Sache Stark vereinfachte. Der Grund hierfür war das man die Problemstellungen
in einzelnen Sequenzen ausarbeiten konnte und für die Querverknüpfungen erst eimal Platzhalter verwenden konnte
die später Zusammengeschaltet wurden.
Zugegeben meine Anfänge lagen damals mehr in der Handlingsautomatisierung (Abläufe).

Mich störte dabei immer die Tatsache, dass Ausgänge direkt aus der Schrittkette gesteuert wurden.
Schon bald erfolgte der umstieg auf Ausgabehilfsmerker (Controls) mit deren Hilfe dann
über eine reine Logicverknüpfung der eigentliche Ausgang gesteuert wurde (incl. Basis-Sicherheitverriegelungen).
Dieses System wurde von mir im Wesentlichen beibehalten, jedoch wurde die einfache Augangslogic
durch Standartisierte Module (Eigenerstellung) ersetzt.
Es gibt also in meinen Programmen aktuell Verschiedene Kontrollmodule z.B.:
- Ventilmodul Pneumatik
- Ventilmodul Hydraulik
- Motromodul für Dehzahlsteuerung
- Servomodul SEW Gen. B/C
- Servomodul Sinamics
- Kameramodul Checker
- Kameramodul Keyence
u.v.m.

All diese Module haben fogende Geminsamkeiten
(unabhängig ob selbst erstellt [80%] oder Adaptiert):
- Gleicher Grundaufbau.
- Einheitliche Ansteuerschnittstellen (möglichst je nach Grundtyp).
- Integrierte Hand- bzw. Einrichtfunktionen.
(sowohl Listen als auch Direktstuerung).
- Integrierte Basisverriegelungen (Grundlegend).
- Adaption für die (Aktor-)Visualisierung.
- Optionsanwahl für verschiedene Unterfunktionen.
- Zeitmessung sofern sinnvoll.

Darüber hinaus gibt es je nach Funktionalität auch Unterschiedliche weitere Funktionen.

Nun ist es möglich eine neue Machine zuerst über die Einrichtfunktion komplett
vorzutesten und ggf. auch aktorabhängige Sensoren zu testen.
Erst danch wird die Automatikfunktion (Schrittketten) amgedockt und getestet.

Diese Vorgehensweise ist sehr Übersichtlich, rationell (Zeitsparend) und entspricht in
wesentlichen Teilen auch der von Siemens in Strukturschulungen vorgeschlsgenen
Vorgehensweise.

Im Prinzip wende ich diese und abgewandelte Module auch in der Prozesstechnik an,
mit dem Unterschied das Schrittketten als Overhead nur dann zum Einsatz kommen
wenn auch ein echter Schrittablauf erforderlich ist.
z.B. Einlege-/Entnahmegreifer, Ablauf eines komplexen Reinigungsprogrammes und
teilweise auch Anfahrkaskaden.

Dabei ist die Art der Schritkette im prinzip Geschmackssache
(Binär, Vektor, Statetype oder Graph etc.)

A.
 
Komm aus dem Sondermaschinenbau. Von Kunden die Noch ne Instandhaltung haben, wird zumindest bei uns meist ne Graph Schrittkette gefordert Teilweise mit Einsprechenden Anzeigen von WinCC, die Siemens per Prodiag zur Verfügung stellt für die Comfort Panels, um anzuzeigen, Wo die Schrittkette Steht mit Weiterschaltbedingungen etc.. (Das Das was bringt muss halt alles schön Kommentiert sein und Ja es gibt Kunden die Schauen ob jede Variable einen Kommentar hat und keine Tipp oder Rechtschreibfehler enthalten)

ne Schritkette die Hängt, Ohne Fehlermeldung, naja da Fehlt halt die Fehlermeldung und die Kann man automatisch generieren lassen.

Hab auch Anlagen die beides Verwenden, Gerade wenn Parallel und unabhängig vom Hauptablauf, in der Anlage Kleine Prozesse wie z.b. irgend ne kleine Vormontage notwendig ist.

Wie schon öfters gesagt beides hat vor und Nachteile.
 
Ich komme auch aus dem Sondermaschinenbau.
Ich meine Schrittketten in Graph sind für sich wiederkehrende Abläufe die beste Wahl. Auch zur Diagnose oder Meldungserzeugung eignen sich Graph-Sequenzen hervorragend.

Für z.B Spritzguss-Automatisierungen habe ich ebenso das OMAC-Modell eingesetzt und die Anlage entsprechend in Equipmentmodule (Anlagenteile) aufgeteilt. Als Controlmodule (Stationen) sind nur die Sequenzen/Abläufe, also die Graph-Ketten, für jede Station definiert.
Für jeden Mode (Production, Maintenance, DryRun,...) gibt es, falls notwendig eine Graph-Kette pro Station.
Die Schrittketten beinhalten die OMAC-States in richtiger Reihenfolge und die State-Complete Bits werden dann immer an entsprechender Stelle im Ablauf gesetzt. Jede Sequenz, also jede Station und dann auch die ganze Anlage befindet sich somit immer im gleichen Zustand.
 
Zurück
Oben