+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: Datenkommunikation (/Forum-Datenkommunikation)
+---- Thema: VISA Kommunikation mit queues (/Thread-VISA-Kommunikation-mit-queues)
VISA Kommunikation mit queues - onsight8c - 10.03.2011 13:39
Hallo zusammen
Ich sitze momentan an folgendem Projekt:
Über eine RS485/VISA Kommunikation werden verschiedene Messgeräte und Ventile angesteuert. Mittels an das jeweilige Gerät gesendete Befehle werden verschiedene Eigenschaften eingestellt oder abgefragt, als Beispiel Gerät mit der Adresse xyz:
Auslesen: @xyzST?;FF Gerät xyz wird mittels "ST?" nach Status gefragt, ;FF ist das Stopzeichen
Beschreiben: @xyzUT!#;FF Gerät xyz wird mittels "UT!" mit dem Usertag # beschrieben, dieser kann alles mögliche sein ("#"= ......)
Bedeutet bspw für die Messgeräte, wenn ich Daten auslesen will, muss ich kontinuierlich den Auslesebefehl senden - kein Befehl, Gerät tut nix und schweigt. Bei den Ventilen ist es ähnlich - Befehl auf/zu und kurze Rückmeldung über den aktuellen Status.
Folgende Funktionalitäten soll das Steuerprogramm nun haben:
- GUI mit Anzeigen und Steuerelementen (Schalter, Buttons, etc)
- Auslesen und Anzeige der Messgerät-Daten
- Ansteuern (auf/zu) der Ventile mittels Schalter, Buttons..
- Auslesen des Ventilstatus (alle paar Sekunden bis Minuten)
- Abfrage weiterer Daten von zukünftigen Geräten (also modularer Aufbau)
Dachte zuerst an ein Procuder/Consumer-Design wie in diesem Falle: Beitrag #8 Allerdings macht mir die ständige Befehle-Senderei Bauchschmerzen.
Habt ihr nen Tip für mich, wie ich das Programm von der Struktur her aufbauen könnte? Ggf über verschiedene States wie beim angehängten VI?
Danke euch schonmal sehr!
Grüße,
Boris
*************
Habe die Datei nochmal für Version 8.2 gespeichert!!!!
RE: VISA Kommunikation mit queues - toaran_ - 11.03.2011 09:21
Hi
also ein Producer Consumer Design ist auf jeden fall passend ... Zum anfangen würde ich das Producer/Consumer Design(Events) Template von Labview nehmen ... dazu gibts auch Beispiele...
in der Eventstruktur behandelst du alle Buttons und in der Consumer Schliefe das senden der jeweiligen Befehle...
Das alle paar Sekunden bis Minuten Ventilstatus abfragen kannst du mit einem User Event (siehe Beispiele dazu in LV) realisieren.
T
RE: VISA Kommunikation mit queues - onsight8c - 11.03.2011 10:31
Moin toaran!
Danke für deine Rückmeldung! Dann bin ich schonmal nicht komplett auf dem Holzweg.
Ich versuche jetzt die Geschichte so aufzuziehen:
- Producer-Loop liest mir die Daten aus der VISA aus
- Packt diese auf ne Queue
- Consumer Loop arbeitet mit verschiedenen States:
0. Abholen eines Datenelements aus der Queue
1. Analyse + Verarbeitung der Daten
2. Weitergabe und Darstellen der verarbeiteten Daten auf der GUI
3. Daten loggen
4. ggf. weiter Spielereien
5. Stop-State für einige ms um danach nächstes Datenelement aus Queue abzurufen und wieder mit state (1) zu beginnen
Kann ich dann dort trotzdem noch Event-Cases einbauen, bpsw. wenn ein Schalter betätigt wird, um ein Ventil zu fahren? Und dass nach Abschluss der Interaktion wieder nur die Daten ausgelesen werden?
Oder muss ich den Weg gehen, dass ich über ne Case-Struktur in der Producer-Loop anwähle ob Daten gelesen oder Befehle gesendet werden?
greetz
Boris
RE: VISA Kommunikation mit queues - IchSelbst - 12.03.2011 10:48
(11.03.2011 10:31 )onsight8c schrieb: - Producer-Loop liest mir die Daten aus der VISA ausProzesse, also Module, durch Queues zu entkoppeln, ist immer ein richtiger Weg.
- Packt diese auf ne Queue
- Consumer Loop arbeitet mit verschiedenen States:
In deinem Falle würde ich in den (ersten) Producer-Prozess bereits folgendes einbinden: Hier kann man möglicherweise eine Vorfilterung der Daten machen, insofern, dass ein Queue-Element ein sinnvoll zu bearbeitendes Datenpaket darstellt. Ein Zwischenschritt (also ein Zwischenmodul), das den VISA-Stream in sinnvoll zu bearbeitende Datenpakete umwandelt, würde ich im ersten Ansatz nicht vorsehen.
Zwischen den Zeilen kannst du lesen, dass es ohne weiteres sinnvoll sein kann, wenn sich ein Verarbeitungsweg über mehrere Queues erstreckt.
Zitat:Kann ich dann dort trotzdem noch Event-Cases einbauen, bpsw. wenn ein Schalter betätigt wird, um ein Ventil zu fahren? Und dass nach Abschluss der Interaktion wieder nur die Daten ausgelesen werden?Gehen tut alles (nur die Frösch' hüpfen).
Man kann einen Ablauf (siehe deine Beschreibung) als Case-Struktur (also Schrittkette) in einer While-Schleife programmieren. Jeder einzelne Schritt sollte dann nur ganz kurz dauern. Nach der Case-Struktur (in der While-Schleife) kann man die Event-Struktur sequenziert einbauen und mit einem Timeout von (z.B. 5ms) laufen lassen. Wenn ein Event eintritt, kann man den synchron in die Case-Sequenz einführen.
Nichtsdestoweniger kann man natürlich auch eine eigenständige Event-Struktur nehmen und per Lokaler Variablen oder auch per Queue Daten an die Case-Struktur senden.
Zitat:Oder muss ich den Weg gehen, dass ich über ne Case-Struktur in der Producer-Loop anwähle ob Daten gelesen oder Befehle gesendet werden?Das hängt von der Applikation und dem Aufbau des Programmes ab.
Ich mach's immer so (und das ist unabhängig von der Schnittstelle, also ob VISA oder DaqMX etc):
Es gibt ein Modul, das die komplette Schnittstelle bedient. Dieses Modul läuft kontinuierlich, ist also nicht in einen expliziten Datenfluss eingebunden. Gesteuert wird dieses Modul über eine Queue. Daten nach außen geben kann dieses Modul über Queues, Melder oder auch FGVs.
Über die Steuer-Queue kann man dem Modul mitteilen, was es jetzt machen soll: VISA initialisieren, Daten lesen, Daten schreiben, et. etc. Beachte, dass das Modul selbstsicher ist, und genau weis, was es gerade tut und was es daher gerade nicht tun kann: Liegt gerade ein laufender Lese-Zyklus an, muss ein Daten-Schreiben natürlich noch warten - das heißt aber nicht, dass der Befehl hierfür nicht angenommen wird.