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.09.2007, 15:51 (Dieser Beitrag wurde zuletzt bearbeitet: 05.09.2007 15:56 von eg.)
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?
' 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?
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
.·´¯)--> Leben ist das, was dir passiert, wenn du eifrig dabei bist andere Pläne zu machen <--(¯`·.
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.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
06.09.2007, 12:52 (Dieser Beitrag wurde zuletzt bearbeitet: 22.12.2007 21:43 von jg.)
' 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.
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.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
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.
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.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
