Dynamisch Queues erstellen

Hallo liebe LFV Nutzer,

ich habe ein kleines Problem und hoffe, dass mit Queues lösen zu können. Und zwar habe ich eine Resource (Motor) die von verschiedenen VIs angesteuert werden können soll. Damit die aber nicht wild untereinander darauf zugreifen und die Motorsteuerung nachvollziehbar bleibt, wollte ich den in ein Programmpaket kapseln, dass auf meinem Rechner läuft und per Queue (oder auch TCP / IP - da das allerdings vermutlich nicht in ne exe umgewandelt wird reichen wohl Queues) von aussen angesteuert werden kann.

Um es mir zu ersparen den Anfrager jeweils mitzusenden und auszuwerten UND gleichzeitig die Kommunikation von verschiedenen Quellen sauber zu trennen, dachte ich daran, dynamisch Queues für die Kommunikation zur Verfügung zu stellen.

Heißt: Jeder Anfrager bekommt seine eigene Schnittstelle auf das Programm mit der er redet und das Programm "weis" wer anfragt bzw. wohin es antworten muss. (dazu sollen noch Sperrfunktionen kommen, damit die Zugreifenden die Motorsteuerung für sich reservieren können wenn nötig etc.; auch hier kann man dann schön in der entsprechenden Queue und NUR in der das entsperren anlegen.
Sprich: Theoretisch braucht jede Queue genau die gleiche Verarbeitung.

Das Grundgerüst wäre dann:
- eine Queue über die eine Verbindung angefordert werden kann - die erzeugt dann eine Neue Queue und gibt die Referenz darauf an den Anforderer zurück
- ein Modul, dass die Anfragen der verschiedenen Programme bearbeitet - die Bearbeitung bleibt dabei gleich, nur die Queue über die die Kommunikation erfolgt ändert sich (am besten vermutlich mit einer Queue eingehend und einer ausgehend für jedes Program
- eine Sperrinfrastuktur

Sequentiell wäre das natürlich kein Prob - Queues in ein Array packen und mit einer For Schleife (um die einzelnen Queues durchzuschalten) nacheinander auswerten (in der Schleife steht dann meine Auswerte- / Ausführungslogik). Allerdings hat das selbst mit Timeout das Prob, dass die Programme sich dann gegenseitig ausbremsen.

Entsprechend sollten die natürlich auch parrallel laufen. Nur wie ist das zu machen? Hat da jemand ne Idee?

Anzeige

Hallo Kiesch,

statt Queue-Referenzen herumzureichen, solltest du einfach mit den Queue-Namen arbeiten.
Wenn ein neuer "Anfrager" sich anmeldet, dann tut er das mit seinem Namen. Und ebendieser wird dann als Name für die Queue verwendet...

Würde ich ungern tun um zu vermeiden, dass sich jemand in die Queues einklinken kann - im schlimmsten Fall zufällig (Queue mit gleichem Namen erzeugt). Deswegen wollte ich eigentlich bewusst unbenannte Queues erzeugen. Ob ich dann nun die Referenz weiterreiche oder den Namen habe ist ja letztlich auch gehüpft wie gesprungen.

P.S: Ja ich weis, dass das mit den Namen Vorteile beim "abwickeln" der Queue hat, da man dann genausooft die Queue anfordert wie man sie irgendwo braucht und dementsprechend die Queue Referenz an mehreren Stellen schließen (und letzte Elemente entnehmen) kann.

Ein wenig , aber eines sollte dir klar sein: Auf eine bestimmte Queue kannst du nur innerhalb der selben Programm-Instanz zugreifen, also z.B. innerhalb der LabVIEW-Entwicklungsumgebung. Von einem anderen Rechner aus geht das gar nicht, und auch nicht von einer zweiten mglw. parallel laufender LabVIEW-Instanz.

Ich bin mit nicht einmal sicher, ob das es zwischen verschiedenen Projekten innerhalb der selben LabVIEW-Instanz möglich ist.

Die TCP-IP Idee würde ich somit nicht gleich komplett verwerfen.

Gruß, JEns

Eigene Ideen sind zwar gut, aber man sollte sich immer auch umschauen wie der Rest der Welt das bereits macht. Ich vermute, mit dieser Methode kann dein Problem auch gelöst werden:
   
In der Queue hat man einen Cluster, enthaltend die Daten als Variant für unterschiedliche Formate ( Text, numerisch, boolsch usw), sowie 2 weitere Elemente. Diese beschreiben, woher die Daten sind und wozu sie dienen.
Damit wäre es jedenfalls möglich, Daten aus ganz verschiedenen Quellen mit unterschiedlichen Datentypen zu senden. Der Empfänger ist immer voll informiert, woher die Daten kommen und was damit zu machen ist.

(12.06.2012 18:00 )jg schrieb:  Ein wenig , aber eines sollte dir klar sein: Auf eine bestimmte Queue kannst du nur innerhalb der selben Programm-Instanz zugreifen, also z.B. innerhalb der LabVIEW-Entwicklungsumgebung. Von einem anderen Rechner aus geht das gar nicht, und auch nicht von einer zweiten mglw. parallel laufender LabVIEW-Instanz.

Ich bin mit nicht einmal sicher, ob das es zwischen verschiedenen Projekten innerhalb der selben LabVIEW-Instanz möglich ist.

Die TCP-IP Idee würde ich somit nicht gleich komplett verwerfen.

Gruß, JEns

In der Entwicklungsumgebung hat das bisher immer geklappt mit Queues. Und ja, wenn das nicht geht muss ich auf TCP IP zurückgreifen. Dadurch ändert sich das Grundproblem allerdings nicht: Dynamisch eine erst zur Laufzeit bekannte Anzahl von (parrallelen) Verbindungen aufbauen. Ich baue mir sowieso grade ein Communication Device Object mit dem ich Queues und TCP IP (und mögliche weitere Protokolle) auf einer einzelnen Schnittstelle abwickeln kann. Die Änderung wäre dann damit nur noch ein anderes Initialisierungsobjekt (TCP IP statt Queue).

@Lucki

Wenns nicht anders geht wüsste ich natürlich das letztlich wie von dir gezeigt (oder ähnlich) abwickeln. Ich finds nur unschön mitschleifen zu müssen woher die msg kommt, deswegen würde ich das gerne weglassen. Außerdem habe ich auch dann das Problem, dass sich die verschiedenen die Verbindung nutzenden Programmteile gegenseitig blockieren können.

Bei so ner Lösung würden die einzelnen Programme dann vermutlich alle auf die gleiche Queue schreiben (die dann die Motorsteuerung verarbeitet) und über jeweils eine eigene Queue Antwort kriegen.

Bei der Architektur wäre das Problem allerdings auch, dass dann nicht die Architektur einfach auf TCP IP umzustellen ist (falls nötig), da ich da ja im Gegensatz zu ner Queue dann nicht von allen Sendern gemeinsam auf die gleiche Queue schreiben kann.

Danke aber für deine Mühe so spät nach Feierabend

Anzeige

(12.06.2012 18:00 )jg schrieb:  Ich bin mit nicht einmal sicher, ob das es zwischen verschiedenen Projekten innerhalb der selben LabVIEW-Instanz möglich ist.

Nein ist es nicht! Jedes Projekt stellt eine Applikationsinstanz dar und alle Synchonisationselemente (Queues, Notifiers, etc) sind nur innerhalb einer Applikationsinstanz gültig. Und wenn Du ein VI ohne Projectkontext ausführst wird das in der allgemeinen Applikationsinstanz ausgeführt, aber die teilt diese Objekte ebenfalls mit keiner anderen Applikationsinstanz.

Übrigens macht es nichts aus ob man diese Objekte mit oder ohne Namen öffnest, sie sind so oder so nur innerhalb der aktuellen Applikationsinstanz gültig. Austauch von Queue Refnums zwischen mehreren Applikationsinstanzen macht auch keinen Sinn, da die Refnums nur innerhalb der Applikationsinstanz Gültigkeit haben in der sie erstellt wurden. Für den der diese Dinge nachprüfen will gibt es ein Ding zum Aufpassen: Nicht in LabVIEW 8.0.x ausprobieren, denn da hatte LabVIEW einen Bug der diese Objekte Prozess global verwaltete, statt per Applikationsinstanz.

Hmm... das schmeckt mir eigentlich garnicht... Damit muss ich dann wohl fast alles über TCP IP abwickeln... Na ja anyway: Wäre hilfreich für mich, wenn wir zum Problem aus dem Eingangspost zurückkommen können

Dachte eigentlich für sowas gibt es eine "Standardlösung" die ich nur noch nicht gefunden habe...

(12.06.2012 20:38 )Kiesch schrieb:  @Lucki

Wenns nicht anders geht wüsste ich natürlich das letztlich wie von dir gezeigt (oder ähnlich) abwickeln. Ich finds nur unschön mitschleifen zu müssen woher die msg kommt, deswegen würde ich das gerne weglassen. Außerdem habe ich auch dann das Problem, dass sich die verschiedenen die Verbindung nutzenden Programmteile gegenseitig blockieren können.

Bei so ner Lösung würden die einzelnen Programme dann vermutlich alle auf die gleiche Queue schreiben (die dann die Motorsteuerung verarbeitet) und über jeweils eine eigene Queue Antwort kriegen.

Bei der Architektur wäre das Problem allerdings auch, dass dann nicht die Architektur einfach auf TCP IP umzustellen ist (falls nötig), da ich da ja im Gegensatz zu ner Queue dann nicht von allen Sendern gemeinsam auf die gleiche Queue schreiben kann.

Ich komme jetzt aus dem Urlaub zurück und schaue erst jetzt den Thread an.
Ist schon komisch: Das wird eine einfache Textinformation wie "Quelle1" in den Queuedaten rethorisch als "Mitschleppen" denunziert, als ob es sch um einen Megabyte großen Datenwust handelt, und folgerichtig nicht weiter in Betracht gezogen.
Die anderen Argumente dagegen halte ich auch nicht für relevant oder ich verstehe nicht was damit gemeint ist.
Und was nun die optimale Lösung? Keine Aussage, der Thread endet einfach so..

@Lucki

Ich find weniger die Info an sich problematisch (Größe), auch wenn vermutlich die "Herkunftsbezeichung" (Quelle 1, Quelle 2 etc.) in etwa so lang wäre wie die eigentlichen Nachrichten... Na ja.

Ich finde es eher "unhandlich".

Das fängt damit an, dass das System mit Bezeichnern nur über Queues funktioniert (da ich mit TCP IP das ich wohl nutzen muss siehe jgs post, nur von A nach B und zurück kommunizieren kann (also nicht von mehreren Stellen gemeinsam genutzt)).


Das geht weiter damit, dass ich im Program immer auswerten muss wer Quelle ist um richtig zu antworten (und nicht inhärent separate Kommunikationskanäle bereitstellen kann, über die dann "automatisch" an den richtigen Empfänger geantwortet werden kann).
Und es wird richtig nervig wenn mans zuende denkt und über EINE Queue antwortet (dann muss nämlich jede einzelne Quelle erstmal mit Vorschau kucken ob sie gemeint ist und wenn nicht muss nen wait reingenommen werden (was das ganze entweder langsam macht oder prozessorlast en masse frisst je nachdem wie das lang das wait ist).


Habe jetzt mal damit rumgespielt und mir ein ablaufinvariantes VI gezimmert, dass ich mehrfach Aufrufe und jeweils mehrfache Kommunikation zur Verfügung zu haben. Ist nur ein Beispiel (siehe Anhang), dass veranschaulicht, dass man beliebig viele erst zur Laufzeit in der Anzahl ekannte Parrallele Kommunikationskanäle erzeugt. Etwa so hatte ich mir das auch ursprünglich vorgestellt. Müsste ich dann noch entsprechend ausbauen, aber denke das Design sollte so auf beliebige Probleme übertragbar sein, bei denen Dynamisch Parrallelität erzeugt werden muss.

Zum Beispiel VI: Communicator.vi ist die aufrufende Instanz die die Kommunikationskanäle dynamisch erzeugt und fungiert gleichzeitig als Kommunikationstest. Man kann auf dem FP einstellen wie viele Queues man erzeugen lassen will und anschließend auswählen an welche Nummer (0 bis Anzahl -1) gesendet werden soll. Bei einer Sendung gibt das entsprechende "dynamic Queue Operation.vi" seinen Queue Namen " | " und die gesendete Nachricht zurück (als test das Richtig Empfangen wurde und das der Richtige Antwortet etc. ). Beide VIs müssen in einem Ordner sein dann sollte das ganze laufen wenn ich alles richtig gemacht habe.

Wäre für weitere Anregungen natürlich dankbar (und eventuelle Hinweise ob ich bei der Architektur noch was beachten muss).

P.S: Im Beispiel werden alle Queues bereits zum Start des Main VIs erzeugt, aber ich hoffe es ist klar, dass man natürlich auch zu beliebigen Zeiten weitere aufmachen kann; war nur so fürs Beispiel einfacher zu machen.