INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

Frage zu "queued state machine" Architektur



Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!

05.08.2016, 13:57 (Dieser Beitrag wurde zuletzt bearbeitet: 05.08.2016 14:16 von joptimus.)
Beitrag #1

joptimus Offline
LVF-Grünschnabel
*


Beiträge: 12
Registriert seit: Aug 2015

2014 SP1
2010
EN



Question Frage zu "queued state machine" Architektur
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:

  1. Benutzerinterface (hier wird der Messablauf gewählt)
  2. 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.
  3. 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?

   

Ist auch hier gepostet:
http://forums.ni.com/t5/LabVIEW/Architec...-p/3331462


Angehängte Datei(en)
15.0 .vi  queued state machine-pc_forum.vi (Größe: 23,45 KB / Downloads: 223)
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
05.08.2016, 14:12 (Dieser Beitrag wurde zuletzt bearbeitet: 05.08.2016 14:14 von GerdW.)
Beitrag #2

GerdW Offline
______________
LVF-Team

Beiträge: 17.465
Registriert seit: May 2009

LV2021
1995
DE_EN

10×××
Deutschland
RE: Frage zu "queued state machine" Architektur
Hallo joptimus,

bitte immer auf Crossposts hinweisen!

Wozu brauchst du die innere While-Loop in der mittleren Statemachine?

Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
05.08.2016, 14:19 (Dieser Beitrag wurde zuletzt bearbeitet: 05.08.2016 14:23 von joptimus.)
Beitrag #3

joptimus Offline
LVF-Grünschnabel
*


Beiträge: 12
Registriert seit: Aug 2015

2014 SP1
2010
EN



RE: Frage zu "queued state machine" Architektur
(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.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
05.08.2016, 14:25
Beitrag #4

GerdW Offline
______________
LVF-Team

Beiträge: 17.465
Registriert seit: May 2009

LV2021
1995
DE_EN

10×××
Deutschland
RE: Frage zu "queued state machine" Architektur
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…

Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
05.08.2016, 14:34 (Dieser Beitrag wurde zuletzt bearbeitet: 05.08.2016 15:03 von joptimus.)
Beitrag #5

joptimus Offline
LVF-Grünschnabel
*


Beiträge: 12
Registriert seit: Aug 2015

2014 SP1
2010
EN



RE: Frage zu "queued state machine" Architektur
(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.
   


Angehängte Datei(en)
15.0 .vi  LL_parken_v4.vi (Größe: 56,64 KB / Downloads: 186)
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Antwort schreiben 


Möglicherweise verwandte Themen...
Themen Verfasser Antworten Views Letzter Beitrag
  Frage zur Architektur: Statemachine und Wait for Events tuhpon 6 4.460 18.03.2024 16:14
Letzter Beitrag: tuhpon
  Machine learning Hubert R. 3 2.505 29.08.2023 10:10
Letzter Beitrag: Hubert R.
  Architektur für sequenziellen Prozess mit Einzelschrittauswahl Lime 1 2.477 29.06.2021 17:59
Letzter Beitrag: GerdW
  Programm beenden State Machine simcum 3 3.412 17.10.2020 20:57
Letzter Beitrag: BNT
Wink Aufbau & die Architektur vom LabVIEW DAYA 3 3.977 31.03.2017 19:44
Letzter Beitrag: DAYA
  Queued State Machine: IDLE Optimierung ALuehmann 3 4.908 14.02.2017 14:00
Letzter Beitrag: HVo

Gehe zu: