Hallo liebes Labviewforum!
Ich würde Hilfestellung bei folgendem Problem benötigen:
Ich habe ein einfaches Programm mit 3 Buttons: Messung Start, Stop, Einstellungen
"Start" und "Einstellungen" Wertänderungen werden von einer Ereignisstruktur behandelt. Bei Druck auf Einstellungen erscheint ein Dialog (derzeit modal).
Das Problem ist nun folgendes: Beim drücken auf Messung start wird eine Whileschleife in der Ereignisstruktur gestartet, die kontinuierlich Messdaten aufzeichnet. Wenn ich nun Einstellungen ändern möchte, ist das erst möglich nachdem die Whileschleife mit dem Stop Button beendet wurde, also die ereignisstruktur verlassen wurde und die Wertänderung vom Einstellungsbutton aus der Queue abgearbeitet wird.
Ich habe schon an eine Ereignisstruktur in der Messwhileschleife gedacht, allerdings wird das dann stark unübersichtlich, außerdem müsste dann beim Beenden der Whileschleife die Wertänderung des Einstellungenklicks nicht bearbeitet werden, sonst würde ja nach Druck auf Stop direkt nocheinmal der Einstellungsdialog kommen.
Wie ist das am besten lösbar? Gleichzeitig sollte die Messung weiterlaufen, wenn der Dialog offen ist.
Besten Dank und schönes Wochenende,
tsa
Hallo tsa,
Zitat:Beim drücken auf Messung start wird eine Whileschleife in der Ereignisstruktur gestartet, die kontinuierlich Messdaten aufzeichnet.
Schlecht. Die Events in einer Eventstruktur sollten schnell (innerhalb von Millisekunden) abgearbeitet werden. Siehe Hilfe zur Eventstruktur!
Zitat:Wenn ich nun Einstellungen ändern möchte, ist das erst möglich nachdem die Whileschleife mit dem Stop Button beendet wurde, also die ereignisstruktur verlassen wurde und die Wertänderung vom Einstellungsbutton aus der Queue abgearbeitet wird.
THINK DATAFLOW! Das nächste Event kann erst abgearbeitet werden, nachdem der aktuelle Eventcase fertig ist…
Zitat:Ich habe schon an eine Ereignisstruktur in der Messwhileschleife gedacht
Das macht die Sache nicht besser: auch hier muss die Eventstruktur darauf warten, dass sie an die Reihe kommt…
Zitat:Wie ist das am besten lösbar?
Parallele Schleifen für UI-Handling und Messung!
Zitat:Gleichzeitig sollte die Messung weiterlaufen, wenn der Dialog offen ist.
Dann erst recht parallele Schleifen!
(27.02.2015 15:59 )GerdW schrieb: [ -> ]Zitat:Wie ist das am besten lösbar?
Parallele Schleifen für UI-Handling und Messung!
Zitat:Gleichzeitig sollte die Messung weiterlaufen, wenn der Dialog offen ist.
Dann erst recht parallele Schleifen!
Ich nehme einfach mal an, dass damit zwei parallele Whileschleifen gemeint sind! Die Sache ist die, dass in der Messschleife auch die Aktualisierung des Anzeigegraphen passiert, und der braucht die Informationen, welche im Dialog in der anderen Whileschleife gesetzt wurden. Die Frage ist nun, wie bring ich die Informationen in die andere Whileschleife rüber? Mir fallen jetzt auf die schnelle Variablen ein, welche jedoch von allen Labview benutzern die ich bis jetzt kennen lernen durfte absolut verteufelt werden, weil sie nicht dem Datenflussprinzip entsprechen.
Bezüglich seperate UI und Messbehandlung, ist damit gemeint, durch den Druck auf Messung start im Ereigniscase nur eine Art Flag zu setzen, welche dann die Messwhileschleife anwirft? Auch das wäre eine verletzung des Datenflussprinzips
Gruß tsa
Hallo tsa,
Zitat:Ich nehme einfach mal an, dass damit zwei parallele Whileschleifen gemeint sind!
Ja.
Zitat:Die Frage ist nun, wie bring ich die Informationen in die andere Whileschleife rüber?
Von mir aus auch lokale Variablen, aber schön ist das nicht. Und sobald du dein MainVI in zwei subVIs teilst, kannst du keine lokalen Variablen mehr nehmen…
Es gibt da:
- globale Variablen (nicht viel besser als lokale)
- Melder
- Queues
- FGVs aka ActionEngines
Zitat:Bezüglich seperate UI und Messbehandlung, ist damit gemeint, durch den Druck auf Messung start im Ereigniscase nur eine Art Flag zu setzen, welche dann die Messwhileschleife anwirft? Auch das wäre eine verletzung des Datenflussprinzips
Wieso sollte es den DATAFLOW beleidigen, wenn du für dein Flag einen Melder verwendest?
(27.02.2015 16:14 )GerdW schrieb: [ -> ]Wieso sollte es den DATAFLOW beleidigen, wenn du für dein Flag einen Melder verwendest?
Ich muss mir das mit dem Melder genauer anschauen, aber das klingt doch nach einer Variable, die z.B. von False auf True umgeschalten wird und damit zB ne Schleife anwirft
(27.02.2015 16:27 )tsa schrieb: [ -> ]Ich muss mir das mit dem Melder genauer anschauen, aber das klingt doch nach einer Variable, die z.B. von False auf True umgeschalten wird und damit zB ne Schleife anwirft
Kann man so sehen, bloß dass ein Notifier beim VI "Wait on Notification" das Warten auf ein Ereignis übernimmt. So müsste man selber dauernd pollen, um eine Wertänderung zu erkennen.
Gruß, Jens
P.S.: Vorlagen sind unter File->New...->From Template->Frameworks->Design Patterns zu finden, z.B. Master/Slave oder Producer/Consumer.
(27.02.2015 19:00 )jg schrieb: [ -> ]P.S.: Vorlagen sind unter File->New...->From Template->Frameworks->Design Patterns zu finden, z.B. Master/Slave oder Producer/Consumer.
Hallo Jens, Danke für den Hinweis mit den Vorlagen, ich habe das ganze jetzt mit Queues gelöst, offensichtlich kann die Queue Datenleitung Informationen in gerade laufende Whileschleifen "einschleusen" :-)
Anbei ein Screenshot des Schaltbilds, falls jemand ein ähnliches Problem hat.
Die untere Verbraucherschleife führt sozusagen eine Messung durch (erhöht Wert um 1), wenn der Button "Enqueue Element" gedrückt wird, öffnet sich ein Dialog wo eine Zahl ausgewählt werden kann (z.B. 1000)
Die Messung in der Verbraucherschleife läuft weiter, sobald der modale Dialog geschlossen wird, wird die ausgewählte Zahl zur Messung hinzuaddiert!
Viele Grüße,
tsa
Hallo tsa,
du kannst auf GetQueueStatus verzichten, wenn du den TimeOut des Dequeue auswerten würdest…
(03.03.2015 09:04 )GerdW schrieb: [ -> ]du kannst auf GetQueueStatus verzichten, wenn du den TimeOut des Dequeue auswerten würdest…
Hallo GerdW, vielen Dank für den Hinweis, habs im Schaltbild ausgebessert! :-)