+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+--- Thema: Modularer Aufbau (/Thread-Modularer-Aufbau)
Modularer Aufbau - Y-P - 24.08.2007 10:28
........ Danke, das wünsche ich Dir auch.
Gruß Markus
' schrieb:Hallo Markus,
habe dein Beispiel ausprobiert. Doch bei mir kam dann immer der Header und nur eine Messreihe. Bei den Zahlenbeispiel von dir hats ja geklappt. Ich weiss nicht warum das Array bei mir nicht mit Messwerten gefuellt wurde. Habe aber ein anderen trick herausgefunden.
Vielen Dank nochmal fuer deine Hilfe.
Schoenes Wochenende.
Gruss
Modularer Aufbau - Grobi - 19.09.2007 08:29
Tach
So wie gestern auch hol ich nochmal wieder einen bissl älteren Beitrag raus.
Und zwar.. Ich habe jetzt schon öfter was von State Machines gehört/gelesen. Also mal ein bisschen hier im
Forum gesucht. In Beitrag 4 dieses Themas sehe ich dann von Y-P ein Beispiel zur State Machine
was ich mir mal anschaue.
Da ist mir was aufgefallen..Ich benutze auch Event-Strukturen, z.B. zur Verwaltung eines Hauptprogrammes
um damit Sub-VIs etc. aufzurufen.
Ich hatte es bis jetzt so gehalten, dass wenn, nehmen wir an, ein Button eine Wertänderung erfährt, das Sub-VI oder
der auszuführende Code direkt in der Event-Struktur liegt.
In dem geposteten VI befindet sich die Struktur quasi als reines Auswahlmenü in einer übergeordneten Case-Struktur,
welche dann im Endeffekt den auszuführenden Code enthält.
Meine Frage dazu ist, warum macht man das? Gilt das der Übersichtlichkeit, oder was steckt dahinter? Oder vielleicht liegt es
nur an dem benötigten Initialisierungscase, welcher aber vielleicht auch mit nem angeschlossenen Timeout zu handlen wäre?
Ist mir nur so aufgefallen. Vielleicht ist die Frage auch selten doof, das weiß ich nicht. Aber vielleicht behandle ich meine
Event-Strukturen auch falsch. Nicht wundern, es interessiert mich nur
mfG
Robert
Modularer Aufbau - Achim - 19.09.2007 08:53
Das macht man deswegen, weil der Code in nem Eventcase evtl. länger dauern kann...und erst wenn dieser Code beendet ist, reagiert die Eventstruktur auf das nächste Event!
Darum ist das Vorgehen beispielhaft so:
- Schleifeniteration n: Event "Messen" auslösen
- Schleifeniteration n+1: Im entsprechenden Eventcase die "Anfrage weiterleiten" an Case "Messen"
- Schleifeniteration n+2: Case "Messen" wird erreicht, Messung durchführen (z.B. 1000 Messwerte abholen), dann Entscheidung ob weiter "Messen" oder z.b. "Auswerten" oder "Beenden"
- Schleifeniteration n+3: Entweder wieder Case "Messen" anspringen (nächste 1000 Werte) oder "Auswerten" oder "Beenden"
- Schleifeniteration n+4: ...
Gruss
Achim
Modularer Aufbau - rolfk - 19.09.2007 09:40
' schrieb:Das macht man deswegen, weil der Code in nem Eventcase evtl. länger dauern kann...und erst wenn dieser Code beendet ist, reagiert die Eventstruktur auf das nächste Event!
Darum ist das Vorgehen beispielhaft so:
- Schleifeniteration n: Event "Messen" auslösen
- Schleifeniteration n+1: Im entsprechenden Eventcase die "Anfrage weiterleiten" an Case "Messen"
- Schleifeniteration n+2: Case "Messen" wird erreicht, Messung durchführen (z.B. 1000 Messwerte abholen), dann Entscheidung ob weiter "Messen" oder z.b. "Auswerten" oder "Beenden"
- Schleifeniteration n+3: Entweder wieder Case "Messen" anspringen (nächste 1000 Werte) oder "Auswerten" oder "Beenden"
- Schleifeniteration n+4: ...
Gruss
Achim
Hallo Achim,
Dein initieller Grund warum man sowas macht ist aber nur effektiv, wenn man die State Machine mit Queues macht und die Event-Abhandlung in eine andere parallele Loop setzt als die eigentliche Event-Detektion.
Persönlich mache ich das aber eher selten. Was ich normalerweise habe ist eine Case Struktur die die verschiedenen States abarbeitet und im Default case davon die Event-Struktur. Der Hauptgrund warum ich die Abarbeitung bestimmter Events überhaupt in einen State setze ist vor allem der dass solche States oft von verschiedenen Events getriggert werden können. Zum Beispiel hast Du Menus die bestimmte Aktionen triggern oder auch Kontrollelemente. Auf diese Weise wird der eigentliche Code nur einmal implementiert. Auch ist es bei komplexeren Userinterfaces oft so dass die verschiedenen Aktionen recht komplex werden können, und dann teile ich oft eine Aktion in mehrere Unterstates und mache ich aus dem State Register ein Array von States wo neue Aufgaben am Ende angehängt werden können und der nächste (Sub)State jeweils am Anfang weggeholt wird.
Dies ist extrem flexibel da man eine bestimmte Aktion in mehrere Sub(States) aufteilen kann und diese dann aus verschiedenen Teilen des Programmes in unterschiedlicher Reihenfolge aufrufen kann. Auch kann man durch Hinzufügen eines neuen States am Anfang eine bestimmte Aktion priorisiert ausführen lassen indem man sie quasi in die Statequeue hineinschiebt.
Aber hier gleich eine Warnung: Eine solche Architektur ist ohne ein sinnvolles Statechart praktisch nicht mehr zu kontrollieren, es sei denn man besitzt über ein Gehirn das in dreidimensionaler Sequenzlogik ausgezeichnet trainiert ist.
Rolf Kalbermatter