+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+--- Thema: Frage zu "queued state machine" Architektur (/Thread-Frage-zu-queued-state-machine-Architektur)
Frage zu "queued state machine" Architektur - joptimus - 05.08.2016 13:57
Hi,
ich habe eine Software für die Steuerung eines Prüfplatzes programmiert. Dabei habe ich die "queued state machine" Architektur genutzt:
https://decibel.ni.com/content/docs/DOC-32964
Das verlinkte Dokument hat mir sehr geholfen, nur ist mir nicht ganz klar, wie das aussehen sollte, wenn eine zusätzliche Ebene hineinkommt:
- Benutzerinterface (hier wird der Messablauf gewählt)
- Zustandsautomaten für Messablauf 1..m (programmatisch vorgegeben, außer Fehlerquittierung/Pause/Stop) keine Nutzerinteraktion. Die Messabläufe passieren hintereinander, nicht gleichzeitig. Es müssen auch nicht zwangsläufig alle stattfinden. Der Nutzer kann z.B. nur die Hälfte der Messungen auswählen, wenn er Zeit sparen will.
- Messinstrumente 1..n
So gesehen ist das VI mit den Zustandsautomaten für die Messabläufe sowohl Producer als auch Consumer - je nachdem, ob man in meiner Architektur von oben oder von unten aus darauf schaut.
Das Problem was ich nun habe, betrifft die Implementierung des GUI. Der Nutzer soll natürlich die Möglichkeit haben, einen Messablauf zu wählen. Hier hätte ich in Anlehnung an die gewählte Architektur bei einem Benutzerevent die entsprechende Botschaft in die Befehlswarteschlange geschrieben, worauf der entsprechende Zustandsautomat startet und dann automatisch sein Ding macht, siehe angehängtes Bild.
Nur habe ich dann - wie rot markiert - eine Whileschleife innerhalb einer Whileschleife. Kann das zu Problemen führen? Gibt es ggf. eine bessere Lösung?
[attachment=56419]
Ist auch hier gepostet:
http://forums.ni.com/t5/LabVIEW/Architecture-question-queued-state-machine-PC-with-multiple/td-p/3331462
RE: Frage zu "queued state machine" Architektur - GerdW - 05.08.2016 14:12
Hallo joptimus,
bitte immer auf Crossposts hinweisen!
Wozu brauchst du die innere While-Loop in der mittleren Statemachine?
RE: Frage zu "queued state machine" Architektur - joptimus - 05.08.2016 14:19
(05.08.2016 14:12 )GerdW schrieb: Hallo joptimus,
bitte immer auf Crossposts hinweisen!
Wozu brauchst du die innere While-Loop in der mittleren Statemachine?
Sorry, vergessen. Habe meinen Post aktualisiert.
Die innere While-Schleife brauche ich, damit der Programmablauf des jeweiligen Messprogramms abgearbeitet wird. Es werden alle z.B. 100 ms Bedingungen geprüft, um zwischen den Zuständen zu wechseln.
z.B. Idle -> nach 5x100 ms Motor an -> Achse bewegt sich -> nach 53x100 ms (wenn Position erreicht ist) Stop
Hätte ich die Schleife nicht, würde es nur eine Ausführung geben.
Das ist doch soweit ich das beurteilen kann genau ein Zustandsautomat: Eine While-Schleife mit einer Case-Struktur darin.
Die äußere While-Schleife gehört zum äußeren Zustandsautomat. Die innere gehört zum inneren. Quasi ein Zustandsautomat in einem Zustandsautomaten. Das ist genau die Komplikation, deren Lösung sich mir aus dem Beschreibungsdokument heraus nicht erschließt.
Edit:
Ich habe das gerade mal so implementiert wie im Bild dargestellt. Es läuft auf den ersten Blick...nur ob ich mir damit nicht doch irgendwo Probleme reinhole, kann ich (noch) nicht sagen.
RE: Frage zu "queued state machine" Architektur - GerdW - 05.08.2016 14:25
Hallo joptimus,
entweder entkoppelst du die beiden Statemachines - oder du bindest die zweite in die erste ein…
Ich würde sie trennen: eine Statemachine arbeitet die UI-Befehle ab und kommandiert die Mess-Statemachine. Die Mess-Statemachine arbeitet die Messung ab. Wenn man die Messung als Queued-Statemachine implementiert, kann man eine komplette Messung als Befehlssatz in eine Queue schicken. Und wenn man die Messung abbrechen will, leert man die Queue oder stellt den STOPP-Befehl "am falschen Ende" rein…
RE: Frage zu "queued state machine" Architektur - joptimus - 05.08.2016 14:34
(05.08.2016 14:25 )GerdW schrieb: Hallo joptimus,
entweder entkoppelst du die beiden Statemachines - oder du bindest die zweite in die erste ein…
Ich würde sie trennen: eine Statemachine arbeitet die UI-Befehle ab und kommandiert die Mess-Statemachine. Die Mess-Statemachine arbeitet die Messung ab. Wenn man die Messung als Queued-Statemachine implementiert, kann man eine komplette Messung als Befehlssatz in eine Queue schicken. Und wenn man die Messung abbrechen will, leert man die Queue oder stellt den STOPP-Befehl "am falschen Ende" rein…
Ich kann mir gerade nicht so ganz vorstellen, wie das Entkoppeln im Blockdiagramm aussehen soll. Die Statemachine für das UI erkennt "Messung 1 soll ausgeführt werden". Aber wie genau würde sie dann die korrekte Mess-Statemachine auswählen?
Der Messablauf ist zwar prinzipiell vorgegeben, aber nicht komplett:
z.B. wird bei zwei Achsen die eine erst dann verfahren, wenn die andere eine bestimmte Position erreicht hat. Das kann bei einer Durchführung passieren, bei der nächsten aber nicht. Weiterhin habe ich Messungen, bei denen der Nutzer an anderer Stelle manuell etwas einstellen und in LabVIEW quittieren muss. Ich kann also nicht einfach eine festgelegte Reihenfolge an Befehlen in die Mess-Statemachine schicken...denke ich.
Vielleicht kannst du mir bitte mit einem anschaulichen Beispiel aushelfen?
Edit:
Aktuell sieht das so aus. Das VI selbst habe ich auch mal angehängt.
[attachment=56421]