X1 Implementierung von Zustandsautomaten im Logikblatt

[willisurf]

hyman Hallo Horst,

Anbei mal mein ProofOfConcept einer Statemachine mit drei Zuständen und 2 Eingängen. Es ist sicherlich noch einiges zu tun (Initialisierung und nicht vorgesehene Tastenbetätigungen führen noch auf State0,...) aber durch die Nutzung der internen previous Variablen ist es möglich auf eine Rückführung zu verzichten und die Statemachine einfach durchzusimulieren.

Die binären Tastenbetätigungen (Taster kurz und Taster lang) werden für die Statemachine über die Treppenlichtzeit nur für (hier 1s) auf den aktuellen Wert gesetzt und fallen danach auf den Wert für ungültig 255 zurück. Das Ganze geht sicherlich noch eleganter, aber erstmal ist mir nichts anderes eingefallen.
Der Vollständigkeit halber kurz die Formel aus dem Block Telegrammselektion "{Trigger:b} ? {Wert:N} :255"

In der Statemachine wird der aktuelle State in Formel4 zusammengefasst, dabei wird der Wert nur geändert, wenn ein Taster nicht als ungültig (255) gekennzeichnet ist.
Die Formeln 1-3 greifen dann jeweils über _previousOut4_ auf den aktuellen State zurück und überprüfen die Ausstiegsbedingungen aus dem State. Wenn eine Bedingung erfüllt ist, wird die neue Statenummer gesetzt, ansonsten wird der Wert Null zurückgeliefert. Auch hier gilt natürlich, das alle Bedingungen enthalten sein müssen. Bei vielen Bedingungen wird die Formel schnell unübersichtlich. Formel1 berücksichtigt zusätzlich den State0, um aus der Initialisierung zu kommen (muss später überarbeitet werden).
Formel4 berechnet den neuen State wenn ein Taster betätigt wurde aus der Summe der Formeln 1-3 (hier könnte noch ein Abfangen einer Fehlberechnung ergänzt werden).

Statemachine.JPG Formeln.JPG

[hyman]

... über die Treppenlichtzeit nur für (hier 1s) auf den aktuellen Wert gesetzt und fallen danach auf den Wert für ungültig 255 zurück.

Das kann bei schneller Tasterbetätigung (unter 1s Zeitabstand) zu Fehlfunktionen führen. Daher würde ich dazu den Wert direkt nach der Verarbeitung von der Formelberechnung auf "ungültig" setzen lassen.

Sehr elegant finde ich Deine Idee, die Rückführung des neuen Zustands auf einen Eingang zu vermeiden.

Bei vielen Bedingungen wird die Formel schnell unübersichtlich.

Wenn eine dieser Formeln zu umfangreich wird, lässt sie sich ohne weiteres teilen. Man kann im Extremfall für jeden Zustandsübergang eine eigene Formel haben.

nicht vorgesehene Tastenbetätigungen führen noch auf State0

Das ließe sich beheben, idem man in der Formel 4 nicht auf den Tasterzustand prüft, sondern darauf, dass mindestens eine der Formeln 1 bis 3 was anderes als 0 zurück gibt.

[willisurf]

Daher würde ich dazu den Wert direkt nach der Verarbeitung von der Formelberechnung auf "ungültig" setzen lassen.

Sehr gute Anregung!

Das ließe sich beheben, idem man in der Formel 4 nicht auf den Tasterzustand prüft, sondern darauf, dass mindestens eine der Formeln 1 bis 3 was anderes als 0 zurück gibt.

Auch hier vielen Dank für Deine Verbesserungsideen. Ich werde das mal einbauen und dann erstmal testen.

[willisurf]

Daher würde ich dazu den Wert direkt nach der Verarbeitung von der Formelberechnung auf "ungültig" setzen lassen.

Wahrscheinlich sehe ich den Wald vor lauter Bäumen nicht, aber ich habe keine Idee, wie ich das ohne Rückführung realisieren kann. Mit Rückführung ist es klar, so ist ja auch Dein Beispiel aufgebaut. Aber ohne habe ich jetzt lange nachgedacht und auch inkl. der _previous_ Variablen keinen Weg gefunden.

[hyman]

Ich hatte schon mit Rückführung gemeint. Ich finde das nicht so schlimm, weil die Auswertung ohnehin so gemacht sein sollte, dass bei lauter inaktiven Eingängen kein weiterer Zustandsübergang möglich ist ...

[hyman]

Weiteres Nachdenken hat mich zu einer rückführungsfreien Implementierung meines früheren Beispiels geführt. Wesentliche Änderungen:

• Es gibt nur noch einen Ausgang, der den aktuellen Zustand repräsentiert. Dadurch wird die Zustandsrückführung auf einen Eingang überflüssig; _previousOut<n>_ enthält ihn.
• Es gibt nur noch einen Eingang, der alle Zustandsübergänge auslöst. Dadurch wird auch das Rücksetzen der Eingänge auf "macht nix" überflüssig: Immer wenn ein Wert kommt, soll der ausgewertet werden und möglicherweise zu einem Zustandsübergang führen.

Zusätzlicher Aufwand entsteht dadurch, wenn man mehrere unabhängige Eingabequellen verarbeiten möchte. Deren mögliche Werte müssen jetzt alle auf verschiedene Wertebereiche für den selben Eingang umgesetzt werden. Im Beispiel habe ich mal einen zweiten Taster hinzugefügt, um das zu veranschaulichen. Dieser soll den Zustand immer auf 0 setzen, wenn er eine 0 sendet (1 wird ignoriert).

Das Zustandsdiagramm sieht damit so aus:

image_117602.png

Die Realisierung im GPA benutzt für jeden Zustandsübergang eine Formel, die den gewünschten neuen Zustand ausgibt (oder -1, wenn der entsprechende Zustandsübergang nicht zutrifft). Von diesen Formeln darf immer höchstens eine was anderes ausgeben als -1; die Bedingungen müssen sich also gegenseitig ausschließen. Die letzten beiden Formeln basteln aus diesen Zustandsübergängen den finalen Zustand:

StateMachineExample.png
Die beispielhaften Simulationsdaten zeigen, dass die letzte Eingabe keinen Zustandsübergang ausgelöst hat, weil keine der ersten 5 Formeln was anderes als -1 ausgegeben hat.

In der nächsten Version des Bausteinpakets mit der Formelberechnung werde ich ein entsprechendes Beispiel zur Dokumentation hinzufügen.

[hyman]

Gelöscht. Das Zustandsdiagramm ist jetzt in den vorigen Beitrag integriert.

[willisurf]

Weiteres Nachdenken hat mich zu einer rückführungsfreien Implementierung meines obigen Beispiels geführt.

Hallo Horst,

Vielen Dank, das Du Dir hierzu nochmal Gedanken gemacht hast! Ich persönlich finde es auch deutlich eleganter eine Statemachine erstmal ohne Rückführung zu implementieren. Auf Basis Deines Ablaufes sollte das genau so möglich sein.

Parallel habe ich mir auch nochmal Gedanken gemacht. Das Hauptproblem ist ja, das die Tastendrücke nur einmalig ausgewertet werden sollen. Ich habe fiktiv einen neuen Variablentyp im Formelbaustein angedacht, mit dem sich dieses Problem m.E. sehr elegant lösen lässt. Die Darstellung wird dann kompakter und vor allem in Bezug auf die Eingänge konsistenter.

Diese Variablen funktionieren ähnlich wie die _previousOutn_ Variablen, d.h. Sie werden zu Beginn gesetzt, jedoch im Unterschied dazu am Ende eines Berechnungsdurchlaufs alle auf "null" gesetzt. Ich habe Sie im Bild mal _cycleOutn_ genannt.

Wenn ich die Funktionalität des Bausteins richtig verstanden habe, sind damit dann Abfragen, wie in dem Bild möglich und es triggert nur die Zeile, die einen Stateübergang auslöst. Ich habe mal versucht -ohne Gewähr- mit diesen fiktiven Variablen Deine 3 stufige Statemachine abzubilden. Wahrscheinlich müsste in den Formeln noch ein Abfrage auf != null ergänzt werden.

Ich hoffe ich habe ansonsten keinen Denkfehler. Wie ist Deine Meinung dazu?
Statemachine.jpg

[hyman]

Da es mit der Formelberechnung geht wie sie ist werde ich da erst mal keine weitere Komplexität einbauen. Was stört Dich an meiner neuesten Implementierung? Wenn es nur die Aufbereitung mehrerer Eingaben zum gemeinsamen Übergangscode ist: Das lässt sich mit einer zweiten, vorgeschalteten Formelberechnung erledigen, wenn es komplizierter wird als in meinem letzten Beispiel.

[willisurf]

Das kann ich gut verstehen, das Du nicht unbedingt etwas ändern möchtest, wenn es grundsätzlich geht.

Ich hatte das nur für einen netten Gedanken gehalten, an das Problem grundsätzlicher heran zu gehen. Tatsächlich ist es aber nicht notwendig, ich werde die Implementierung nach Deiner Methode umsetzen. Vielen Dank dafür!

P.S. Werde gleich mal die neue Forumsfunktion "beantwortet" austesten.

[hyman]

P.S. Werde gleich mal die neue Forumsfunktion "beantwortet" austesten.

Tut -- nur ist der Haken in der Thread-Liste leider kein Link zum als Antwort gekennzeichneten Beitrag.

[willisurf]

Naja, aber er ist ja als zweiter Beitrag recht prominent erreichbar. Aber irgendwie im Traueranzeigenlook. Wäre schon nett, wenn man die Rahmenfarbe anders als schwarz konfigurieren könnte.

[hyman]

ist ja als zweiter Beitrag recht prominent erreichbar

Stimmt, ich hatte ich noch gar nicht gemerkt, dass der Beitrag da nochmal erscheint. Von dort ist auch der Beitrag im Originalzusammenhang weiter hinten im Thread verlinkt.

irgendwie im Traueranzeigenlook. Wäre schon nett, wenn man die Rahmenfarbe anders als schwarz konfigurieren könnte.

... oder wenigstens ein schönes Grün für den Rahmen verwendet würde.

[concept]

oder gelb/grün

(duck und weg)

[willisurf]

hyman Ich habe nochmal ein wenig darüber nachgedacht und meine das die Einführung der neuen Variablen _is&lt;name&gt;ValueSet_ auch bei der Implementierung der StateMachine hilft. Die Variablen würden dann jeweils nur die Formeln triggern, die über den entsprechenden Eingang (Taste) berechnet werden sollen. Von daher eine sehr gute, generische Lösung.