LabVIEWForum.de

Hallo,

habe ein kleines Problem mit QSM.

Meine Parser Schleife bekommt befehle über eine Queue und führt diese aus:

Read&Parse
Idle
Exit

und noch paar andere.

Sobald die Schleife den Befehl Read&Parse bekommt, fängt diese an die Schnittstelle auszulesen und die Daten zu parsen UND nachdem es gemacht ist, befiehlt die sich selbst Read&Parse und macht es solange bis etwas anderes kommandiert wird.

Stellt euch vor, die Schleife ist gerade in diesem Dauerzustand Read&Parse. Jetzt wird von außen Idle kommandiert, nun wird der Zustand ausgeführt und nach dem Ausführen wird der Befehl Read&Parse wie oben beschrieben kommandiert. Somit befinden sich jetzt zwei Befehle in der Statequeue. Als nächstes sind wir im State Idle, da aber noch ein Befehl "Read&Parse" in der Queue ist kommen wir wieder in den Dauerzustand "Read&Parse".

D.h. ich komme da nicht mehr raus!?!? Ok, das habe ich jetzt gelöst in dem ich im Zustand Idle die Queue flushe (alle Elemente löschen). Und damit bekomme ich mein nächstes Problem:

wenn ich gleich nach dem "Idle" den "Exit" machen will wird es nicht mehr aqusgeführt, da alle Elemente inclusive "Exit" aus der Statequeue entfernt wurden.

Was kann man dagegen tun? Befehlsunterscheidung? Andere Vorgehensweise?

Ich warte auf euere Vorschläge

eg

' schrieb:wenn ich gleich nach dem "Idle" den "Exit" machen will wird es nicht mehr aqusgeführt, da alle Elemente inclusive "Exit" aus der Statequeue entfernt wurden.

ich mach das tatsächlich so, dass ich vor dem exit die Queue flushe und dann die "Exit Sequenz" einleite, in dem ich genau die States reinschreibe, die für eine saubere Beendigung des Programms notwendig sind. Dabei darf natürlich nichts anderes mehr in die Queue geschrieben werden, die diese Sequenz beeinflussen könnte

Danke, aber diese Vorgehensweise wird, wenn ich alles richtig verstanden habe, nicht reichen oder das Problem lösen. Könntest du bitte einen kleinen Beispiel posten?

eg

Du könntest für das von dir beschriebene Problem das Exit-Element an den Anfang der Queue schreiben.
(Enqueue Element At Opposite End)

Du must dabei aber sicher sein, das du die anstehenden Elemente in der Queue nicht ausführen musst, oder im Exit dann schauen ob nicht noch was wichtiges in der Queue ist/war. (File-Close, DAQ-Stopp.......)

Gruss
Roland

Ich würde die Statemachine um einen expliziten State "End Read&Parse" erweitern. Es müsste dann aber zwei "Read&Parse"-Typen geben: einen von außen angestoßenen und einen innerhalb der SM erzeugten. "End Read&Parse" setzt ein Flag, das von "Read&Parse-TypAußen" gelöscht wird. Kommt ein "Read&Parse-TypInnen" an, wird "Read&Parse" nur ausgeführt, wenn das Flag aus ist. Dadurch wird also kein "Read&Parse-TypInnen" mehr erzeugt. Kommt ein jeodch "Read&Parse-TypAußen" geht wieder alles von vorne los.

' schrieb:Du könntest für das von dir beschriebene Problem das Exit-Element an den Anfang der Queue schreiben.
(Enqueue Element At Opposite End)

Du must dabei aber sicher sein, das du die anstehenden Elemente in der Queue nicht ausführen musst, oder im Exit dann schauen ob nicht noch was wichtiges in der Queue ist/war. (File-Close, DAQ-Stopp.......)

Gruss
Roland

Es geht nicht nur um den State "Exit", sondern um ein paar andere auch.

' schrieb:Ich würde die Statemachine um einen expliziten State "End Read&Parse" erweitern. Es müsste dann aber zwei "Read&Parse"-Typen geben: einen von außen angestoßenen und einen innerhalb der SM erzeugten. "End Read&Parse" setzt ein Flag, das von "Read&Parse-TypAußen" gelöscht wird. Kommt ein "Read&Parse-TypInnen" an, wird "Read&Parse" nur ausgeführt, wenn das Flag aus ist. Dadurch wird also kein "Read&Parse-TypInnen" mehr erzeugt. Kommt ein jeodch "Read&Parse-TypAußen" geht wieder alles von vorne los.

Beispiel ins Studio (wenn es geht).

Danke, eg


P.S. im Anhang was zum Basteln.

(VI LV 8.0)

Keine weiteren Vorschläge?

' schrieb:Beispiel ins Studio (wenn es geht).

Geht nicht.

Ich hätte ja gerne dein Muster erweitert. Das geht aber mit meiner LV8.2 nicht. Wenn dann würde ich sowieso anstelle eines Strings einen Enumerator nehmen. Beim Erstellen eines Enumerators aber stürzt die komplette IDE wortlos ab.

' schrieb:Geht nicht.

Ich hätte ja gerne dein Muster erweitert. Das geht aber mit meiner LV8.2 nicht. Wenn dann würde ich sowieso anstelle eines Strings einen Enumerator nehmen. Beim Erstellen eines Enumerators aber stürzt die komplette IDE wortlos ab.

Hey, was hast du denn? Spinnt dein LV?

eg

' schrieb:Hey, was hast du denn? Spinnt dein LV?

Meins? Meins wenns wäre, gings. LV8.2 (nicht LV8.2.1) hat diverse schwere Fehler, so z.B. den, über den es hier auch einen langen Thread gibt: LV stürzt bei "Eigenschaft" eines Zahl-Bedienelementes ab.

Hier auf diesem Rechner mit LV8.2.1 sieht die Sache schon anders aus: siehe Anhang. Der Enumerator sollte wegen der Erweiterbarkeit natürlich ein strikter Typ sein.