Hi
So ich wusste jetzt nicht wirklich wohin mit dem Thema - deswegen einfach mal hier.
Anbei sind 2 Beispielprogramme für eine kleine Statemaschine. Das ganze kann noch durch mehrere States ausgebaut werden und somit ziemlich effektiv eingesetzt werden.
Die Programme unterscheiden sich nur durch die "Queue-Funktion" (Element Einfügen) und (Element am Anfang Einfügen) im State (Dateibearbeitung).
Wenn ich nun im Frontpanel die Taste (nächste Messung) z.B. 10 mal schnell hintereinander drücke möchte ich das der "State" (Messwertvorgabe) immer zwingend nach dem "State" (Dateibearbeitung) abläuft. Deswegen auch die "Queue-Funktion (Element am Anfang Einfügen).
Beim Statemachine.vi funktioniert das auch so was man am blinken der LED's sieht. Zum Vergleich bei Statemachine2.vi läuft das völlig unkoordiniert ab.
Meine Frage nun zur Diskussion:
Wie kann ich mit solch einer Struktur sicherstellen das ein bestimmter State "immer" und "zwingend" nach einem anderen State abläuft. Es könnten ja theoretischer Weise bei größeren Programmen noch weitere Elemente in die Queue verschoben werden die dann auch wieder die Reihenfolge durcheinander bringen.
Ist das überhaupt möglich oder muss man solchen Code besser in einen State programmieren - z.B. als Sequenzstruktur?
Bei einem weit komplexeren Code - denn ich hier leider nicht einstellen kann - hab ich nämlich genau das Problem das die State unkoordiniert angefahren werden was nicht der Fall sein darf.
Ok - hoffe ich habe mich deutlich ausgedrückt und freu mich auf eure Antworten.
Viel Spass mit denn Codes. Ist vielleicht auch so für den ein oder anderen nützlich.
[
attachment=16230]
[
attachment=16232]
Das braucht Ihr eventuell noch - [
attachment=16231]
Gruß Martin
Also ohne jetzt den Code angesehen zu haben...
ich mache das immer so, dass ich einen IDLE State habe in den sie Statemachine springt, wenn der aktuelle State abgearbeitet wurde.
Möchte ich jetzt z.B. zwingend einen State nach einem Anderen ausführen, dann springt die Statemachine halt nicht in den IDLE State sondern in den, den ich brauche. Ist dieser State fertig, gehts wieder in den IDLE State oder zum nächsten zwingenden State.
Hab das in einem basic mp3 Player so gemacht. Such mal im Forum nach "play mp3 mit winapi winmm.dll" da solltest du das finden, wenn dich das als Beispiel interessiert.
Dort ist es erforderlich, dass vor dem Play-State der Open-State ausgeführt wird. Und nach dem Stop-State der Close-State.
Gruß SeBa
Hi
Das Prinzip der Statemachine mit Idle State gibt es hier ja auch.
Das Problem liegt vielmehr darin wie die Queue Funktion die Elemente anordnet denke ich.
Die Statemachine hier ist in Verbindung mit der Ereignisstruktur nicht so sehr prozessorlastig. Deswegen hab ich mich ja auch für diese Variante entschieden.
Werde mir dein Beispiel jetzt gleich einmal ansehen.
Gruß
Martin
Du könntest deine Queue als Array von Enums erstellen und die entsprechenden States nacheinander setzen.
Die richtige alternativen Status-Reihenfolge hast Du doch, wenn Du den Status "Messwertvorgabe" gleich oben im Ereigniscase erzeugst und nicht erst unten.
(Bei dem ähnlichen Vorschlag von Role gibt es Komplikationen wegen der erforderlichen Änderung des Queue- Datenfomates von "Enum" zu "Array of Enum")
[
attachment=24163]
Hi
Danke für die Inspirationen. Also das mit denn Arrays macht bei großen Programmen alles wieder unübersichtlich.
Bei dem Beispiel von Lucki hab ich aber auch noch das Problem das nicht garantiert ist das der Status am Ende der queue gesetzt wird. Da ist die Variante mit "Element am Anfang einfügen" doch die bessere!?!
Hab das ganze bei meinem großen Programm übrigens jetzt hinbekommen. Hab in denn Stadien welche zwingend hintereinander laufen sollen immer mit "Element am Anfang einfügen" gearbeitet. Allerdings trau ich dem ganzen noch nicht so.
Was auch noch Interessant wär (z.B. für einen Not-Aus) eine höhere Priorität hinzuzufügen. Aber das würd ich jetzt einfach mit "Queue löschen" und dann neuen State "Ende" oder so erledigen. Oder geht das auch besser?
Kann man die Queue eigentlich irgendwie darstellen. Ich glaub da fehlt mir noch ein bisschen das Verständnis wie die organisiert sind.
Gruß
Martin
' schrieb:Danke für die Inspirationen. Also das mit denn Arrays macht bei großen Programmen alles wieder unübersichtlich.
Bei dem Beispiel von Lucki hab ich aber auch noch das Problem das nicht garantiert ist das der Status am Ende der queue gesetzt wird. Da ist die Variante mit "Element am Anfang einfügen" doch die bessere!?!
Das vertehe ich nicht. Es wird überhaupt kein Queue-Status abgefragt, und ich behaupte dass es wasserdcht funktioniert. Übertroffen würde diese Sicherheit nur noch, wenn Du, wie du schon sagtest, beide Tasks in eine einzige Sequenz reinpacken würdest.
Vergiss "Element am Anfang einfügen", das ist als wenn sich jemand in der Schlange ganz nach vorn drängelt und hat hier bei Dir nichts zu suchen.
Zitat:Kann man die Queue eigentlich irgendwie darstellen. Ich glaub da fehlt mir noch ein bisschen das Verständnis wie die organisiert sind.
Das unnötige 100ms Wait ist mir z.B. ein Indiz, daß Du die Funktionsweise der Queues noch nicht richtig verinnerlicht hast. "Element aus der Queue holen" wartet nämlich von selbst, solange die Queue noch leer ist. Das Wait ist überflüssig oder sogar schädlich.
Die Queues sind doch so einfach zu verstehen: Was neu hinzukommt, stellt sich hinten an, abgeholt wird vorn. Hast Du selbst noch nie Schlange gestanden?
' schrieb:So ich wusste jetzt nicht wirklich wohin mit dem Thema - deswegen einfach mal hier.
So, mit RT hat das aber nichts zu tun.:verschoben12:
Gruß, Jens
Hi
Zitat:Bei dem Beispiel von Lucki hab ich aber auch noch das Problem das nicht garantiert ist das der Status am Ende der queue gesetzt wird. Da ist die Variante mit "Element am Anfang einfügen" doch die bessere!?!
Da habe ich mich wohl falsch ausgedrückt. Sollte heißen "Status am Anfang der ..." usw.
Zitat:Vergiss "Element am Anfang einfügen", das ist als wenn sich jemand in der Schlange ganz nach vorn drängelt und hat hier bei Dir nichts zu suchen.
Also ich denke das sich eher beim normalen Einfügen jemand vordrängelt. Funktioniert tut das Ganze ja nicht mit dem "hinten Anstellen". Zur Erklärung:
Bei dem großen Programm hab ich z.B. fogenden Ablauf.
1. "State" "Messwerte abholen" - hier werden Daten von einem LCR Meter erfasst
2. "State" "Dateibearbeitung" - hier werden die Messdaten zusammengefasst und in eine Datei geschrieben.
3. "State" "Tabelle erstellen" - hier wird eine Tabelle im Frontpanel aktualisiert.
Das Problem. "State" "Messwerte abholen" wird durch ein Signal von einer Antriebseinheit ausgelöst. Kommt nun dieses Signal und der "State" wird in die Queue geschoben wenn 2. und 3. noch nicht abgearbeitet ist verliere ich die Messdaten da diese nur temporär (Schieberegister) gespeichert werden. In der Queue drängelt sich dann ja 1. vor.
Deswegen das mit der zwingenden Folge. Wie im letzten Post geschrieben kann man das auch mit einer langen Ereignisstruktur abarbeiten.
Ich wollte eigentlich nur eure Meinung hören was denn nun geschickter ist?!? Ist es grundsätzlich falsch so zu programmieren?
Zitat:Das unnötige 100ms Wait ist mir z.B. ein Indiz, daß Du die Funktionsweise der Queues noch nicht richtig verinnerlicht hast
Deswegen frag ich hier ja nach -
Wär eine meiner nächsten Fragen gewesen.
Zitat:So, mit RT hat das aber nichts zu tun. verschoben1.gif
Sorry aber ich hab leider keinen besseren Bereich gefunden...
Nun gut - Da es jetzt erstmal läuft geb ich mich halt zufrieden - allerdings würd ich mich freuen noch ein paar Tips zu bekommen eine ordentliche Struktur hinzubekommen. Schließlich soll der Code ja noch erweitert werden und da will ich besser keine bösen Überraschungen erleben.
Gruß
Martin
P.S. Das mit dem Notaus und der Funktion "Queue löschen" funktioniert einwandfrei.
' schrieb:Das Problem. "State" "Messwerte abholen" wird durch ein Signal von einer Antriebseinheit ausgelöst. Kommt nun dieses Signal und der "State" wird in die Queue geschoben wenn 2. und 3. noch nicht abgearbeitet ist verliere ich die Messdaten da diese nur temporär (Schieberegister) gespeichert werden. In der Queue drängelt sich dann ja 1. vor.
NEIN!
"Messwerte abholen" drängelt sich nur dann vor, wenn die Antriebseinheit mit "Element am Anfang einfügen" arbeitet
Du musst es eben so organisieren, dass im Schritt "Messwerte abholen" gleich die nächsten zu bearbeitenden Schritte nacheinander in die Queue geschrieben werden!