Bidirektionaler Datenaustausch zwischen parallelen Schleifen / subVi

Hallo Leute,

vielleicht habe ich nur das richtige Stichwort noch nicht gefunden, aber ich habe bis jetzt trotz langer Suche keine schöne Lösung für mein Problem gefunden:

sagen wir ich möchte im Kern zwei parallele schleifen:

Die erste stellt eine Position (Zahl) ein und wartet darauf, das diese Position erreicht ist, bevor sie einen Messwert verarbeitet.

Die zweite sendet den Positionierbefehl an einen Schrittmotorcontroller und das OK zurück an die erste Schleife.

Wie mache ich das ordentlich (ohne z.B. eine Statusvariable zu pollen)?

Die Producer-Consumer Architektur sieht keine Rückmeldungen vor. Queues scheinen mir auch nicht dafür ausgelegt. Am liebsten wäre mir so etwas wie eine Ereignisstruktur, die auf die Änderung einer Statusvariablen reagiert. Da die besagten schleifen aber innerhalb eines großen VIs mit Ereignisstruktur und State-Machine sind führt das hinzufügen weiterer Ereignisstrukturen in meinem Hauptprogramm immer zum einfrieren des FP. (Das problem ist leider nur im Hauptprogramm, ein einfaches Bespiel-VI, das ich machen wollte, zeigt diesen fehler leider nicht).

Ich hoffe jemand hat meine Frage verstanden, vielen Dank für Tipps.

Anzeige

Das geht mit Queues, Notifiers oder User Events. Ich bevorzuge Queues in solchen Fällen (beim Notifier kann die Bestätigung verloren gehen, dann wartet man vergeblich drauf).

Gruß, eg

Du kannst ja auch zwei Queues verwenden. Eine zum Reinschreiben und eine zum Auslesen.

Gruß Markus

' schrieb:Du kannst ja auch zwei Queues verwenden. Eine zum Reinschreiben und eine zum Auslesen.

So würde ich es auch machen. Man muß sich dann aber überlegen, wie man die beiden Schleifen miteiander synchronisiert. Bei der klassichen Erzeuger-Verbraucher-Strukur ist es in der Regel so, daß beim Verbraucher auf das Eintreffen neuer Daten gewartet wird. Dadurch synchronisiert sich die Verbraucherschlaife mit der Erzeugerschleife.
Bei Datenaustausch in beiden Richtungung hat man das Problem: Wer synchronisiert wen? Eine (von mehreren) Möglichketen wäre, daß gar nicht synchronisiert wird, jede Schleife hat hat ihren eigenen Takt. Das Timout für den Datenenempfang aus den Queues wird auf Null vorgegeben. Die Timeoutfehler werden auf beiden Seiten aufgefangen.

Das Gegenargument ist dann aber: Die Synchronisation ist gerade der Vorteil von Queues. Wenn man keine Synchronisation braucht, dann kommt man man mit lokalen Variablen zum bidirektionalen Datenaustausch billiger.

Wenn eine Schleife die andere synchonisieren soll, dann ist vielleicht am besten, 1 Queue zu verwenden und für den Rückkanal lokale Variable. Beispielweise wäre es denkbar, daß für die OK-Meldung eine lokale Variable reicht.

Meine Gedanken sind etwas ungeordnet, aber vielleicht regt es die Diskussion an. (Und konkretere Vorschläge mit VI sind in er Regel nur bei Fragen mit angehängtem VI möglich)

Ich habe mal ein Beispiel gebastelt, mit zwei schleifen und einem Melder. Die Variante mit der Lokalen Variable wird später nicht funktionieren, da jede schleife ein SubVi werden soll, um das Programm möglichst modular zu halten ausßedem müsste man die dann entweder pollen oder eine ereignisstruktur einführen(?).

So wie es aussieht funktioniert das so (noch)... bin für jede Anregung dakbar, ob das auch solide funktioniert...

  2schleifen_1MelderLV_8.0.zip (Größe: 13,47 KB / Downloads: 379)

' schrieb:Die Variante mit der Lokalen Variable wird später nicht funktionieren, da jede schleife ein SubVi werden soll, um das Programm möglichst modular zu halten

Genau, so ist das Vorgehen richtig.

Zitat:ausßedem müsste man die dann entweder pollen oder eine ereignisstruktur einführen(?).

Beides würde gehen.

Zitat:So wie es aussieht funktioniert das so (noch)... bin für jede Anregung dakbar, ob das auch solide funktioniert...

Solide wird es nicht funktionieren. Früher oder später wird dieses Verfahren mit Meldern zu so nicht lösbaren Problemen führen.

Nimm statt einem Melder lieber zwei Queues.

Anzeige

' schrieb:sagen wir ich möchte im Kern zwei parallele schleifen:
Die erste stellt eine Position (Zahl) ein und wartet darauf, das diese Position erreicht ist, bevor sie einen Messwert verarbeitet.
Die zweite sendet den Positionierbefehl an einen Schrittmotorcontroller und das OK zurück an die erste Schleife.

Ist schon schon ein Weile her, daß ich auch mit Motorsteuerungen etwas postioniert habe habe, uind habe mal nachgechaut, wie ich es gemacht hatte.
Hier ein Beispiel:

   

Die Grau-Gelben SubVIs gehören zu einer LabVIEW-Bibliothekt der Fima ISEL, sie gehört zu einer Motorsteuerung "LS146". Mit dem ersten Sub-VI wird die neue Position an die Steuerung übergeben, mit dem zweiten wird der Status so lange gepollt, bis die Position erreicht ist. Also alles ist ganz simpel.
Ich weiß ja nicht, ob Du zu Deinem Motor eine komfotable Steuerelektronik hast, womöglich noch mit solchen LabVIEW- Treibern. Das würde die Sache natürlich enorm erleichtern. Aber auf jeden Fall würde ich vorschlagen daß Du Dir einen Satz so ähnlicher SubVIs erstellst. Damit kannst Du dann dein Problem lösen, ohne Dich hier in der Problematik des bidirektionelen Datenaustzauschen von 2 Schleifen zu verfangen.
Habe solche Bibliotheken für 2 verschiedene Motorsteuerungen da, wenn es Dir nützt kannst Du sie haben.

Ja, ich habe bei bedarf auch die Isel-LV Treiber, das ist glaubce ich nicht das Problem, die wesentlichen Funtionen mit Position Senden -> Auf Position warten habe ich. Mein Problem ist, das die neuen Positionsdaten in einer anderen schleife generiert werden sollen, die z.B. eine automatische nachregelung auf das Signalmaximum eines angeschlossenen Spektrometers durchführt. Diese muss aber warten, bis die Position erreicht ist. Sinn dieses Konstrukts soll sein, dass die Motorsteuerung leicht durch eine andere ersetzen werden kann, ohne tief in mehreren SubVi diese funktion tauschen zu müssen. (die routiene die die positionen generiert muss auch austauschbar sein, wenn ich alles nur einmal bräuchte würde ich nicht versuchen mir die mühe zu machen...)

Eine Frage zu Queues/Melder: Eigentlich soll es bei meinem Programm niemals vorkommen, dass sich Meldungen aufstauen, da keine seite ohne Meldung der anderen weitermachen darf, wären dann nicht zwei melder sinnvoller als queues?

' schrieb:Eine Frage zu Queues/Melder: Eigentlich soll es bei meinem Programm niemals vorkommen, dass sich Meldungen aufstauen, da keine seite ohne Meldung der anderen weitermachen darf, wären dann nicht zwei melder sinnvoller als queues?

Ich würde keine Melder verwenden.

Du willst doch bestimmt "eventgesteuert" arbeiten. Also sobald der "Trigger" vorhanden ist, soll was gemacht werden. Hierfür ist aber eine Queue das logischerere Mittel. Die Queue wird nämlich ausgelesen und dann ist das entsprechende Datum verschwunden aus der Queue. Um dieses Verhalten bei Meldern zu realisieren musst du zum Zeitpunkt des Aufrufens des MelderAbfragens sagen, dass die Historie ignoriert werden soll. Das Datum im Melder wird nämlich bei Auslesen nicht automatisch gelöscht. Und genau hier kommt es dann zu RaceConditions (also zu Problemen synchron-spezifischer Art) auf Melderebene.

Wenn es um Ablaufsteuerung geht, verwende ich immer eine Queue. Die zu steuernde Seite muss die Queue auslesen. Wenn es darum geht, einen Zustand allgemein bekannt zu geben, dann nehme ich Melder. Wer die Daten braucht soll sie auslesen.

' schrieb:Mein Problem ist, das die neuen Positionsdaten in einer anderen schleife generiert werden sollen, die z.B. eine automatische nachregelung auf das Signalmaximum eines angeschlossenen Spektrometers durchführt. Diese muss aber warten, bis die Position erreicht ist.

So hatte ich es auch verstanden, und die einfache Löung ist doch: Für die Abfrage des Bewegungsstatus erstellt man ein SubVI, dieses wird nach der Übergabe der neuen Positionsdaten an der gleichen Stelle im Programm so lange in einer kleinen Schleife gepollt, bis sich sich der Motor nicht mehr bewegt. Mein Verständnis für das Aufbauschen dieses kleinen Problemchesn mittels paralleler Schleifen, Meldern, Queues hält sich in Grenzen.