Datenkommunikation mittels QSM

Hallo liebe LVF-Gemeinde,

ich habe die Aufgabe eine LVSoftware für bis zu 6 verschiedene Messgeräte zu entwickeln.
Dabei bin ich sehr schnell auf eine QSM PC Architektur gestoßen.
Nun frage ich mich, wenn mein Main-Programm eine QSM PC ist, wie lege ich dann die einzelnen Messgeräte darin an?
Sollen es einfache State Machinen sein oder können es auch QSM sein, damit ich sie via Queued steuern kann?

Da ich leider noch etwas unerfahren bin in diesem speziellen LV-Bereich, würde ich mich über Support freuen.
Vielleicht hat ja schon mal wer verschiedene Geräte über verschiedene Schnittstellen in einem LV Programm angesteuert.

Bei Rückfragen gehe ich auch gerne weiter ins Detail

Gruß
Markus

Anzeige

Ueblicherweise hast du nur eine state machine und das ist deine GUI (Main). Die Instrumente werden ueber Sub-VIs initialisiert und angesprochen. Wenn du unbedingt eigenstaendige Instrumente willst, les dich in "GDS active objects" oder "Actor Framework" ein. Das scheint allerdings in deinem Fall overkill.

Wie legst du die Messgeraete an? Dafuer hat deine state machine einen "create hardware" state, dem du irgendwie sagst was anzulegen ist. Was dort genau passiert, haengt davon ab, wie du eine Instrumente implementierst.

Die "Messanwendung mit mehreren Instrumenten" ist das klassische Beispiel fuer eine Objektorientierte Architektur mit dem factory design pattern. Falls du Zeit hast und viel lernen willst, wuerde ich das auf jeden Fall empfehlen. Wenns schnell gehen muss, solltest du wahrscheinlich von jemand anderem Hilfe suchen Hast du mal in die sample projects reingeschaut, die mit LabVIEW kommen (create project)?

Hallo Teegee,

Als Main-Programm stelle ich mir eine QSM PC vor, damit ich die GUI und alle Messgeräte verwalten kann.
Die Ereignisse würde ich dann an Hand der GUI-Eingaben und Messwerte erzeugen lassen, welche dann eine ENUM-Constante generieren.
Diese wird im Messagehändler entsprechend verarbeitet.

Wenn ich jedes Messgerät jeweils als SubVI einfüge, dann lege ich auch eine eigene Schleife drum herum, welche Eventgesteuert ist oder?

Die Beispiele von LV habe ich unter "Create Project" zwar schon gefunden, konnte diese aber noch nicht ohne Weiteres auf meinen Fall umprogrammieren.

Es liegt noch ein gutes Stück Arbeit vor mir und ich bin deshalb um jede Hilfe dankbar.

Gruß
Markus

Ok, ich sehe 2 Loesungen fuer deine Messinstrumente
1) Ein VI pro Instrument.
Das muss dann eine action engine sein, die Aktionen wie "Init", "Config", "Measure" und "Close" bereit stellt und sich diverse Attribute und Eigenschaften merken kann. Dann kannst du in deiner consumer schleife "Measure" implementieren und ueber booleans entscheiden, welche Instrumente abgefragt werden. Alternativ kannst du in der comsumer schleife "MeasureInstrumentA", "MeasureInstrumentB", ... implementieren und die entsprechenden Aktionen in der GUI enqueuen. In jedem Fall musst du eine case structure oder aehnliches bereit stellen, die die Entscheidungen trifft. Das ist ok, wenn du 100% sicher bist, dass spaeter keine neuen Instrumente hinzugefuegt werden.

2) Eine Klasse pro Instrument, die alle von BaseInstrument abgeleitet sind.
In dem Fall werden eine "Init", "Config", "Measure" und "Close" states eigene Sub-VIs und die Attribute merkst du dir in dem cluster der Klasse. Mit dieser Loesung kannst du im consumer einen "Measure" state haben, der dank dynamic dispatch das richtige Instrument abfragt. Das ist flexibler und einfacher zu erweitern, aber etwas schwieriger zu verstehen, falls man unerfahren in Objektorientierter programmierung ist.

Und dann haben wir natuerlich noch die "active object" Loesung, von der du anscheinend nicht weg kommst. Wenn du unbedingt mit Events kommunizieren willst, musst du sicher stellen, dass all deine Instrumente auf Events lauschen. Dass geht nur, wenn sie alle gleichzeitig laufen. Das ist der grosse Unterschied zwischen "active object" und den oben erwaehnten Alternativen.
Loesung 1) ist relativ einfach von action engine in state machine verwandelt, in dem du einfach eine while schleife um deine case structure baust und einen "Idle" case einfuegst, in dem auf Events hoerst. Nach der Messung musst du dann die Messwerte per Event an die GUI zurueck schicken, um sie darzustellen. Das ersetzt dann schon fast die consumer schleife im Main und ist von der Idee sehr aehnlich zum Actor Framework.
Loesung 2) ist etwas komplizierter - vor allem, wenn du *nicht* das GDS benutzt. Drum werd ich da jetzt nicht genauer drauf eingehen.

Was du jetzt zuerst entscheiden musst ist: Wie kommunizierst du mit den Instrumenten?
- Events in beide Richtungen (Anfrage und Ergebnis)
- Sub-VI Aufrufe, die direkt das Ergebnis zurueckliefern

Hallo Teegee,

erstmal danke für die fixe Antwort!

Da ich aktuell weder Lösung 1 noch Lösung 2 für meinen Anwendungsfall beurteilen kann, erkläre ich dir lieber nochmal meine Problemstellung

Mein Ist-Stand sind ca. 5 verschiedene Messgeräte, die jeweils andere Messwerte aufnehmen und nicht vom gleichen Hersteller sind.
Aktuell gibt es die Möglichkeit die Geräte händisch über das jeweilige Bedienpanel zu betreiben und die Messwerte visuell zu erfassen.

Mein Soll-Stand:
Die Bedienung der Messgeräte via LabVIEW. Dabei sollen die Geräte jeweils initialisiert werden, Messwerte aufnehmen und speichern, Messungen starten und stoppen in Abhängigkeit von Bedinungen, ihre Verbindung zu Remote Control herstellen und beenden, etc.

Als Verbindungsart zwischen den Geräten ist hauptsächlich RS232 und einmal GBIP genutzt.

In Sachen Steuerung via LV, habe ich schon mit den Geräten einzelln kommuniziert und die jeweiligen Commands für die jeweiligen "Events" ausprobiert.
Jetzt heißt es jedoch daraus eine State machine zu machen, welche ich mittels Queuedmessages bedienen kann.
Das jedes Messgerät sein eigenes VI bekommt und im Main-VI über die GUI gesteuert wird, ist mein erster Lösungsansatz. Dabei muss jedoch die Parallelität berücksichtigt warden, weil auch manche Messwerte als "Eventauslöser" dienen sollen.
Macht das Stichwort "Observer" hier in meinem Fall sinn?

Gruß
Markus

Fangen wir mal von hinten an
- Ich nehme an, mit dem "Stichwort Observer" meinst du das observer design pattern? In dem Fall, nein, das macht eher wenig Sinn. In deinem Main VI kannst du jedes Instrument einzeln ansteuern und jedes Instrument schickt seine Messungen an das Main VI zurueck, wo sie (vermut ich mal) angezeigt werden. Dort kannst du dann auch relativ einfach eine Messung anhand des Resultats einer anderen Messung starten.
- Parallelität: Wenn du deine Messungen wirklich in parallel durchfuehren willst, musst du dich von der Idee einer einzigen consumer Schleife (QSM) verabschieden und jedem Instrument seine eigene consumer Schleife geben. Das waere dann die "active object" Variante von Option 1). In dem Fall kriegt jedes Instrument seine eigene event queue. Das Main VI verwaltet alle queues und sammelt Messungen via User Events.

Moin,

also Parallelität der Messgeräte ist sehr wichtig, da ich nicht sequenziell messen werde, sondern sich mehrere Werte gleichzeitig ändern und diese von mir (dem Programm) aufgenommen werden müssen.

Option 1 mit der Active Object Architektur klingt wohl nach der Lösung meines Problemchens.
Hättest du dazu zufällig ein paar weiterführende Links, damit ich mich in die Thematik einarbeiten kann?

QSM im Main, welche eine QSM für jedes Messgerät beinhaltet ist theoretisch möglich oder praktisch ganz anders umgesetzt?

Gruß
Markus

(07.04.2015 08:57 )MKay schrieb:  also Parallelität der Messgeräte ist sehr wichtig, da ich nicht sequenziell messen werde, sondern sich mehrere Werte gleichzeitig ändern und diese von mir (dem Programm) aufgenommen werden müssen.

Option 1 mit der Active Object Architektur klingt wohl nach der Lösung meines Problemchens.
Hättest du dazu zufällig ein paar weiterführende Links, damit ich mich in die Thematik einarbeiten kann?

Vielleicht überlegst Du Dir doch noch das Actor Framework als Lösungsansatz in Betracht zu ziehen. Es ist kein Overkill! Und es ist recht gut dokumentiert, https://decibel.ni.com/content/groups/ac...w=overview Es biete alles was Du benötigst, aktive Objekt mit wohl definierter Kommunikation.

Gruß Holger

Ich hab mal kurz was zusammen gehackt, was als Alternative zum Actor Framework dienen soll. Mit Hilfe des GDS toolkits ging das ganz flott.
Zwei "active object" instrumente und eine simple GUI, mit der du Messungen in parallel starten kannst und dann die Ergebnisse abfragen kannst.
Die Instrumente benachrichtigen die GUI nicht, wenn eine Messung fertig ist. Das ueberlass ich dir. Stichwort: Register User Events


  active object instruments.zip (Größe: 634,04 KB / Downloads: 298)