' schrieb:Macht man alles in einer Schleife (in einem BD)
Wofuer steht bitte BD?
' schrieb:Dieses Vorgehen ist richtig.
Bei mir gibt es immer ein Haupt-VI mit Benutzeroberfläche. Dieses Haupt-VI hat eine Event-Struktur in einer While-Schleife. Hier werden lediglich Events (also einmalige Ereignisse) abgearbeitet, wie z.B. Buttonclicks. Neben dieser While-Schleife kann eine zweite While-Schleife mit einer Statemachine stehen. Diese Statemachine kann genau den automatischen Ablauf enthalten, den du haben willst. Diese zweite While-Schleife befindet sich deswegen in diesem Haupt-VI, weil Anzeigeelemente beschrieben werden sollen. Diese Statemachine kommuniziert mit dem Modul über Queues und Melder. Wäre keine Anzeige notwendig, würde man diese Statemachine auch in ein SubVI (also ein eigenständiges Modul) auslagern oder gar in das Endgeräte-Modul integrieren.
Die Gerätesteuerung selbst (also das ganz oben erwähnte Modul) liegt mit Queue/Melder/Ereignis-Referenzen am Eingang auf dem BD des MainVI. Dieses Modul läuft im Hintergrund parallel zum Haupt-VI.
Moment, das ist jetzt verwirrend. Das Haupt.vi besteht aus einem Producer-Consumer-Pattern. Im Producer sind bei Dir die Eventbuttons? Consumer-Schleife kann als Sub.Vi ausgelagert werden, wenn man moechte?
Was genau ist jetzt fuer dich ein Modul und was bedeutet bitte"liegt am Eingang auf dem BD des Main.vi"?
Generell ist mir nicht klar, wie ich die dauerhafte Ueberwachung meines Geraetes programmieren soll, ohne das Gerät für die Eventstruktur ("Buttonklicks" zu blockieren") Im Beispiel unten habe ich testweise eine weitere Schleife gebaut, in der ein wait sitzt. Es scheint zu klappen, aber ich weiss nicht, ob die Umsetzung richtig ist.
' schrieb:Ich hab mal ein kleines Muster angehängt. Die untere While-Schleife ist das Endgeräte-Modul und sollte in einem SubVI ausgelagert werden. Benutzerereignisse sind in dieser Ausbaustufe noch nicht erforderlich.
Der Consumer-Loop entspricht also in diesem Beispiel dem Endgeraet-Modul?
' schrieb:Was für mich "einfach" ist - modulare, also gekapselte, klassenorientierte SubVI-Programmierung mit Queues/Melder und FGVs - erscheint dem einen oder anderen doch recht verwirrend.
Haettest Du vielleicht ein Beispiel fuer ein FGVs, dass in einem "komplexeren" Programm eingebettet ist? Es heisst zwar immer, in FGVs kann man Daten speichern, nur weiss ich nicht, wie man an einem im Diagramm weiteren Ort, z.b. in einer anderen parallelen Schleife darauf zugreift.
Zu deinem Beispielprogramm einige Fragen:
1. Warum hast Du Dich fuer eine Sequenz entschieden?
2. Warum hast Du darauf verzichtet, ein Event dynamisch zu registrieren? Das war ja mein ursprünglicher Ansatz.
3. Warum sind in der zweiten while-Schleife im Producer-Loop waits eingebaut?
Ich habe dein Beispiel uebernommen und die Befehle fuer meine Pumpe eingebaut. Sie wechselt tatsaechlich automatisch die Richtung ohne merklich am Umkehrpunkt zu stoppen. Das ist wirklich ein guter Fortschritt.
Die naechste Herausforderung war nun, dem Geraet mitzuteilen, WANN die Richtungsumkehr erfolgen soll. Dafuer gibt es i.a. zwei Ansaetze:
1. Ueber die verstrichene Zeit. Das habe ich wieder ueber einen Timeout mit einer Eventstruktur realisiert. Das LabView-Style-Book empfiehlt ein solches Vorgehen jedoch nicht. Ich weiss nur nicht, wie man ansonsten die verstrichene Zeit in einer while-Schleife registrieren kann. Ich habe versucht, es mit der Tick Count.vi zu realsieren, aber das ging scheif.
Generell wechselt die Pumpe nach der angegebenen Zeit fuer den Timeout (10s) auch die Richtung, ohne am Umkehrpunkt lange zu stoppen. Ich nenne das mal glattes Umkehren. b] Problem hierbei[/b]: Sobald man der Pumpe den Befehl zu Umkehr schickt, kehrt sie auch sofort um. D.h., wenn die Pumpe 50ml injizieren soll und der Umkehrbefehl kommt nach 10s (Rate: 5ml/s), dann meldet das Pumpendisplay das z.b. erst 48.9ml als injiziertes Volumen. Ich habe den Verdacht, dass der Motor dann Schritte vergisst. Obwohl die Zeit eigentlich stimmt, braucht die Pumpe einen Tacken laenger als 10s. Diese Zeit kenne ich aber nicht.
Wie kann man eine Umkehr sicherstellen, die exakt nach 50ml injiziertem Volumen stattfindet, und der Umkehrprozess ohne Pause von statten geht?
(Beispiel 1 angehaengt. Ich bitte um Entschuldigung ob der beiden Eventstrukturen im selben vi. Dient nur der Veranschaulichung wegen.)
Ich habe das auch mit einem Timed Loop probiert (statt Timeout Eventstruktur). Es tritt das gleiche Problem auf. Die Pumpe wechselt "glatt" ihre RIchtung, aber das Volumen stimmt nicht. Pumpe zeigt z.b. 48ml oder dann mal nur 46ml an.
Beispiel_1.zip (Größe: 66,61 KB / Downloads: 270)
2.Mein zweiter Versuch bestand darin, die Pumpe ständig nach ihrem Status in einer dritten, parallel laufenden Schleife zu fragen. Immer wenn sie meldet "Target reached", sollte dynamisch ein User-Event ausgelöst werden, das sich um die Richtungsänderung kümmert. Geklappt hat es. Jedoch wartet die Pumpe immer einen Moment (im Sekundenbereich), wenn "Target reached" gemeldet wird und bis das User-Event zur Richtungsumkehr ausgeloest wird. Damit stelle ich zwar sicher, dass die Umkehrung nach 50ml passiert, jedoch dauert der Umkehrprozess viel zu lange. Mein Betreuer moechte die Zeit, in der der Motor umkehrt, möglichst auf null reduzieren.
Dass das möglich ist, zeigt eine eingebaute Methode auf der Pumpe. Gefragtes Volumen wird injiziert und Richtungsumkehr erfolgt ohne merklichen Stop, also richtig glatt (im Prinzip wie eine Sinuskurve). Ich verstehe einfach nicht, wieso ich das nicht in LabView umsetzen kann.
Beispiel_2.zip (Größe: 71,73 KB / Downloads: 232)
Danke schoen fuers Lesen.
Gruss
Blue
