X1 Implementierung von Zustandsautomaten im Logikblatt

[hyman]

willisurf , Du hast völlig recht. Mit der (noch nicht verfügbaren) Version 1.4.x der Formelberechnung kann man sich die externe Aufbereitung der Eingabewerte sparen und mehrere Eingänge verwenden. Das Beispiel von oben (die Wiederholung des Zustandsdiagramms spare ich mir) sieht dann so aus:

StateMachine2.png

Reset ist jetzt ein separater Eingang, der auf beliebige Telegrammwerte (nicht nur 0 wie oben) reagiert. Möglich wird das, indem jede Zustandsübergangs-Formel zusätzlich prüft, ob der zugehörige Eingabewert gerade eben neu empfangen worden ist. In den gezeigten Simulationsdaten wurde seit dem letzten Reset 2 x Auf (AbAuf = 1) geschickt.

Ich glaube, wir brauchen noch eine Max-Funktion mit beliebig vielen Parametern ... dann sieht Formel 6 nicht so chaotisch aus.

[willisurf]

Ich glaube, wir brauchen noch eine Max-Funktion mit beliebig vielen Parametern ... dann sieht Formel 6 nicht so chaotisch aus.

Ja, das wäre deutlich übersichtlicher. Aber schön, das es dann eine elegante Lösung gibt, die auch nebenbei als Beispiel geeignet ist.

Wobei nochmal überlegt. Könnte man nicht alle nicht getriggerten Formeln eine 0 ausgeben lassen und die States von 1… n durchnummerieren. Der aktuell berechnete State wäre dann einfach die Summe. Man muss natürlich darauf achten, das immer nur genau eine Formel triggert und auch jedes Eingangssignal zu einer Berechnung führt.

[hyman]

Könnte man. Allerdings kann dann 0 kein gültiger Zustand sein. 0 ist aber der initiale Zustand, so dass dann zusätzlicher Aufwand nötig ist, um von da zu einem gültigen Zustand zu kommen. Entweder tut der Zustandsautomat dann nix bis ein Reset kommt oder mindestens einer der anderen Zustandsübergänge muss komplizierter werden.

Ich denke, Minima und Maxima mehrerer Werte sind allgemein sinnvoll, deshalb hab ich die auch eingebaut. Damit kann man alles lassen wie es ist und es wird trotzdem recht übersichtlich.

Mir ist noch ein Fehler in der obigen Version aufgefallen: Wenn ein Auf- oder Ab-Telegramm gleichzeitig mit einem Reset-Telegramm eintrifft, wird der Reset ignoriert. Mit einer zusätzlichen Formel lässt sich das beheben:

image_118477.png
Zuletzt wurde eine 1 gleichzeitig an AbAuf und Reset gesendet. In diesem Fall hat der Reset Priorität; das Auf-Telegramm wird verworfen; der Ausgang steht auf 0.

[willisurf]

Ich denke, Minima und Maxima mehrerer Werte sind allgemein sinnvoll, deshalb hab ich die auch eingebaut.

Klasse Dankeschön! Wenn die neue Version released ist, wird das dann die Lösung desThreads

[hyman]

Ab der soeben freigegebenenen Version 1.4.5 der Visu- & Web-Logikbausteine kann man in der Formelberechnung feststellen, welche Eingabewerte gerade neu gesetzt worden sind:

Für jeden Eingang wird eine Variable bool _is<name>ValueSet_ angelegt. Diese gibt an, ob der Eingang für die laufende Berechnung ein neues Eingangstelegramm erhalten hat (true) oder ob der Wert von einem früheren Eingangstelegramm stammt (false). Ob sich der Eingangswert durch dieses Telegramm tatsächlich geändert hat (oder nur der gleiche Wert erneut empfangen worden ist), lässt sich daraus nicht ableiten.

Damit lässt sich die oben angegebene Lösung für den Zustandsautomaten eleganter realisieren.

Das Beispiel für einen einfachen Zustandsautomaten ist der schon bekannte Auf-/Abwärtszähler mit unterer Grenze 0 und oberer Grenze 2. Das folgende Zustandsdiagramm zeigt, welche Zustände dieser Automat annehmen kann und welche Übergänge zwischen ihnen möglich sein sollen:

image_118479.png

Um die Formeln übersichtlich zu halten, hat jeder Zustandsübergang seine eigene Formel, in der die Anfangsbedingung und der Zielzustand enthalten sind. Wichtig ist, dass immer nur eine der Anfangsbedingungen erfüllt ist. Dazu wertet die erste Formel aus, welche Eingänge aktuell einen Wert erhalten haben. Nur wenn ein Auf- oder Ab-Telegramm, aber kein Reset anliegt, lassen wir die Zustandsübergänge zum Auf- und Abwärtszählen zu:
Formel 1: _isAbAufValueSet_ && !({Reset:B} && _isResetValueSet_)
Die Zustandsübergänge zum Auf- und Abwärtszählen benötigen außerdem den aktuellen Zustand des Automaten, der zuletzt an Ausgang 8 ausgegeben worden ist:
Formel 2: (!{AbAuf:B} && _out1_ && (_previousOut8_ == 1)) ? 0 : -1
Formel 3: (!{AbAuf:B} && _out1_ && (_previousOut8_ == 2)) ? 1 : -1
Formel 4: ({AbAuf:B} && _out1_ && (_previousOut8_ == 0)) ? 1 : -1
Formel 5: ({AbAuf:B} && _out1_ && (_previousOut8_ == 1)) ? 2 : -1
Der Reset führt unabhängig vom aktuellen Zustand immer in den Zustand 0:
Formel 6: ({Reset:B} && _isResetValueSet_) ? 0 : -1
Da die Formeln für alle nicht zutreffenden Zustandsübergänge -1 ausgeben, führt der tatsächlich zutreffende Zustandsübergang zu dem Zustand, der sich aus dem Maximum der vorigen fünf Ergebnisse ergibt:
Formel 7: MoreMath.Max(_out2_, _out3_, _out4_, _out5_, _out6_)
Wenn dieses Maximum -1 ist, dann findet gar kein Zustandsübergang statt. In diesem Fall soll auch nichts ausgegeben werden:
Formel 8: (_out7_ >= 0) ? (int?)_out7_ : null

Der gesamte Zustandsautomat lässt sich so mit einem einzigen Formelberechnungs-Baustein realisieren, der hier mit beispielhaften Simulationsdaten gezeigt ist:

image_118480.png
Zuletzt wurde eine 1 gleichzeitig an Ab/Auf und Reset gesendet. Da der Reset Priorität hat, wird das Auf-Telegramm verworfen. Der Ausgang steht deshalb wie gewünscht auf 0.

Bei der Weiterverarbeitung des Ausgabewerts von Ausgang 8 ist zu beachten, dass der Startzustand 0 ist. Dieser wird aber beim Neustart des Logikmoduls nicht ausgegeben. Die Eingänge nachfolgender Logikbausteine müssen daher mit 0 vorbelegt sein.

Nach dem gezeigten Prinzip lassen sich auch komplexere Zustandsautomaten realisieren.

Grüße von Horst

[willisurf]

Wow! Aus meiner Sicht eine sehr ausführliche und verständliche Anleitung. Damit ist das Thema Zustandsautomat sehr gut und systematisch implementiert.
Vielen Dank für die tolle Arbeit Horst!

[hyman]

(Gelöscht da Review beendet)