Probleme mit der Ereignisstruktur

Hi, ich hab mal wieder ein Problem wo ich glaube ich einfach irgendwas noch nicht richtig verstanden habe.
Es geht um bestimmte Bedingungen die passiert sein müssen, damit mein Programm startet. Ich hab den Teil mal aus meinem Programm isoliert und beschreibe hier mal die gewünschte Funktion:


1. Button aufzeichnung, ist dieser auf soll Status "Aufzeichnung nicht aktiv" ausgegeben werden. Anschließend soll gewartet werden, bis sich der Status von Aufzeichnung ändert.

2. Wurde der Button Aufzeichnung betätigt soll ein Regelkreis aufgebaut werden. In dieser Zeit soll der Button Aufzeichnung gesperrt werden damit dieser Prozess nicht unterbrochen werden kann. Es soll der Status "Regelkreis aufbauen Wartezeit x".

3. Nachdem der Regelkreis aufgebaut ist soll die Sensorik überprüft werden. Ist sie eingeschaltet soll in den Aufzeichnungs True-Case gegangen werden. Ist die Sensorik ausgeschaltet soll der Status "Sensorik ausgeschaltet" ausgegeben werden und an dieser Stelle gewartet werden, bis entweder die Sensorik eingeschaltet wird (dann soll das Programm in den Aufzeichnungs True-Case gehen) oder der Button Aufzeichnug ausgeschaltet wird. In diesem Fall soll erneut gewartet werden, bis dieser wieder eingeschaltet wird.

4. Im True Case soll der Status "Betriebsbereitschaft" so lange ausgegeben werden, bis Aufzeichnung beendet wird.

5. Nach Beenden der Aufzeichnung soll die Sequenz wieder bei Punkt 1 beginnen.


Folgende Probleme hab ich, und ich weiß nicht wie ich sie umgehe:

Punkt 1 klappt, wenn ich das Programm neu beginne. Wenn ich jedoch Punkt 4 beendet habe wartet das Programm nicht auf Wertänderung, sondern durchläuft Punkt 2 und 3 ohne auf Wertänderung zu warten.

Punkt 3 Wenn die Sensorik ausgeschaltet ist, wartet das Programm nicht auf Wertänderung von Aufzeichnung oder Sensorik, sondern gelangt in den Aufzeichnungs True-Case.

Wie es aussieht liegt mein Fehler in der Ereignisstruktur, da diese nicht anhält wenn ich das erwarte, bzw verlange. Es wird ohne die geforderte Wertänderung der nächste Schritt getätigt.
Hoffe mir kann jemand die Funktionsweise näher bringen.

Hallo,

bevor ich mir das VI jetzt genauer anschaue, hier mal ein kleiner Ersteindruck:
- Du vermischt die Strukturen in einer "komischen" Art: Bei 2 Eventstrukturen in einem VI ist schon absolute Vorsicht geboten, aber dass beide das gleiche Ereignis abarbeiten und auch noch ineinander geschachtelt sind geht GAR NICHT. (Woher wissen die Strukturen welche jetzt das Ereignis abfangen soll?)
- Die Case-Struktur um die Eventschleifen sind komischer Stil, am besten ist es du baust alles in eine StateMachine oder in ein Producer/Consumer-Design um

Gruß bis dahin

Hallo Johnny,

No-Go:
- Events sollten immer möglichst schnell abgearbeitet werden. Du dagegen lässt Sequenzen und Schleifen mit langen Wartezeiten im Event ablaufen...

Fragwürdig:
- Warum nutzt du lokale Variablen, wenn die Terminals ungenutzt bleiben?
- Warum ein Wertänderungs-Event innerhalb einer Case-Struktur, die schon vom gleichen Eingabeelement kontrolliert wird?
- Warum eine Wartezeit in der Schleife, statt das vorhandene timeOut-Event ordentlich zu definieren?

Tipps:
- Du hast selbst schon mehrere Punkte definiert. Erstelle daraus eine Statemachine!
- Steuere deine Statemachine über eine Queue, die wiederum von deiner Eventstruktur in einer parallelen Schleife gespeist wird (Producer-Consumer)!
- Die "Namen" bei Propertynodes auszublenden ist zumindest äußerst schlechter Dokumentations-Stil in deinem VI...

(10.07.2013 09:15 )GerdW schrieb:  Hallo Johnny,

No-Go:
- Events sollten immer möglichst schnell abgearbeitet werden. Du dagegen lässt Sequenzen und Schleifen mit langen Wartezeiten im Event ablaufen...

Fragwürdig:
- Warum nutzt du lokale Variablen, wenn die Terminals ungenutzt bleiben?
- Warum ein Wertänderungs-Event innerhalb einer Case-Struktur, die schon vom gleichen Eingabeelement kontrolliert wird?
Das hatte ich gemacht, damit bei ausgeschalteter Sensorik das Programm an der Stelle beendet werden kann.
- Warum eine Wartezeit in der Schleife, statt das vorhandene timeOut-Event ordentlich zu definieren?
Die Wartezeit habe ich nur gemacht, um das geschehen besser beobachten zu können. Konnte und kann nicht verstehen, warum er immer einmal die gesamte Sequenzsturktur durchlaufen hat statt zu warten.

Tipps:
- Du hast selbst schon mehrere Punkte definiert. Erstelle daraus eine Statemachine!
- Steuere deine Statemachine über eine Queue, die wiederum von deiner Eventstruktur in einer parallelen Schleife gespeist wird (Producer-Consumer)!
- Die "Namen" bei Propertynodes auszublenden ist zumindest äußerst schlechter Dokumentations-Stil in deinem VI...
Hatte ich übergangsweise gemacht, um ein wenig Platz zu sparen. gelobe Besserung

Ok danke schon einmal.
Hab vorher mich noch nie mit ner state machine befasst.

Ist es richtig wenn ich dann 4 Status habe, die ich dann in einer case Struktur verarbeite?
Die Status wären dann ja:
Status 0: Aufzeichnung aus
Status 1: Aufzeichnung an, Regelkreis aufbauen
Status 2: Regelkreis aufgebaut, Sensorik aus
Status 3: Regelkreis aufgebaut, Sensorik an

Von der Producer-Consumer Statemachine hab ich nix nix gehört, gibt es dazu ein einfaches Beispiel irgendwo?[/color]

Hallo Johnny,

schon mal im LabVIEW-Startfenster unter "neue Projekte" geschaut?

Bzw. bei LabVIEW 2011 unter "File"->"New..." -> "Frameworks"

Gruß, Jens

Danke allen.

Hab mal versucht das einigermaßen hinzubekommen.
Mag sich das noch einmal jemand angucken und prüfen, ob da Verbesserungsmöglichkeiten sind oder ob das so programmiertechnisch in Ordnung ist?

Hallo Johnny (klingt wie im Western),

ich würde die Queue-Funktion "auf Nachricht warten" in jedem Fall mit einem TO versehen. Sonst hast du ohne Drücken von STOP keine Möglichkeit dieses VI zu beenden, z.B. über das Windowskreuz, was man ja erwarten könnte.


Gruß, Marko

Ich hätte nochmal ne allgemeine Frage zum Producer/Consumer-Design bei Ereignisstrukturen:
Wenn ich die eintreffenden Ereignisse der Producer Schleife mittels Queue asynchron in der Consumer Schleife abarbeite, ist das nicht im Prinzip dasselbe als wenn ich nur eine Ereignisstruktur (ohne Producer/Consumer Design) mit der Option "Benutzereingriffe auf dem Frontpanel erst verarbeiten, wenn der Ereignis-Case abgeschlossen ist" verwende? Immerhin passiert hier nun auch nichts anderes als dass die Ereignisse intern in eine Art Queue gelegt, nach und nach abgearbeitet werden und das Frontpanel auch wie gewünscht nicht blockiert wird.
Oder worin liegt der Vorteil dieses Producer/Consumer-Designs bei Ereignisstrukturen?

Hier der Auszug von der NI-Webseite:

Code:

Why use Producer/Consumer?

The Producer/Consumer pattern gives you the ability to easily handle multiple processes at the same time while iterating at individual rates. What makes this pattern unique is its added benefit of buffered communication between application processes. When there are multiple processes running at different speeds, buffered communication between processes is extremely effective. For example, an application has two processes. The first process performs data acquisition and the second process takes that data and places it on a network. The first process operates at three times the speed as the second process. If the Producer/Consumer design pattern is used to implement this application, the data acquisition process will act as the producer and the network process the consumer. With a large enough communication queue (buffer), the network process will have access to a large amount of the data that the data acquisition loop acquires. This ability to buffer data will minimize data loss.

Und hier der Link zu der Seite:
http://www.ni.com/white-paper/3023/en/

Dort steht die Antwort auf Deine Frage.

Gruß Markus

(22.07.2013 13:03 )ash schrieb:  Ich hätte nochmal ne allgemeine Frage zum Producer/Consumer-Design bei Ereignisstrukturen:
Wenn ich die eintreffenden Ereignisse der Producer Schleife mittels Queue asynchron in der Consumer Schleife abarbeite, ist das nicht im Prinzip dasselbe als wenn ich nur eine Ereignisstruktur (ohne Producer/Consumer Design) mit der Option "Benutzereingriffe auf dem Frontpanel erst verarbeiten, wenn der Ereignis-Case abgeschlossen ist" verwende? Immerhin passiert hier nun auch nichts anderes als dass die Ereignisse intern in eine Art Queue gelegt, nach und nach abgearbeitet werden und das Frontpanel auch wie gewünscht nicht blockiert wird.
Oder worin liegt der Vorteil dieses Producer/Consumer-Designs bei Ereignisstrukturen?