State Machine für verschiedene Events

Hallo!

Mir geht es um folgende Problemstellung:

Ich möchte eine State Machine entwerfen, bin mir aber noch nicht schlüssig, wie ich einen speziellen Punkt richtig angehe:

- Die Grundstruktur der State Machine ist für mich soweit klar: Init, "Haupt-State" (in meinem Fall wird von der COM-Schnittstelle gelesen), Fehlerbehandlung und ein Exit-State.
Jetzt habe ich aber auf meinem FP verschiedene Buttons, über die ich in verschiedene States wechseln möchte, damit dort andere Aktionen abgearbeitet werden können.

Meine konkrete Frage ist nun: Wie programmiert man diese "Abfrage", welcher Button gedrückt wurde und in welchen State dann gewechselt wird, am ordentlichsten? Benutzt man Ereignis-Cases für die Wertänderung jedes Buttons? Oder benutzt man Case-Strukturen, in die man die angepeilten States dann ablegt?
Habe mir schon dieses Tutorial bei NI angeschaut, bin aber nicht so ganz durchgestiegen, weil dort relativ viele Möglichkeiten aufgezeigt werden.

Wäre toll, wenn mir jemand diesbezüglich ein paar Tipps geben kann.

Danke & Gruß

Anzeige

Du kannst einen "Leerlauf"-Case erstellen, in dem Du eine Ereignisstruktur platzierst und entsprechend der Userauswahl in den gewünschten Case springst.

Gruß Markus

Meinst du das so, dass immer zwischen dem "Lesen"-State und dem "Idle"-State immer abwechselnd hin- und her gesprungen wird?
Das wäre ja schon okay, aber mein Problem liegt dann für mich immer noch bei der Behandlung der Buttons. Bspw. hätte ich jetzt 5 Buttons, die alle auf einem FP abgefragt werden sollen. Soll ich fünf Ereignisstrukturen erstellen oder dann doch fünf Case-Strukturen? Und mein (wahrscheinlich triviales) Problem ist dann noch: Wie gebe ich dann die verschiedenen Enums auf das Schieberegister? Wenn ich mehr wie ein Enum anschließe, erhalte ich ja eine Fehlermeldung...

Ich mache es z.B. so:
   
Die State-Cases befinden sich alle im Timeout der Ereignisstruktur. Wichtig ist, daß in den States kein Waits stattfinden, auch langes Warten auf Datenempfang etc. sollte vermieden werden (Z.B. bei Warten auf Datenempfang: Timeout im Ereignsicase so einstellen, daß beim Übergang zum Dantenempfangs-Case schon alle Bytes im Empfangspuffer sind. Oder den Datenempfangs-Case mehrere Male pollen, bis alle Daten im Buffer sind) . D.h. alles Warten, wenn erforderlich, sollte möglichst immmer über den Timeout-Anschluß der Ereignsistruktur realisiert werden, wobei die Timeout-Zeit nicht konstant sein muß, sondern sich über Schieberegister für jeden State individuell anpassen läßt.
Beim Datenempfang sollte auch auch über eine Erzeuger-Verbraucher-Struktur nachgedacht werden. Dann würde das Warten auf Datenempfang in eine unabhängige Schleife ausgelagert. Oder ein erfolgter Datenempfang läßt sich als Ereignis registrieren (Das ist die um Größenordnung bessere Variante gegenüber den oben von mir in Klammern genannten Möglichkeiten).
Edit: unausgereifte Überlegung: Könnte man es nicht auch so einrichten, daß jeder neue State ein benutzerdefiniertes Ereignis ist? Dann währen alle States Ereignise und hätten ihren eigenen Case innerhalb der Ereignsistruktur, anstatt innerhalb einer normalen Case-Struktur

Die Idee mit der Producer-Consumer-Struktur ist gut, die werde ich auf jeden Fall weiterverfolgen. Deine Antwort lässt zwar schwer meinen Kopf rauchen, aber mal schauen, wie sich das am besten für mich umsetzen lässt

Hallo nochmal!

Ich habe mir jetzt so über den Tag Gedanken gemacht, wie ich das mit den verschiedenen Buttons -> verschiedene States realisieren kann und bin bisher zu folgender Lösung gekommen.
   

Wenn kein Button gedrückt ist, wird im Timeout-Case nur ein leerer String übergeben bzw. mit dem anderen String verknüpft. Der Standard-Case in der nachfolgenden Struktur verweist auf den aktuellen State (in diesem Fall "lesen"), d.h. es wird solange in diesem State geblieben, bis irgendein Button gedrückt ist.
Klickt man nun auf einen Button, dann wird der Text für den entsprechenden State übergeben und mit dem leeren String verknüpft. Dann wird in der Case-Struktur der entsprechende Fall ausgewählt und an das Schieberegister weitergereicht, was dann den nächsten State bestimmt.

Soweit meine Gedankengänge, jetzt wollte ich eigentlich nur einmal von den Experten hören, ob mein Konzept sinnvoll ist bzw. ob noch irgendwelche Fallstricke lauern könnten. Bei meinen Tests hat das einen recht brauchbaren Eindruck gemacht & auch schnell reagiert. Aber vielleicht gibts ja noch eine bessere Lösung...

Du bist ein intelligentes Kerlchen, und so macht es Spaß Dir zu helfen. Habe aber in den nächsten Tagen wenig Zeit. Wer springt freiwillig ein?

Versuch mal dies

' schrieb:Versuch mal dies

Danke Martin & Danke an alle bisher für das Feedback!
Leider kann ich das mit 8.6 nicht öffnen, wäre es möglich, dass du mir das nach 8.2 runterspeicherst?

Grüße

ohh sorry
bin mir nicht gewohnt, dass hier im Forum mit einer "tieferen" Version als ich gearbeiten wird