+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+--- Thema: Was waere hier am besten? (/Thread-Was-waere-hier-am-besten)
Was waere hier am besten? - bluesaturn - 14.06.2011 18:10
Hallo Labviewforum.
Ich habe hier eine VI und habe lauter Knoten im Gehirn.
Die VI hoert auf eine UDP-Connection und bekommt verschiedene strings ab. Im Moment sind es zwei (pumpslow, pumpstop) , aber wollen es gerne erweitern.
Die Strings sollen in spaeter in eine Art Buttonaktion ueberfuerht werden, der praktisch solange gedrueckt bleibt, bis ein anderer Befehl kommt.
Oder anders ausgedrueckt: Wurde einmal pumpslow gesendet, soll meine Pumpe solange weiterpumpen, bis der naechste Befehl ueber die UDP-Verbindung kommt.
Ist das eine Standard - State - Machine? Koennte mir jemand vielleicht bitte ein Beispiel mit einer State Machine geben, angelehnt an die unter .vi, die unsere ersten dummen Versuche zeigt?
Ich weiss nicht einmal, wie ich diese State-Machine initialisiere mit der UDP-Connection?
RE: Was waere hier am besten? - GerdW - 14.06.2011 18:38
Hallo blue,
eine einfache Statemachine wird aus eurem VI, wenn ihr die Befehle in einem Schieberegister speichert - so wie im angefügten Beispiel...
Eine bessere Statemachine wird draus, wenn man den Befehlsempfang (und seine Quittierung) in eine extra Schleife auslagert und die Befehl programmintern per Queue oder Melder an den Consumer weitergibt - also das Statemachine-Konzept mit dem Producer-Consumer-Konzept verbindet. Für beide Konzepte gibt es Beispiele (und VIs im "More..."-Dialog unter "Frameworks"->"Design Concepts")!
RE: Was waere hier am besten? - bluesaturn - 14.06.2011 19:17
(14.06.2011 18:38 )GerdW schrieb: Hallo blue,
eine einfache Statemachine wird aus eurem VI, wenn ihr die Befehle in einem Schieberegister speichert - so wie im angefügten Beispiel...
Eine bessere Statemachine wird draus, wenn man den Befehlsempfang (und seine Quittierung) in eine extra Schleife auslagert und die Befehl programmintern per Queue oder Melder an den Consumer weitergibt - also das Statemachine-Konzept mit dem Producer-Consumer-Konzept verbindet. Für beide Konzepte gibt es Beispiele (und VIs im "More..."-Dialog unter "Frameworks"->"Design Concepts")!
Hallo GerdW.
Danke fuer deine Antwort! Ich glaube, ich bekomme den zweiten Vorschlag nicht on the fly hin. Dafuer bin ich zu schlecht in LabView. Ich habe schon mal Master Slave Pattern versucht zu programmieren, aber das hat gedauert. Gerade bin ich extrem unter Zeitdruck.
Koenntest du mir vielleicht bitte noch ein Beispiel geben, wo mehrere Strings als Befehle in die Statemachine eingehen bitte?
Wie kann man es bitte hinbekommen,dass ein Event solange ausgefuehrt wird, bis der naechste String via UDP ankommt?
In einem Ansatz habe ich mir gerade eine Eventstruktur mit einem Button gebastelt und wenn der Value dieses Buttons sich aendert soll das Event ausgefuehrt werden. Das klappt. Wie aber kann man den Button (z.B. INfuse AUto) durch den Befehl steuern oder ersetzen, den ich ueber die UDP -Verbindung bekomme? (Siehe Bild)
Danke schoen. Ich weiss, dass ich mich bessern muss mit Labview.
Vielel Gruesse
Blue
RE: Was waere hier am besten? - GerdW - 14.06.2011 21:48
Hallo blue,
Zitat:Wie kann man es bitte hinbekommen,dass ein Event solange ausgefuehrt wird, bis der naechste String via UDP ankommt?Habe ich doch im VI schon gezeigt: der String ändert sich nur, wenn ein neuer per UDP empfangen wird...
Zitat:ein Beispiel geben, wo mehrere Strings als Befehle in die Statemachine eingehen bitte?Einfach mehrere Befehle nacheinander per UDP versenden...
Zitat:eine Eventstruktur mit einem Button gebasteltSo sieht das aus. Empfohlen wird übrigens nur eine Eventstruktur pro VI...
Zitat:Wie aber kann man den Button (z.B. INfuse AUto) durch den Befehl steuern oder ersetzenIndem man die Statemachine wie gezeigt über das Schieberegister ansteuert. Es ist doch egal, wo der String eingelesen wird (UDP, in einem Event, ...)!
Zitat:Gerade bin ich extrem unter Zeitdruck.Das tut mir leid für dich. Vielleicht bessere Zeitplanung üben?