Ist das so okay realisiert?

' schrieb:Hallo Blue,

sieht doch schon ganz ordentlich aus...

Danke schoen! Interessanterweise funktioniert diese Art der Programierung viel besser als mein erster, murksiger Versuch, wo Producersachen+Consumersachen in einer gemeinsamen Schleife drin waren.

' schrieb:Du kannst mehrere Events in einem Eventcase abarbeiten lassen. Die Events werden dann ODER-verknüpft, jedes einzelne der Events löst diesen Eventcase aus.

Danke fuer die Erklaerung. Ich habe noch eine Frage zur Anzahl an Eventstrukturen. Wieviele sind pro .vi erlaubt? Soweit ich weiss, eine. Aber darf man dann noch in Sub.vis jeweils eine weitere Eventstruktur haben?
Hintergrund: Im Moment kann der User, wenn er will, ganz schnell die Buttons Infuse druecken und danach auch wieder Withdraw. Das "Button drucken" loest die Eventcases aus. Lustigerweise, kehrt die Pumpe die Richtung dann um, ohne kurz zu stoppen. Kann man sozusagen dieses Producer-Consumer-Pattern auch in eine Sub.vi packen und das die Events werden automatisch getriggert, z.b. alle 10s?

' schrieb:Noch ein Tipp:
Ich würde noch ein QUIT-Kommando ins Enum nehmen, um den Consumer kontrolliert (d.h. programmatisch) runterfahren zu können.

Was ist der Vorteil bitte? Bedeutet das Runterfahren des Cconsumers gleich einen Stopp des gesamten LabView-Programms oder stoppt as Geraet und wartet ggf. auf neue Befehle?
Ich hatte ueber sowas aehnliches am We schon ueberlegt. Ich dachte da an einen "globalen" Stop-Button, der das komplette LabView-Programm kontrolliert stop. Meinst du das vielleicht bitte?

' schrieb:Dann könnte man sich auch überlegen, ob man die Queue mit einem TimeOut ausliest und den Stop der Whileloop an den QUIT-Befehl koppelt... Nur so 'ne Idee.

Das verstehe ich absolut nicht. Was macht das? Danke fuer deine Vorschlaege!

Einen schoenen Abend.
Gruese
Blue