Parallele Queue Struktur

Hallo,

ich habe an meinen Rechner mehrere Messgeräte über Netzwerk angeschlossen. Die Kommunikation erfolgt dabei über TCP. Die Grundstruktur des Programmes ist eine einfache Producer-Consumer-Struktur, d.h. die Daten werden in der Producer Schleife ausgelesen und in der Consumer Schleife ausgewertet. Als Kommunikationselement zwischen den beiden Schleifen setze ich eine Queue ein. Da die Anzahl der Messgeräte auf bis zu 30 Stück ansteigen kann, stellt sich mir die Frage, wie ich das Auslesen der TCP Verbindung beschleunigen kann. Meine Idee dazu ist eine for-Schleife mit paralleler Ausführung (s. screenshot). Zu diesem Code-snippet habe ich nun folgende Fragen:

- Ist es möglich mehrere TCP Read Blöcke parallel auszuführen?
- Stellt Labview beim Anhängen der Daten an die Queue sicher, dass in diesem Moment keine weitere Instanz der for-Schleife Zugriff in die Queue hat oder können mir durch diesen Aufbau Daten verloren gehen?
- Oder gibt es eine elegantere Möglichkeit meine Problematik zu lösen? ;-)

Ich bedanke mich für eure Hilfe
Schöne Grüße

Anzeige

Hallo eurostar,

Dein Enqueue ist nicht der limitierende Faktor. Wer zuerst drankommt, darf zuerst Daten in die Queue schreiben. Daten gehen nicht verloren...

Es sollte möglich sein, die TCPReads parallel auszuführen, wobei die FOR-Loop hier auf den langsamsten Teilnehmer warten muss.

Hallo,

vielen Dank für die Antwort GerdW.

Dass die FOR-Loop auf den langsamsten Teilnehmer warten muss, ist hier nicht schlimm.
Der Zeitgewinn durch die parallele Abarbeitung wird weit aus größer sein, besonders wenn keine Daten vorliegen und der volle timeout abgewartet wird..

Grüße

Bei Queues kann man mehrere Sender haben, es gibt aber nur einen Empfänger. Wenn man unterschiedliche parallele For-Schleifen zum Senden hat, denn warten die doch nicht aufeinander, sondern jede steckt ihren Wert für sich in die Queue, unabhängig davon, in welchem Status sich die anderen Sender gerade befinden. Verstehe nicht, wieso das anders gesagt wurde, aber vielleicht ist es ein Missverständnis.
Da die einzelnen Raten unterschiedlich sein können, hat man in der Queue ein entsprechendes Durcheinander der Daten von den einzelnen Sendern.
Das Problem lässt sich so lösen: Die Queuelemente sollten Cluster sein. Element 1: Herkunft der Daten, Element 2: Datenelement selbst. Über eine Case-Struktur lassen sich dann die Daten beim Empfang nach ihrer Quelle sortieren.

Hallo Lucki,

Zitat:Wenn man unterschiedliche parallele For-Schleifen zum Senden hat, denn warten die doch nicht aufeinander, sondern jede steckt ihren Wert für sich in die Queue, unabhängig davon, in welchem Status sich die anderen Sender gerade befinden.

Ich habe nicht gesagt, dass die Enqueue-Funktionen aufeinander warten, sondern dass die FOR-Loop (insgesamt) auf das langsamste TCPRead warten muss (vorausgesetzt, alle Instanzen laufen parallel)!

Hi
Hast mal darüber nachgedacht, einen objektorientierten Ansatz zu wählen, z.B. das NI Actor Framework. Es wird seit LabVIEW 2012 voll integriert.

In Actor-Kindklasse(n) implementierst Du die Auslese des Geräts. Für jedes Gerät startetst Du einen Actor. Jeder Actor sendet die Daten zu einem Analyse-Aktor.

Vorteile:
- Die Klasse wird nur einmal programmiert und n-mal instantiiert. Änderungen müssen auch nur an einer Stelle gemacht werden.
- Alle Aktoren werden unabhängig von einander ausgeführt.
- Die Komminkation funktioniert mittel Messages via Queue.
- LabVIEW kümmerst sich selbstständig um die Verteilung auf verschiedenen Cores (falls vorhanden).
- Einfach Erweiterbarkeit.

Nachteile: Keine.

Gruß Holger

Anzeige

Hallo Holger,

Nachteil:
Alle anderen Teilnehmer im Thread verwenden nur LV2011...

Nachteil 2: ...und von denen, die LabVIEW 2012 verwenden, haben die meisten eine Abneigung gegen objektorientiertes Programmieren. Ich glaub' ich muss mir doch mal den Lehrgang bei NI reinziehen.

Gruß Markus

(28.01.2013 14:48 )GerdW schrieb:  Hallo Holger,

Nachteil:
Alle anderen Teilnehmer im Thread verwenden nur LV2011...

OK.
Die LV2011-Nutzer müssen das Actor-Framework separat herunterladen und installieren.
Geht aber auch.

Gruß Holger

Vielen Dank für eure Antworten!

@Lucki: Danke für den Tipp mit dem Cluster, so werd ich es machen.
@BNT: Das NI Actor Framework kenne ich noch garnicht, werde mir es aber diesbezüglich mal genau anschauen. Danke für den Tipp!

Grüße