+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: Datenkommunikation (/Forum-Datenkommunikation)
+---- Thema: Resourcen schonende Kommunikation (/Thread-Resourcen-schonende-Kommunikation)
RE: Resourcen schonende Kommunikation - LV-New - 08.04.2020 12:22
Ich glaube die Queues erschlagen mich noch... zumindest bei der Menge die es dann werden.
Aber klar, es sind zuviele Parameter die ich beachten muss bei meiner Idee.
RE: Resourcen schonende Kommunikation - GerdW - 08.04.2020 12:32
Hallo LV-New,
man kann Queues auch mit Namen anlegen.
Und wenn man weiß, z.B. per ConfigFile oder typdefiniertem Enum, welche Consumer zu erwarten sind, kann man für jeden Consumer eine Queue anlegen.
Jeder Consumer kennt seinen eigenen Namen und kann so auch seine Queue lesen.
Und um zu verhindern, dass die Queues den Speicher vollmüllen, kann man sie beim Erstellen auch gleich auf eine sinnvolle Länge begrenzen. (Man verwendet dann ein LossyEnqueue…)
Alles zusammen:
Man legt eine überschaubare Anzahl von benannten Queues an, die man natürlich zum Ende des Programms auch alle wieder löscht. Und jeder Consumer liest aus seiner längenbeschränkten Queue.
Klappt für "normale" Datenübertragung (d.h. keine Anforderungen an große Datenpuffer und sehr hohe Datenraten) sehr gut! Ich nutze das, um in einer Prüfstandssoftware mit einer unbekannten (aber über ein Enum definierten maximalen) Anzahl anzusteuernder Geräte Stellbefehle an alle Geräte zu verteilen. Jedes Gerät liest aus seiner Queue - und wenn der Gerätetreiber mangels Hardware nichts liest, stört das aufgrund der Längenbeschränkung der Queues auch nicht…
RE: Resourcen schonende Kommunikation - LV-New - 08.04.2020 17:50
Bräuchte nochmal Hilfe!
Versuche mich nun mehr und mehr in Queues einzuarbeiten...
Aktuell möchte ich gern die Slave-Queueschleife beenden, wenn aus der Masterschleife alle Queues gelesen wurden.
Aber irgendwie hänge ich gerade. Siehe Beispiel im Anhang (Wenn ich Queue-Status lesen in eine separate Schleife packe funktioniert es, warum nicht in der unten angehangenen Schleife?)
Kurze Erklärung warum es nicht geht wäre super, dann kann ich es auch verstehen.
Danke
RE: Resourcen schonende Kommunikation - jg - 08.04.2020 19:01
Schon mal dein VI im Highlighting Modus debuggt?
Du hast dir eine schöne Race-Condition programmiert in deinem Bsp-VI.
Get Queue Status in deiner Consumer-Loop wird je nach Ausführungsreihenfolge das erste Mal VOR dem ersten Enqueue in der Producer-Loop ausgeführt, lieert damit bei "Elements in Queue" als Ergebnis Null, womit du sofort deine Queue zerstörst...
"Elements in Queue" würde ich nicht dafür hernehmen, um einen Consumer zu beenden. Das ist eher zum Debuggen geeignet, ob der Consumer schnell genug hinterherkommt.
Lieber:
Vom Producer eine Nachricht an den Consumer senden, dass er aufhören soll.
Alternativ: Nach Ende des Consumers die Queue zerstören, und auf diesen Fehler im Consumer reagieren.
Nachteil dieses einfachen Ansatzes: Es gehen Meldungen verloren...
Nie, wirklich NIEMALS das Label eines Controls wegeditieren (wie bei dir der Stopp-Button).
Wenn du das Label im FP nicht sehen willst, dann dort per Rechtsklick -> Visible Itmes das Label nicht anzeigen.
Gruß, Jens
RE: Resourcen schonende Kommunikation - LV-New - 09.04.2020 08:26
Hi,
da hatte ich wohl die alter Version angehängt. :-(
Wie dem auch Sei, die Aufgabe sollte eben sein:
Es sollen keine Meldungen verloren gehen weder während der Producer Daten erzeugt (sollte durch Queue ja gesichert sein, richtig?) Noch nachdem der Producer fertig ist (Schleife beendet). Dennoch soll nachdem alle Werte aus der Queue gelesen wurden der Consumer Loop "automatische" geschlossen werden (Da Producer beendet wurde und keine Daten mehr ausgibt.)
Daher das "Elements in Queue".
Hintergrund: DAQ Daten Erstellung in einem separaten Loop zu einem TDMS lopp, der die Daten speichert.
Da hat doch bestimmt schon jemand was gemacht.... :-)
RE: Resourcen schonende Kommunikation - GerdW - 09.04.2020 08:49
Hallo LV,
Zitat:Da hat doch bestimmt schon jemand was gemacht.... :-)Dann lies dir bitte noch einmal Jens' Antwort von gestern abend durch!
So in etwa kann das aussehen:
[attachment=60856]
Statt eines simplen Strings kann/sollte man ein typdefiniertes Enum verwenden: dann landet man schon beim QueuedMessageHandler-Pattern…
Zitat:Hintergrund: DAQ Daten Erstellung in einem separaten Loop zu einem TDMS lopp, der die Daten speichert.Wenn es dir nur um die Datenspeicherung geht: das kann dein DAQmx-Task ganz allein erledigen! Dafür gibt es spezielle DAQmx-Funktionen und BeispielVIs im Beispielfinder!
RE: Resourcen schonende Kommunikation - jg - 09.04.2020 09:03
Hallo LV-New
Auch dieses Beisoiel wird genauso scheitern.
Der Consumer wird in dem Moment, in dem das erste Element in der Queue landet, dieses auslesen, danach ist die Queue leer und du zerstörst die Queue. Think Dataflow!!
Ich hatte dir schon eine Lösung angedeutet, es ist "Standard", über die Queue nicht nur Daten, sondern auch Kommandos weiterzugeben.
Ich hab mal schnell was zusammengeklickt:
[attachment=60857]
Hier gehören das Enum und der Cluster natürlich noch Typdefiniert, aber es soll nur das Prinzip darstellen.
Gruß
EDIT: Gerd war schneller (2 min)...
RE: Resourcen schonende Kommunikation - LV-New - 09.04.2020 09:14
Hey Danke Euch nochmal, manchmal hat man einfach ein Brett vor dem Kopf.
Oder anders gesagt.. bin ich gerade noch dabei die ganzen kleinen Puzzelteile zusammen zu suchen um eine schnelle, aber Ressourcen schonende Kommunikation zwischen meinen Schleifen zu erstellen.
RE: Resourcen schonende Kommunikation - kpa - 09.04.2020 09:59
Hallo LV-New,
übersichtlich und resourcenschonend geht es auch so (da viele Knotenpunkte wegfallen):
[attachment=60858]
Grüße
kpa
RE: Resourcen schonende Kommunikation - jg - 09.04.2020 11:42
(09.04.2020 09:59 )kpa schrieb: Hallo LV-New,
übersichtlich und resourcenschonend geht es auch so (da viele Knotenpunkte wegfallen):
Grüße
kpa
Dazu passend, aktuell kostenlos verfügbar:
https://learn.ni.com/training/resources/1266/channel-wire-communication
Gruß, Jens