Netzwerkkommunikation zwischen Vi's

Hallo alle,

im Rahmen eines Projektes stellt sich mir folgende Aufgabensituation:
An unserem Versuchsaufbau sind 2 PCs integriert. Einer davon steuert Parameter des Experiments, der Andere eine Kamera. Was ich nun realisieren soll, ist immer dann ein Bild aufzunehmen, wenn etwas im Aufbau verändert wurde, sprich PC1 einen Parameter neu setzt.
Ich muss also ein VI auf PC2 mit dem VI auf PC1 triggern.

Eine unidirektionale Kommunikation langt hier im Prinzip. Also "Mach Bild" -> macht Bild.
Bidirektional wäre ev. auch eine Überlegung wert. "Mach Bild" -> macht Bild -> "Bild gemacht" -> Schritt weiter -> ...

Die Frage ist, wie mach ich das am Besten?
Hatte bis jetzt noch nicht viel mit Netzwerken zu tun, dewegen würde mich interessieren, was ihr da für die Beste Lösung haltet.

Die beiden PCs sind WinXP Rechner und mit einem lokalen Netzwerk verbunden. Zusätzlich kann ich auch über Com Ports eine Verbindung aufbauen.

Meine bisherige Lösung (die soweit auch funktioniert) ist, mittels COM Port und Visa einen beliebigen String zu übermitteln. Das Slave VI befindet sich in einer Endlosschleife, die ständig überprüft ob Bytes am Com Port liegen. Wenn ja -> überprüfen und gegebenenfalls ein Bild machen.

Was ich noch entdeckt habe wären diese Visa Events. Leider kenn ich mich hier gar nicht aus. Wäre das eine Alternative? Z.B.: auf einen Break warten.
Oder soll ich doch über Globale Variablen oder Referenzen arbeiten. Und wenn ja, wie muss ich da vorgehen, Server konfigurieren?

Vielen Dank, Grüße

Wenn die beiden PCs schon in einem Netzwerk sind, kannst du doch gleich TCP/IP reden und brauchst kein serielles Kabel. Einfach die IP Adresse und einen freigegebenen Port beim Open TCP eingeben, dann hast du schon die Verbindung aufgebaut. Dann kannst du von einem PC zum anderen ein Befehl schicken, z.B. "Mach Bild" und der 2. PC kann dan antworten, wenn er soweit ist. Geht doch relativ einfach.


Gruss, Eugen

P.S.

Schau dir das hier:
http://www.LabVIEWforum.de/index.php...ost&p=24240

Da nimmst du eine While-Schleife für PC1 und eine für PC2, vergiss aber nicht die richtige IP-Adresse einzustellen.

Hallo,

ich mache das mit "Shared Variables". Die beruhen auch auf TCP/IP und sind einfach zu handhaben.

Gruß Markus

In meinem jugendlichen Eifer schliesse ich mich M.Weippert an.

Wenn später noch mehr PCs was sehen wollen, können diese dann auch schon ohne großartiges Zutun diese Variable "sehen". Wie steht es denn mit der Zeit aus? Soll das auslösen des Bildes Zeitkritisch (deterministisch) behaandelt sein? Dann würde ich eine Direktverbindung vorziehen und evtl. sogar in Richtung RealtimeDesktop.

Aber wenn es relativ Wurscht ist (heavy traffic on Netzwerk kurz vor Mittagspause) wie zeitversetzt das Bild aufgenommen wird, bleibe ich bei M.Weipperts Vorschlag unter Win.

Gruß

' schrieb:In meinem jugendlichen Eifer schliesse ich mich M.Weippert an.

Wenn später noch mehr PCs was sehen wollen, können diese dann auch schon ohne großartiges Zutun diese Variable "sehen". Wie steht es denn mit der Zeit aus? Soll das auslösen des Bildes Zeitkritisch (deterministisch) behaandelt sein? Dann würde ich eine Direktverbindung vorziehen und evtl. sogar in Richtung RealtimeDesktop.

Aber wenn es relativ Wurscht ist (heavy traffic on Netzwerk kurz vor Mittagspause) wie zeitversetzt das Bild aufgenommen wird, bleibe ich bei M.Weipperts Vorschlag unter Win.

Gruß

Zeitkritisch != deterministisch

Und "Realtime OS" hat keinen Einfluss auf die Netzwerkübertragungsgeschwindigkeit !

Gruss

Doch Eugen.

Link1
Link2

Mit dem RealTime Modul kommt sogar ein sogenanntes RealTime FIFO dazu...

Und da Determinismus heisst, dass ich weiss, wie lange ich maximal für etwas brauche (z.B. u.A. Übertragungszeit), kann ich damit sagen, dass diese Direktverbindung zweier PCs max. soundso lange zur Übertragung des grössten Datenpaketes benötigt.
Damit kann ich meinen zeitkritischen Auftrag (Bild auslösen) deterministisch beschreiben.

Aber Du hast damit recht, dass das OS nichts damit zu tun hat. Lediglich die Direktverbindung und die Möglichkeiten des RT-Modules ermöglichen den Einfluss.

Greetings.

' schrieb:Mit dem RealTime Modul kommt sogar ein sogenanntes RealTime FIFO dazu...

aber ganz bestimmt nicht in die TCP/IP Kommunikation. Diese ist per se weder deterministisch noch in irgend einer Weise echtzeitfähig. Der RT FIFO ist quasi das Gegenstück zu einer Queue (nur halt mit mehr oder weniger festem Speicherbedarf) und wird z.B. in der AI Schleife verwendet um die Daten zur TCP-Schleife zu schieben.

' schrieb:ich mache das mit "Shared Variables". Die beruhen auch auf TCP/IP und sind einfach zu handhaben.

Sharded Variables beruhen auf UDP, sonst können die gar keinen Determinismus versprechen!
http://zone.ni.com/devzone/cda/tut/p/id/4679

Eben drum!

Wenn die "queue" als shared variable definiert wird, ist sie ja über UDP deterministisch...oder stimmt das nicht? Immer unter der Voraussetzung der Direkten Verbindung, also keinerlei sonstiger Traffic auf dem "Netzwerk".

Wobei hiermit sogar auch bei "nebenverkehr" noch entsprechend Performance rauszuholen sein müsste (ob das kompatibel ist?). Aber ist dann halt wieder was anderes..

Gruß

Mist, dann hat mir damals der NI-ler auf der Messe was falsches erzählt.
Einfach zu handhaben sind sie aber allemal. Anlegen, Typ einstellen, IP-Adresse der Variablen anlegen. Fertig.

Gruß Markus

' schrieb:Sharded Variables beruhen auf UDP, sonst können die gar keinen Determinismus versprechen!
http://zone.ni.com/devzone/cda/tut/p/id/4679

' schrieb:Wenn die "queue" als shared variable definiert wird, ist sie ja über UDP deterministisch...oder stimmt das nicht? Immer unter der Voraussetzung der Direkten Verbindung, also keinerlei sonstiger Traffic auf dem "Netzwerk".

Wobei hiermit sogar auch bei "nebenverkehr" noch entsprechend Performance rauszuholen sein müsste (ob das kompatibel ist?). Aber ist dann halt wieder was anderes..

Es gibt einen Modus (Time Triggered) bei network published Shared Variables, der sowas wie Determinismus verspricht. Ich hab's selber noch nicht ausprobiert und kann da nicht viel dazu sagen, aber vorhanden ist es. Der Determinismus beruht praktisch darauf, dass man sich darauf verläßt, dass die Hardware (das Netzwerkkabel), die Daten schnell genug schicken kann und ist höchstwahrscheinlich (wo auch sonst?) im NI-PSP Protokoll implementiert. Determinismus heißt ja nicht "verdammt schnell" sondern "ganz bestimmt innerhalb einer festgelegten Zeitspanne"

' schrieb:Mist, dann hat mir damals der NI-ler auf der Messe was falsches erzählt.

mei - shit happens, da hat wohl jemand die eigenen WhitePapers nicht gelesen

' schrieb:Einfach zu handhaben sind sie aber allemal. Anlegen, Typ einstellen, IP-Adresse der Variablen anlegen. Fertig.

Für einfache Datentype, ja. Wenn man aber den Datentyp "Custom" wählt und z.B. einen getypedeften Cluster schicken möchte, wird man feststellen, dass Änderungen am Typedef nicht in die SharedVariable übernommen werden, und das find ich ganz schön eklig - ich hab auch schon bei NI deswegen gemeckert und hoffe, dass das in der nächsten Version geändert ist ...