Mit oder ohne Evenstruktur?

Hallo LVF.

Ich habe ein LV-Programm mit 5 Moeglichkeiten und wuerde gerne wissen, ob folgendes besser mit einer Eventstruktur oder einer SubVi zu realisieren ist.

Ich habe, wie gesagt, 5 Moeglichkeiten:

1) Infuse
2) Withdrawl
3) JM1
4) JM2
5) Flow without target, so long until stop button is pressed

Alle Moeglichkeiten werden mit true/false-Buttons gestartet und die Faelle 1,2 und 5 unterscheiden sich zusaetzlich um eine boolesche Variable, die manuell auf true oder false vorher gesetzt werden muss.
Ich haenge meine Main.vi als Png an. Darauf sieht man die Booleans Infuse, Widthdrawl, JM1 (Jiggle Method 1), JM2 (Jiggle Method 2).
Alle "Methoden" befinden sich in case-Strukturen. (Damals hatte ich noch kein LV2009 zur Verfuegung).

Meine urspruenglicher erster Ansatz bestand darin, in jede Case-Struktur eine Subvi einzubauen, die dann die Eigenschaften wie Volumengroesse, Flussrate, Richtung in eine Tabelle schreibt, wofuer es eine subvi geben soll. Allerdings muesste ich dann von jeder Case-Struktur ein Kabel zur Subvi ziehen, die innerhalb der inneren, groesseren Schleife sitzt und die Daten registriert bzw. sammelt.
Kann man nicht soetwas auch mit einer Evenstruktur abarbeiten, die innerhalb der inneren, groesseren Schleife sitzt? Dann erspare ich mir vielleicht Kabelsalat.
Im Moment wuerde ich eine Eventstruktur bevorzugen, weil Fall 5 kompliziert ist. Ich moechte dort erst die Daten in meine Tabelle schreiben, wenn ein Stop ausgefuehrt worden ist. Erst dann weiss ich, wieviel Volumen ueberhaupt ausgeflossen ist, weil mit dem Stop-Button die Pumpbewegung aufhoert.
Diese Stop-Bolean sizt momentan in einer Evenstruktur in der inneren, kleineren Schleife.


Meine zweite Frage lautet wie folgt:
Eventstrukturen reagieren ja auf Veraenderungen, z.b. wenn ein Boolean seinen Wert veraendert.
Fall 5 unterscheidet sich von Fall 1,2 dahingehend, dass eine zweite Boolean auf falsch (5) statt wahr (1,2) gesetzt wird. Koennen Evenstrukturen auch funktionieren, wo zwei Variabeln gleichzeitig betrachtet werden, damit der richtige Eventcase ausgeloest wird?

Die Events waeren z.B. dann so:

1)infuse, set_target=true
2)withdraw, set_target=true
5) infuse, set_target=false

Oder ist es dann besser, in die Evenstruktur eine normale case-Struktur hineinzupacken, die sich dann um die zweite Variabel set_target kuemmert?

Danke schoen fuer einen Ratschlag.
Gruss
Blue

Hallo Blue,

schön wäre es, wenn du dein UI von deiner Arbeitsschleife trennst und ein Producer-Consumer-Pattern einführst. Und im Consumer dann noch eine State-Machine zur Abarbeitung deiner verschiedenen States!

Dann könntest du noch diese ganzen lokalen Variablen entfernen...

"Koennen Evenstrukturen auch funktionieren, wo zwei Variabeln gleichzeitig betrachtet werden, damit der richtige Eventcase ausgeloest wird?"
Du kannst in einem Eventcase ohne Probleme auf mehrere Werte zurückgreifen. Und bitte: LabVIEW hat keine Variablen (zumindest nicht im klassisch text-basierten Programmierschema)...

"in die Evenstruktur eine normale case-Struktur hineinzupacken, die sich dann um die zweite Variabel set_target kuemmert?"
Das geht natürlich auch.

Aber: Events sollten immer schnell abgearbeitet werden, damit andere Events nicht blockiert werden. Deshalb die vorgeschlagene Trennung von UI und DAQ!

"Meine urspruenglicher erster Ansatz bestand darin, in jede Case-Struktur eine Subvi einzubauen, die dann die Eigenschaften ... in eine Tabelle schreibt, wofuer es eine subvi geben soll. Allerdings muesste ich dann von jeder Case-Struktur ein Kabel zur Subvi ziehen,"
Wenn man eine FGV benutzt, braucht man keine Drähte zu anderen Schleifen/Cases und hat diese Daten trotzdem an einer Stelle verwaltet...

Guten Morgen, GerdW.
Danke zunächst für Deine Antwort, zu der ich weitere Fragen habe.
Eine kleine Anmerkung vor weg: Ich bin immer noch blutiger Anfänger und von Beruf nicht Programmierer. Ich habe das nie richtig gelernt, immer nur DIY. Guter Programmierstil ist mir daher noch fremd. Ich bitte das zu entschuldigen. Oftmals wird auch nicht Zeit dafür eingeplant, sowas zu lernen.

' schrieb:Hallo Blue,

schön wäre es, wenn du dein UI von deiner Arbeitsschleife trennst und ein Producer-Consumer-Pattern einführst. Und im Consumer dann noch eine State-Machine zur Abarbeitung deiner verschiedenen States!

Meinst du damit, daß man alle Programme in SubVi steckt, damit man bei späteren Veränderungen es einfacher hat?
Ich weiß nicht, wie man das UserInterface (=UI?) von der äußeren Arbeitschleife trennt. Producer-Consumer-Pattern sagt mir leider auch nichts. Das klingt aber sehr kompliziert, wahrscheinlich für meine Fähigkeiten zu kompliziert, um es binnen 24h zu realisieren. Kannst du vielleicht ein Beispiel für ein Producer-Consumer-Pattern geben oder gibt es grundsätzlich, LabView-Literatur, die auch solche schweren Beispiele abdeckt?

' schrieb:Dann könntest du noch diese ganzen lokalen Variablen entfernen...

Welche z.B.?

' schrieb:Du kannst in einem Eventcase ohne Probleme auf mehrere Werte zurückgreifen. Und bitte: LabVIEW hat keine Variablen (zumindest nicht im klassisch text-basierten Programmierschema)...

Nennt man das dann tatsächlich Boolean mit Wert true/false?

' schrieb:Aber: Events sollten immer schnell abgearbeitet werden, damit andere Events nicht blockiert werden. Deshalb die vorgeschlagene Trennung von UI und DAQ!

Der erste Satz von Dir ist verständlich. Fall 5) ist es auch, weswegen ich eine Eventstruktur basteln würde. Sobald der Knopf "stop" gedrückt wird, sollen von der Pumpe Daten ausgelesen werden. Das sollte doch schnell gehen und keine anderen Events hoffentlich blockieren. Was meint bitte DAQ in diesem Sinne, eventuell Data Acquisition?
Meinst du etwa, man hat die äußere Schleife und packt alles andere in Eventstrukturen außerhalb dieser Schleife?
Ich weiß nicht, wie man diese äußere Schleife sonst umgeht. Ich brauche sie, weil das Programm immer wieder ablaufen soll. Aber vielleicht erübrigt sich das, wenn ich Evenstrukturen einführe.
Wie gesagt, mein grundsätzlicher Ansatz ist LabView 8.6 zu verdanken, weil ich in der Version keine Evenstruktur hatte.

' schrieb:Wenn man eine FGV benutzt, braucht man keine Drähte zu anderen Schleifen/Cases und hat diese Daten trotzdem an einer Stelle verwaltet...

Okay, ich sehe es ein, daß es kompliziert wird. Ich muß mehr Zeit für LabView-Lernen veranschlagen. Mein supervisor denkt halt, das wäre alles ganz einfach, ein gutes LV-Programm zu schreiben, was in Echtzeit fehlerfrei arbeitet und mögliche Fehler abfängt.

Viele Grüße
Blue

Ich habe Dein Bild überflogen und kann auf die Schnelle nur sagen, dass eine 2. Eventstruktur in einem VI überhaupt nicht empfehlenswert ist.
Da Du aber schon eine Eventstruktur verwendest, solltest Du keine weitere Eventstruktur einfügen.
Leider habe ich gerade nicht mehr Zeit, um Dein VI genauer anzuschauen.

Gruß Markus

Hallo Blue,

"Producer-Consumer-Pattern sagt mir leider auch nichts."
Dann guck mal in die LabVIEW Examples, da ist dieses Pattern dabei...

lokale Variablen: "Welche z.B.?"
So ziemlich alle, die ich gesehen habe... LabVIEW speichert Werte nicht in irgendwelchen "Variablen", sondern in den Drähten!

"Nennt man das dann..."
Das nennt man "lokale Variable"/"local" - diese erzeugen aber immer eine Kopie der Daten und können zu RaceConditions führen. Wann immer möglich, solltest du stattdessen Drähte verwenden.

"Meinst du etwa, ..."
Guck dir das Producer-Consumer-Example an! Deine Eventstruktur wird Producer (von Befehlen), dein Consumer arbeitet die Befehle ab. Die Kommunikation dieser zwei Schleifen wird im Example gezeigt...

"Mein supervisor denkt halt, das wäre alles ganz einfach, ein gutes LV-Programm zu schreiben, was in Echtzeit fehlerfrei arbeitet und mögliche Fehler abfängt."
Wie kommt dein Supervisor darauf? Warum sollte das Schreiben eines guten Programms in LabVIEW einfacher und schneller vonstatten gehen als in text-basiertem Programmieren? Warum sollte man dafür keine Schulung einplanen? (Guck mal hier: www.ni.com/training)

' schrieb:Warum sollte das Schreiben eines guten Programms in LabVIEW einfacher und schneller vonstatten gehen als in text-basiertem Programmieren?

Weil das der Verkäufer von LabVIEW (von NI-Produkten) so rübergebracht hat ...

Anzeige

' schrieb:"Mein supervisor denkt halt, das wäre alles ganz einfach, ein gutes LV-Programm zu schreiben, was in Echtzeit fehlerfrei arbeitet und mögliche Fehler abfängt."
Wie kommt dein Supervisor darauf? Warum sollte das Schreiben eines guten Programms in LabVIEW einfacher und schneller vonstatten gehen als in text-basiertem Programmieren? Warum sollte man dafür keine Schulung einplanen? (Guck mal hier: www.ni.com/training)

Guten Abend, alle miteinander. Danke für Eure Antworten. Ich würde gerne ausführlicher auf sie nächste Woche eingehen. Es ist gerade schlecht, weil am Mittwoch das Experiment beginnt. Im Moment macht mein LV-Programm ja auch etwas. Es ist nicht gut programmiert, aber es macht wenigstens was

LV wurde für mein Projekt gewählt, weil meinen beiden Chefs gesagt worden ist, wirklich jeder kann ganz easy was in LabView schnell programmieren. Tja, also bin ich jetzt die Versuchsratte. Nach der Messzeit setze ich mich regelmäßig hin und versuche es nochmal besser zu lernen.

Y-P: Koennte man statt einer Eventstruktur diese generel nicht erweitern? Ich sehe aber ein, daß ich mein Programm überarbeiten muss, weil es zu kompliziert wird, es vernünftig zu erweitern.

Danke schön und noch einen guten Abend.
Blue

Erweitern ist kein Problem, nur eine eigenständige, zweite Event-Struktur ist nicht ratsam. Da gibt's zig Probleme....

Gruß Markus

' schrieb:Y-P: Koennte man statt einer Eventstruktur diese generel nicht erweitern? Ich sehe aber ein, daß ich mein Programm überarbeiten muss, weil es zu kompliziert wird, es vernünftig zu erweitern.