+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: Datenkommunikation (/Forum-Datenkommunikation)
+---- Thema: Zwei Wege Kommunikation (/Thread-Zwei-Wege-Kommunikation)
Zwei Wege Kommunikation - Kiesch - 16.11.2011 13:01
Hallo liebe LVF Nutzer,
gibt es für Labview eine einfachere Möglichkeit sowas (zwischen zwei verschiedenen VIs) zur Prozesskommunikation zu realisieren als zwei Queues zu machen?
Randbedingungen:
Polling bzw. unnötige Wartezeiten sollen vermieden werden (deswegen fallen wohl FGVs, Shared und Globale Variablen raus, oder gibt es dafür "value change" Events?).
Realisiert habe ich das schon über zwei Queues (je Einelementig), die jeweils ausgelesen und damit wieder geleert werden. Jeder Prozess liest eine Queue und schreibt die andere. Durch die Beschränkung auf ein Element soll realisiert werden, dass genau so schnell geschrieben wird wie auch gelesen wird. Umgekehrt wird auch nur gearbeitet wenn ein Leseprozess stattgefunden hat, dann jedoch Zeitnah, so dass ich schnelles Ansprechverhalten auf Daten ohne Overhead durch schnelles Polling habe.
Kann man das Verhalten auch irgendwie anders (vulgo: einfacher) zusammenbauen?
Gruß Kiesch
RE: Zwei Wege Kommunikation - Y-P - 16.11.2011 13:16
TCP/IP?!
Gruß Markus
RE: Zwei Wege Kommunikation - unicorn - 16.11.2011 13:20
Wenn sozusagen "der Staffelstab" zwischen den beiden VI immer hinundher gereicht wird, ist die Semaphore das richtige. Befindet sich auf Synchronisationspalette. Im Prinzip bleibt der Aufwand der gleiche wie mit der einelementigen Queue.
RE: Zwei Wege Kommunikation - Kiesch - 17.11.2011 12:12
Müsste ich den Semaphor nicht auch pollen? Außerdem verstehe ich nicht wie ich das zur Kommunikation nutzen kann. (von A nach B) ich könnte maximal isolieren, dass nicht A und B gleichzeitig auf Daten schreiben - aber das hilft mir doch an sich nicht weiter (ausser mir racing conditions zu ersparen). Ich will ja von A mit B reden. Außerdem finde ich jetzt auf die schnelle keine "auf Semaphor freigabe warten" Funktion. Wie gesagt, polling will ich ja möglichst auch nicht.
Fällt mir auch grade ein:
Bremst es die Laufzeit stark, dass ich eine einelementige Queue verwende? (dabei muss ja immer erst der eine dann der andere Prozess arbeiten von daher muss der Prozessor etc. auch erstmal entsprechend Zeit zuteilen) Meine Daten kommen nämlich in der schon realisierten Variante typischerweise eher stoßweise (die werden von einem VI geliefert, dass ich fernsteuere und in dem mit Wartezeiten gepollt wird - daran wollte / konnte ich allerdings nicht großartig rumspielen, verbessern, da ich keine neuen Bugs da drin gebrauchen kann atm; allerdings ist die Kommunikation hier und da etwas langsam scheinbar (Daten gehen über ne Queue an nen Modul das TCP IP Kommunikation mit nem zweiten Rechner macht von dem aus die Daten dann wieder per Queue an ein VI gesendet werden - das ganze wie gesagt auf zwei Wege Basis. Entsprechend kann ich mir zumindest vorstellen, dass die Queue Größe da ein Flaschenhals für die Laufzeit ist).
Bin nämlich nach durchdenken für den Thread darauf gekommen, dass ich die Bedingung einelementig doch noch aufweichen könnte - dann würde mir allerdings die gewollte (sofortige) Info an den ersten Prozess abhanden kommen, dass die Daten aktuell nichtmehr verarbeitet werden können - einelementige Queue gibt mir entsprechend eine sofortige Response wenn irgendwas nicht geklappt hat - mit ner Mehrelementigen könnte ich lediglich sicherstellen, dass die Befehle in der richtigen Reihenfolge abgearbeitet werden - nicht aber, dass der sendende Prozess weis welche Befehle schon bearbeitet wurden...
Sorry wenn das vielleicht ein wenig wirr klingt. Hoffe es is einigermaßen verständlich. Kernpunkt der Frage ist:
Bremst es die Ausführungszeit stark ein wenn eine einlementige Queue zur Kommunikation genutzt wird statt eine Mehrelementige - unter der Maßgabe, dass bei der mehrelementigen jeweils ein Element gelesen würde bis die leer ist und dann auf neue Daten gewartet wird und, dass die Daten eher Stoßweise kommen mit längeren Leerzeiten (10ms Bereich) zwischen den Daten"bündeln?
P.S: Zu TCP/IP - finde ich persönlich zu kompliziert... Und auch da muss man minimum zwei Ports nehmen um die Kommunikation sauber zu trennen. Dazu kommt, dass man keine Trennung nach Datenpaketen hat (ein String den ich über eine Queue sende bringt seine Länge gleich mit, ist also über die Queue in seiner Länge definiert - ensprechend sauber kann ich einzelne Befehle voneinander trennen; bei TCP IP müsste ich nach Steuerzeichen durchsuchen die die Befehle trennen (was geht) und zusätzlich entweder Zeichenweise lesen oder eine Kommunikation programmieren, die erst Länge der gesendeten Daten und dann die Daten sendet. Geht natürlich auch - ist aber meiner Meinung nach noch deutlich mehr aufwand als das über Queues zu machen.
Die Hauptfrage wäre dann also: Wie performant sind Zeichenweise TCP IP Leseprozesse auf Localhost? Falls die schnell genug sind könnte das eventuell tatsächlich ne alternative sein... (Größenordnung dürfte bei ~30 Zeichen pro Befehl im Mittel liegen).
RE: Zwei Wege Kommunikation - unicorn - 17.11.2011 12:42
Durch das Senden-Antwort-Verhalten ist die Performance reduziert. Es ist als würde alles auf einem Rechner seriell ablaufen. Der Verzicht auf das Warten auf die Antwort würde die Performance erhöhen. Wenn der Sendeprozess zwingend auf die Antwort der vorherigen Aktion angewiesen ist, kannst Du nichts ändern.
Das Netzwerk kann auch die Perfomance verschlechtern, wenn andere Daten über das Netzwerk gesenden werden.
Wenn Du nicht auf das Ergebnis des Verarbeitungsprozesses angewiesen bist, bietet sich eine viel-elementige Queue an. Diese speichert die Daten zwischen. Damit können stoßweise anfallende Daten kontinuierlich verarbeitet werden oder der Sendeprozess kann kontinuierlich Daten einstellen auch die Verarbeitung der Daten unterschiedlich lange dauert.