X1 X1 Implementierung von Zustandsautomaten im Logikblatt

[willisurf]

Ich bin auf der Suche nach einer Möglichkeit im Logikblatt des X1 einen Zustansautomaten zu modellieren.

Gibt es dort neben dem Weg „über die Dörfer“, also RS FlipFlops und Logik für Set-/Reset einen eleganteren Weg?

Hintergrund: Ich möchte die Logik eines Präsenzmelders modellieren. Diese ist soweit fertig, jetzt fehlen nur noch die manuellen Overridemöglichkeiten (auf Basis der MDT Logik mit ext. Taste kurz/lang). Dafür bieten sich mMn Zustandsautomaten an, s. Anlage. A1121B45-CE21-4A60-89B9-DC5B1FD07994.jpeg

[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

[thn80]

Hallo Bernhard,

ich weiß zwar nicht, ob es für dich eine Lösung wäre, aber ich hatte das gleiche Problem mit einem BJ PM. Mit diesem wollte ich auch die Statemachine von MDT nachbilden. Was dabei rausgekommen ist, siehe Anhang.

Wichtig ist, dass das XNOR seinen Ausgang nur dann ändert, wenn sich der "blaue Eingang" ändert.
Die beiden AND-Gatter dienen nur dazu, dass ich auf dem Taster dann die linke LED für "Manuell Aus" und die rechte LED für "Manuell An" leuchten lassen kann.

Ist zwar jetzt keine richtige Statemachine wie du es wolltest, bildet es aber in Logik nach und das sollte mit deinem X1 ja funktionieren.

Gruß,

Thomas

Beleuchtung_Auto-Manuell_Statemachine__diagrammeditor.de.png

[willisurf]

Dankeschön Thomas, ich schaue mir das mal in Ruhe an!

Ich suche tatsächlich noch etwas anderes, da ich den PM selbst nachbilden möchte. Ideen sind also noch willkommen.

[thn80]

Was stelle ich mir unter einer Nachbildung des PM vor? Was soll das Ding am Ende machen? Was bringt diese Nachbildung?

[willisurf]

Das Problem ist, das die Applikation des Steinel True Presence sehr schlecht implementiert ist. Szenensteuerung des Status vom PM geht nicht, es gibt keinen vernünftigen Statuseingang, die Sperre wird nicht vernünftig bedient,... ein Sack voller Flöhe.

Daher möchte ich eine vernünftige Steuerung inkl. all dieser Features (und noch etwas mehr, wie z.B. adaptive Helligkeitsschwelle für zuverlässige Abschaltung) in eine externe Steuerung im X1 integrieren. Die Grundlogik habe ich bereits fertig. Es fehlen nur noch ext. Taste kurz/lang (in MDT Logik).

Die beiden Blockschaltbilder zeigen, wie das Ganze ausfallsicher funktioniert:

Bildschirmfoto 2021-10-16 um 13.50.44.png Bildschirmfoto 2021-10-16 um 13.50.53.png

[hyman]

Wenn ich mir Dein Zustandsdiagramm im Eingangspost anschaue, fällt mir zunächst auf, dass der Taster außerhalb des Erfassungsbreichs des PM montiert sein sollte. Sonst hat es keinen Sinn, per Tastendruck nach "Auto Bereit" zu gehen, weil der PM das ja ohnehin gleich wieder mit "Auto Ein" überschreiben würde.

Ich gehe mal davon aus, dass auf den KOs für die Tastendrücke jeweils eine 0 für "Aus" und eine 1 für "Ein" kommt. Der Zustandsautomat muss dann wissen, welches KO den aktuellen Tastendruck darstellt und welche Tasterzustände bereits verarbeitet worden sind. Da sehe ich bei der Umsetzung mit einer Formelberechnung das größte Problem. Evtl. bekommt man das in den Griff, indem der Taster statt 0 und 1 eine Szenennummer sendet. Die könnte der Zustandsautomat dann nach der Verarbeitung auf eine unbenutzte Nummer umsetzen, die keinen weiteren Zustandsübergang auslösen kann.

[willisurf]

Wenn ich mir Dein Zustandsdiagramm im Eingangspost anschaue, fällt mir zunächst auf, dass der Taster außerhalb des Erfassungsbreichs des PM montiert sein sollte. Sonst hat es keinen Sinn, per Tastendruck nach "Auto Bereit" zu gehen, weil der PM das ja ohnehin gleich wieder mit "Auto Ein" überschreiben würde.

Ja, das stimmt für den Zustandsübergang muss es noch eine Totzeit bis zum aktiven Freischalten von Auto Bereit geben. Ist in der Logik der MDT PM auch so umgesetzt.

Ich gehe mal davon aus, dass auf den KOs für die Tastendrücke jeweils eine 0 für "Aus" und eine 1 für "Ein" kommt.

So war es eigentlich gedacht, Steuerung mit boolschem Eingang. Ich hatte gehofft, das dies trotzdem mit der Formelberechnung funktionieren könnte, aber wenn Du da schon Probleme siehst, müsste ich mir tatsächlich eine andere Variante überlegen.
Ich muss mal etwas mit den Bausteinen an einem einfachen Beispiel experimentieren. Formelberechnung schien mir da bisher am vielversprechendsten. Vielleicht kann ich ja auch einen Trigger bei geändertem Zustand auslösen und damit die Eingänge abgekoppelt zurücksetzen.

[hjk]

Nur zur Info, das Diagramm ist stark vereinfacht und dient nur zum Verständnis.

[willisurf]

hjk Danke für den Hinweis. Ich erwarte auch, das ich nach den Erfahrungen im Alltag noch an einigen Stellen nachbessern werde. Aber es gibt dann eine solide Basis mit einem Eingang für den Aktorstatus und nachvollziehbarer Umschaltung Ein/Aus bzw. Automatisch/manuell. Alles deutlich zuverlässiger als die nicht deterministische Logik ohne vernünftigen Statuseingang im TP.

Am liebsten wäre mir natürlich, wenn es solch ein PM-Logikmodul von MDT gäbe. Hardwarebasis das aktuelle Logikmodul, "nur" geänderte Software, flexibel einsetzbare PM/LK Blöcke mit der guten MDT PM Logik, ergänzt durch die Ermittlung des Lichtstatus (ODER Gatter mit vielen Eingängen), Szenensteuerung,...

Jeder der sich mit schlechten PM Implementierungen herumärgern muss, könnte sich dann solch ein Modul in die Verteilung bauen und hätte eine mächtige und konsistente Logik für die Präsenzmelder. Ich wäre jedenfalls der erste Kunde, auch wenn das mal in einem X1 läuft...

[hyman]

Formelberechnung schien mir da bisher am vielversprechendsten.

Sehe ich auch so. Die Schwierigkeit besteht darin, dass die immer alle Formeln berechnet, auch wenn sich nur ein Eingang geändert hat. Da wir mehrere Tastereingänge benötigen, müssen wir unterscheiden können, welcher davon gerade gedrückt wurde. Und wenn wir einen neuen Zustand ermittelt haben, müssen wir den auch auf einen Eingang zurück führen, weil davon der nächste Zustandsübergang abhängt. Dieser soll aber erst erfolgen, wenn wirklich wieder ein Taster gedrückt wird oder sonst ein externes Ereignis eintritt, und nicht schon allein durch das Anlegen des neuen Zustands. Daher müssen wir vor dem Anlegen des neuen Zustands alle Eingaben auf einen neutralen Wert zurück setzen, die keine Zustandsänderung bewirken.

Ich muss mal etwas mit den Bausteinen an einem einfachen Beispiel experimentieren.

Ich auch...

[willisurf]

Daher müssen wir vor dem Anlegen des neuen Zustands alle Eingaben auf einen neutralen Wert zurück setzen, die keine Zustandsänderung bewirken.

Das ist genau der Weg. Ich bin jetzt soweit durch, das ich Morgen alles zusammenpuzzeln und ausprobieren kann. Ich veröffentliche das Logikblatt dann mal hier.

Es geht dann nach dieser „Vorbehandlung“ der Tasterbetätigungen doch mit Deinem Formelmodul, wirklich genial!!

P.S. Ich denke es geht sogar ohne Rückführungen, dadurch lässt sich das Ganze auch simulieren.

[Igge]

Grafische Zustandsautomaten vermisse ich im Bereich Smart Home bzw. Hausautomatisierung schon lange. So richtig scheint es da nichts zu geben. Beruflich habe ich viel mit Matlab Simulink/Stateflow gearbeitet und würde mir sowas auch hier wünschen.

[hyman]

So, jetzt habe ich mal einen einfachen Zustandsautomaten mit drei Zuständen und einer Eingangsgröße realisiert:

StateMachineExample.png

Um mit einer Schalt-Eingabe arbeiten zu können wird diese direkt per Typ-Konverter in eine (vorzeichenbehaftete) Ganzzahl gewandelt. Dadurch kann die Formelberechnung (in Formel 1) den Eingabewert mit -1 als verarbeitet markieren. Die weiteren vier Formeln stellen jeden möglichen Zustandsübergang dar. Dazu sind immer zwei Bedingungen notwendig:

• Der passende Ausgangszustand
• und der passende Eingabewert

Sind beide erfüllt, so gibt die Formel den neuen Zustand aus. Ist auch nur eine davon nicht erfüllt, gibt die Formel nichts aus. Es gibt keinen Fall, in dem mehr als eine dieser Zustandsübergangs-Formeln einen Wert ausgibt.

Der neue Zustand wird auch auf den entsprechenden Eingang der Formelberechnung zurück geführt. Dies führt zwar zu einem weiteren Berechnungslauf, der aber keine weitere Änderung des Zustands bewirkt (weil auch der Eingabewert auf -1 = "verarbeitet" gesetzt wird, so dass keine der vier Zustandsübergangs-Formeln einen Wert ausgibt). Der Send-by-Change verhindert danach weitere endlose Berechnungsläufe.

Das Prinzip sollte sich für kompliziertere Zustandsautomaten verallgemeinern lassen:

• Für jede Eingangsgröße wird ein sonst nicht vorkommender Wert als Code für "verarbeitet" festgelegt. Dieser Wert wird konstant mit einer Formel ausgegeben (die nur als Wertgenerator wirkt) und auf einen Ausgangsbaustein für die Eingangsgröße geführt.
• Sollte die Eingangsgröße keinen freien Wert für "verarbeitet" ermöglichen, so ist sie mittels Typkonvertierung in einen entsprechend mächtigeren Typ zu wandeln wie im Beispiel oben.
• Für jeden Zustandsübergang wird ebenfalls eine Formel angelegt, wie oben beschrieben. Dabei ist darauf zu achten,
  • dass Eingabewerte, die den Wert "verarbeitet" haben nicht zu Zustandsübergängen führen dürfen,
  • und dass nur eine der Formeln einen neuen Zustand liefert, die anderen aber nichts ausgeben.
• Alle Ausgänge von den Formeln für die Zustandsübergänge werden auf den gleichen Ausgangsbaustein geführt und mittels eines Eingangsbausteins auf den entsprechenden Eingang der Formelberechnung zurück geführt. Wichtig ist hier der Send-by-Change, damit es nur zu genau einer Neuberechnung kommt (und nicht zu einer endlosen Wiederholung dieser Neuberechnung).

Grüße von Horst

[hyman]

P.S. Ich denke es geht sogar ohne Rückführungen, dadurch lässt sich das Ganze auch simulieren.

Das kann ich mir nicht vorstellen. In meinem Beispiel oben siehst Du auch direkt warum. Simulieren kann man das, indem man die zurück geführten Werte händisch einträgt -- zuerst den "verarbeitet"-Wert der Eingangsgröße, danach den neuen Zustand.

Solltest Du doch was ohne Rückführung hin bekommen, wäre das natürlich noch besser ...

[willisurf]

Grafische Zustandsautomaten vermisse ich im Bereich Smart Home bzw. Hausautomatisierung schon lange. So richtig scheint es da nichts zu geben.

Ja, das ist wirklich schade, weil man dies ja bei der Steuerung von Abläufen regelmäßig brauchen könnte.

So, jetzt habe ich mal einen einfachen Zustandsautomaten mit drei Zuständen und einer Eingangsgröße realisiert:

Dankeschön für Dein generisches Beispiel. Da habe ich Morgen ja genug zum Nachdenken.

Solltest Du doch was ohne Rückführung hin bekommen, wäre das natürlich noch besser ...

Noch denke ich das es geht.