# Zustandsautomaten/ State Machine Steuerung



## Tmbiz (12 Oktober 2019)

Hallo Zusammen,

ich muss für einen Auftrag eine Maschine automatisieren. Diese Maschine soll Schuttgüter in Container füllen. Die alte Programmstruktur war, eher klassisch. Also FBs, welche die Ventile, Motoren usw Steuern und regeln. Dann entsprechende Schrittketten, welche je nach Betriebsmodus die einzelnen Aktoren in Abhängigkeit von Sensoren und Logik steuern und Regeln. 

Nun ist es so, dass die Software nun so aufgebaut werden soll, dass bestimmte Standards erfüllt werden. Das bedeutet, es könne sein, dass in der nächsten Maschine eine völlig andere Waage genutzt wird. Oder eine ganz andere FUs oder andere Komponenten. 

Daher ist meine Idee, alles nach dem System State Machine zu erstellen. Das bedeutet, es gibt z.B. eine State Machine für die Dosierung. Gleichgültig, welche Waage oder welche unterliegenden Komponenten verwendet werden. Genau so Motor Controller usw.

Mal als Idee, es gibt 4 State Machines welche als Waage eingesetzt werden können. Diese in intern völlig unterschiedlich aber alle könne die gleichen Befehle empfangen und identische Rückmeldungen geben. 
Mit andern Worten, einem Taxifahrer ist es egal ob er einen VW nutzt oder einen Skoda. Welche zwar völlig unterschiedlich sind (Dieses/ Benzin/ Marke) aber von der Bedienung ist alles identisch. 

Oder ein anderes Beispiel: dem Fahrer eines LKW ist es egal, ob hinter dem LKW ein Tiefkühler, ein Tieflader oder ein Holztransporter ist. Alle haben den Zweck etwas zu transportieren. 



An folgenden Punkten habe ich noch ein Verständnis Problem oder bitte ich mir ein paar Tipps zu geben.

a. Wie solle man die Steuerung einer State Machine aufbauen? Wenn ein solche Einheit z.B. einen bestimmten Ablauf ausführen muss, dann würde es doch ausreichen, einen Befehl zu senden "fahr in Grundstellung" und ab da nur noch den Befehl "next". Oder sollte man Befehle geben wir "fahren in Grundstellung" und dann "Zustand 1 ausführen" und dann "Zustand 2 ausführen" usw usw. Also sollte die Transaktion individuelle sein (ein Bool Eingang für jeden Schritt) oder ein Bool Eingang, welcher nur den Puls gibt um automatisch in den nächsten Schritt zu wechseln. 

Ich sehe den Nachteil darin, dass eine komplexes Interface aufwendig in der Verschaltung ist aber auch gut zu lesen. 

b. Was sind aus eurer Sicht die Vor und Nachteile wenn man als Befehl Zahlen übergibt. Also z.B. es gibt eine Variable als Kommando (int) 1=Fahre in Grundstellung; 2=Start Schritt A; 3=Start SchrittB usw. 
Das bedeutet, die State Machine erhält Befehle über einen Eingang, welche verschiedene Befehle in Form eine Zahl empfängt und gibt den Status auch in Form eine Zahl heraus. 1=Befehl erfolgreich ausgeführt; 2= Busy; 3= Error usw. 

Ich sehe den Nachteil, dass es eher etwas unübersichtlich ist wenn man einen Fehler sucht. Daher ist meine Idee, einen string zu übergeben. 'grundstell'= fahre in Grundstellung; 'SchrittA'= Start schritt A usw. Also anstelle einer Zahl wird eine Text übergeben. So wäre der Quelltext nicht so kryptisch und auch eine Servicetechniker kann das ganze noch lesen. 


Was denkt Ihr über diese Idee?


----------



## Blockmove (12 Oktober 2019)

Ein Zustandsautomat ist erstmal eigentlich nix anderes als eine Schrittkette.
Bzw. kann ich eine Schrittkette zu einem Zustandsautomaten erweitern.
Kein Mensch sagt, dass eine Schrittkette immer in Schritt 1 und Grundstellung starten muß.
Du kannst entweder mit mehreren Initialschritten arbeiten oder am Anfang alternativ verzweigen.

Ob nun Schrittkette, Zustandsautomat oder simple Verknüpfungssteuerung hängt von der Aufgabenstellung ab.

Wenn du einen Zustandsautomat baust, dann schau dir S7Graph oder bei Codesys AS an. Damit kannst du das ganze grafisch erstellen.
Irgendwelche Übergaben in Form von Zahlen oder Strings sind absolut wartungsunfreundlich.
Bis man da die jeweilige Verwendungsstelle findet, bekommt man bei komplexen Anlagen graue Haare.
Immer drand denken: Du schreibst das Programm nicht für dich, sondern für einen Kunden. 

Gruß
Blockmove


----------



## Tmbiz (12 Oktober 2019)

Ich würde gerne mal eure Meinung zu diesem Beispiel hören. Ja, die Informationen werden mit nur einer Variable übertragen also genau so wie "Blockmove" es nicht vorschlägt aber könnte man das ganze nicht durch eine übersichtliche Struktur gut lesbar machen?

Die Befehle laufen grundsätzlich immer nur zu einer Stelle und der Status kommt ja auch immer nur zu einer Stelle.


----------



## Blockmove (12 Oktober 2019)

Natürlich kannst du es so machen, doch ich sehe keinerlei Vorteile gegenüber einer Umsetzung in Graph.


----------



## Tmbiz (12 Oktober 2019)

Blockmove schrieb:


> Natürlich kannst du es so machen, doch ich sehe keinerlei Vorteile gegenüber einer Umsetzung in Graph.



Ah ok. Ich weiss was du meinst. Es geht mir gerade nicht um das "wie" der Logik. Sondern nur um das "wie" der Kommunikation der einzelnen Teilnehmer.


----------



## Blockmove (12 Oktober 2019)

Tmbiz schrieb:


> Ah ok. Ich weiss was du meinst. Es geht mir gerade nicht um das "wie" der Logik. Sondern nur um das "wie" der Kommunikation der einzelnen Teilnehmer.



Schon klar.
Ein ähnliches Verfahren wende ich manchmal auch an.
Ich habe für jede Kette (oder Statemachine) oder Station einen Global-DB mit entsprechenden Strukturen.
Wo es möglich ist, nutze ich aber Bits zur Kommunikation, da dies einfacher für die Diagnose / Instandhaltung ist.
Durch dieses System gewinnst du Flexibilität bei Erweiterungen oder Einsatz anderer Baugruppen.
Man muss halt schauen, ob diese zusätzliche Abstraktionsschicht wirklich Vorteile gegenüber einer hardwarenahen Programmierung bringt.


----------



## ADS_0x1 (14 Oktober 2019)

Hi Tmbiz,

wir machen in der Firma Statemachines nur bei einfachen Abläufen oder wenn Anlagenteile Autark arbeiten können. Alles andere in Schrittketten - das ist bei IB und IH nachher wesentlich einfacher nachzuverfolgen, wo du gerade stehst und warum es nicht weitergeht.
Das Ganze dann mit deiner Modularität der Komponenten ist doch recht easy zu lösen, dazu hat der liebe Gott (oder ein ihm nachfolgender Programmierer) etwas tolles erfunden, dass sich "Schnittstelle" nennt. 

In der Schrittkette selber prüfst du doch bspw. nur auf den Gewichtswert. Wie der zu Stande kommt, kann der Schrittkette doch komplett egal sein. Also legst du entweder einen Global-DB / GVL mit dem Wert an (_i_f_GewichtWaageX : REAL_) oder erweiterst deine Schrittkette um die entsprechenden IN /OUTS. Gleiches gilt für die Ansteuerung (_o_b_PumpeAn : BOOL_). Die Signale selber kommen dann von einem Ausgang / gehen an einen Eingang des Komponentenbausteins (fb_WaageMettlerToledo, fb_DanfossPumpe - sind jetzt nur Beispielnamen).

Damit kannst du die Schrittketten komplett neutral halten und die Komponente, die verwendet wird, ist komplett ega. Zusätzlicher Vorteil ist, dass du sämtliche Stati der Anlage für den Teil, der dich interessiert, in dem Global DB / GVL einsehen kannst. Zudem weißt du durch die Schrittkette immer, wo du im Moment stehst. TIA Graph ist da schon eine gute Wahl - das kann auch jeder IH'ler i.d.R.

Ansonsten programmieren wir bei TC2/TC3 die Schrittketten selber aus in ST. So grob hab ich das auch schon einmal hier gepostet.

Viele Grüße!


----------



## Blockmove (14 Oktober 2019)

ADS_0x1 schrieb:


> wir machen in der Firma Statemachines nur bei einfachen Abläufen oder wenn Anlagenteile Autark arbeiten können. Alles andere in Schrittketten - das ist bei IB und IH nachher wesentlich einfacher nachzuverfolgen, wo du gerade stehst und warum es nicht weitergeht.



Was ist eigentlich (bei euch) der Unterschied zwischen einer Statemachine und einer Schrittkette?


----------



## ADS_0x1 (14 Oktober 2019)

Blockmove schrieb:


> Was ist eigentlich (bei euch) der Unterschied zwischen einer Statemachine und einer Schrittkette?



Bei der Schrittkette sind die Bereiche Transitionen, Überwachung, Interlock, Aktionen (Eintritt, Austritt ...) und Verriegelungen sauber getrennt, sprich in verschiedenen Codebereichen, bei der Statemachine gibt es "nur" den State, indem quasi alles gemacht wird. 

Klingt irgendwie komisch, wenn ich das so beschreibe... also eigentlich wäre dann nach dieser Definition die Schrittkette eine Statemachine, bei der nur alles anders sortiert ist... :s15:


----------



## Blockmove (14 Oktober 2019)

ADS_0x1 schrieb:


> Klingt irgendwie komisch, wenn ich das so beschreibe... also eigentlich wäre dann nach dieser Definition die Schrittkette eine Statemachine, bei der nur alles anders sortiert ist... :s15:



Eben 

Deshalb ja die Frage 
Wenn ich zum Beispiel ein etwas komplexeres Handlingsportal programmiere, dann mache ich das in S7-Graph als Statemachine.
Geht wunderbar, denn es ist ein Trugschluß, dass eine Kette immer aus Grundstellung starten muß 

Gruß
Blockmove


----------



## Thomas_v2.1 (14 Oktober 2019)

Also ich persönlich bezeichne etwas als Schrittkette wenn es ein annähernd linearer Ablauf ist, eben z.B. ein Produktionsablauf an einer Maschine. D.h. es werden ggf. einzelne Sequenzen wiederholt oder Schritte parallel abgearbeitet, aber der Ablauf erfolgt hauptsächlich linear in einer Richtung von einem Anfangs- in einen Endzustand.

Habe ich viele verschiedene Übergänge zwischen verschiedenen Zuständen ohne Vorzugsrichtung, es gibt nur einen definierten Anfangszustand, dann bezeichne ich es als Zustandsautomat.
Außerdem habe ich beim Zustandsautomat nur einen aktiven Zustand.
Bestes Beispiel für einen Zustandsautomat ist die Profidrive Zustandsmaschine.

Das lässt sich bestimmt auch als Schrittkette in S7-Graph implementieren, ich vermute aber das sieht nicht gerade elegant aus.
Der Unterschied liegt bei mir hauptsächlich in der Darstellungsart.


----------

