Kommunikation von externen Geräten über TCP/IP

Hallo Forum!

In einem von mir erstellen Unterprogramm baut LabVIEW über Ethernet und TCP/IP eine Verbindung zu einem externen Gerät auf. Es werden Daten gesendet und empfangen, alles funktioniert ohne Probleme.

Dieses Unterprogramm kann vom Hauptprogramm zweimal aufgerufen werde, da ich zwei externe Geräte ansteuern muss. Dieser parallele Aufruf erfolgt oft zeitgleich. Das läuft auch meist über einen längeren Zeitraum gut (bis zu 24 Stunden). Dann sieht es so aus, als ob eines der externen Geräte keine Daten vom Rechner empfängt.

Meine Frage daher: Hat jemand Erfahrungen mit dem parallelen Aufbau von zwei TCP/IP Verbindungen zu externen Geräten?

Hardware: Rechner mit einer Netzwerkkarte, dann ein Switch, daran sind die externen Geräte angeschlossen.

Vielen Dank für Eure Mühe!
Vogster

Anzeige

' schrieb:Hallo Forum!
(snipp)
Dieses Unterprogramm kann vom Hauptprogramm zweimal aufgerufen werde, da ich zwei externe Geräte ansteuern muss. Dieser parallele Aufruf erfolgt oft zeitgleich. Das läuft auch meist über einen längeren Zeitraum gut (bis zu 24 Stunden). Dann sieht es so aus, als ob eines der externen Geräte keine Daten vom Rechner empfängt.

(snipp)

Vielen Dank für Eure Mühe!
Vogster

Hallo Vogster,

Hat der Rechner eine festeingetragene IP oder bekommt er die per DHCP? (Dann könnte es sein das er nach 24h die Adresse neu zugewiesen bekommt.)

Ansonsten würd ich vielleicht mal mit Wireshark oder einem anderen TCP/IP-Sniffer den Datenstrom im Netzwerk analysieren, besonders was da kurz vor dem Verbindungsabbruch passiert.

Gruß, Robert

Hi Robert,

alle Geräte haben eine fest zugewiesene IP-Adresse.

Ich werde den Datenverkehr mal mitschreiben, vielleicht ergibt sich ja was.
Vielen Dank für die Anregung.

Leider bin ich was den Hintergrund von TCP/IP mit LabVIEW angeht nicht so bewandert. Ist es vom Prinzip möglich/richtig/unsauber/, dass mehrere Verbindungen (besonders mit LabVIEW) zeitgleich aufgebaut werden?

Mit freundlichen Grüßen und vielen Dank
Vogster

Hallo,

ich kenne mich damit auch nicht so aus, aber vielleicht hilft Dir das weiter.....

Gruß Markus

' schrieb:Hi Robert,

alle Geräte haben eine fest zugewiesene IP-Adresse.

Ich werde den Datenverkehr mal mitschreiben, vielleicht ergibt sich ja was.
Vielen Dank für die Anregung.

Leider bin ich was den Hintergrund von TCP/IP mit LabVIEW angeht nicht so bewandert. Ist es vom Prinzip möglich/richtig/unsauber/, dass mehrere Verbindungen (besonders mit LabVIEW) zeitgleich aufgebaut werden?

Mit freundlichen Grüßen und vielen Dank
Vogster

' schrieb:Hi Robert,

alle Geräte haben eine fest zugewiesene IP-Adresse.

Ich werde den Datenverkehr mal mitschreiben, vielleicht ergibt sich ja was.
Vielen Dank für die Anregung.

Leider bin ich was den Hintergrund von TCP/IP mit LabVIEW angeht nicht so bewandert. Ist es vom Prinzip möglich/richtig/unsauber/, dass mehrere Verbindungen (besonders mit LabVIEW) zeitgleich aufgebaut werden?

Mit freundlichen Grüßen und vielen Dank
Vogster

Ich habe verschiedene Applikationen geschrieben in denen ich teilweise dutzende von TCP/IP Verbindungen gleichzeitig offenhalte und mit den entsprechenden Endpunkten (teilweise andere LabVIEW Applikationen) kommuniziere.

Das Geheimnis für eine langdauernde, problemlos funktionierende TCP/IP Kommunikation ist, dass man die Kommunikation robust implementiert. Das kann auf zwei Arten. Jedesmal die Kommunikation öffnen, lesen und schreiben was man muss und dann gleich wieder abschliessen.

Oder aber einmal öffnen, die refnum speichern und dann immer wieder kommunizieren. Wenn eine der Lese- oder Schreibfunktionen einen Fehler zurückgibt, abhängig von diesem Fehler folgende Dinge tun:

Timeout error: 1 oder mehrere Male retry und bei einer bestimmten Anzahl von retries Abbruch
Bei allen anderen Fehlern Abbruch.

Abbruch bedeutet, dass die refnum abgeschlossen wird und wieder neu geöffnet wird und dann geht es weiter. Auf diese Weise habe ich Applikationen geschrieben die Monate lang miteinander kommunizieren ohne je auszufallen. Eingebautes Logging zeigt mir dass die Verbindungen regelmässig mit Fehlern abgebrochen werden und wieder neu afgebaut werden, aber mit entsprechender retry Logik nach einem Fehler geht das ohne Probleme. Überlebt sogar das Entfernen des Netzwerkkabels und wieder anschliessen, wobei die Kommunikation während der unterbrochenen Netzwerkverbindung natürlich wegbleibt und die entsprechenden Applikationsteile auf den Wiederaufbau der Verbindung warten, ohne aber den Rest der Applikation zu blockieren solange das möglich ist.

Rolf Kalbermatter

Hallo Rolf,

vielen Dank, damit hast Du mir ein ganzes Stück geholfen.

Zur Absicherung, dass wir beide das selbe Problem habe, hätte ich noch einige Fragen:

- Die Fehlermeldungen von LabVIEW sind "Fehler 56 ist bei TCP - Lesen aufgetreten" Fehler 56 bedeutet laut Hilfe: Die Netzwerk-Operation hat die vom Benutzer oder System vorgegebene Zeitbegrenzung überschritten. Das wird der von Dir beschriebene Timeout sein. Dann habe ich noch den Fehler Nr. 62: Das System hat die Netzwerkverbindung abgebrochen.
Sind das die Fehler, mit denen Du auch zu kämpfen hattest?

- Ich habe die Ethernetverbindung mit Wireshark abgehört (wie oben empfohlen). Dabei ist sichtbar, dass die Kommunikation eigentlich sehr gut funktioniert (keine Prüfsummenfehler etc.). Manchmal hört die Kommunikation (im LabVIEW Fehlerfall) einfach auf, ich habe aber auch Fälle gehabt, wo bei der letzten Nachricht das Reset - Flag gesetzt war. Kann mir jemand sagen, was bei einem Reset - Flag passiert? Muss ich die Verbindung dann seitens LabVIEW neu abfbauen? Wie lange dauert so ein Bus - Reset? Ich habe gelesen (Wiki), dass ein Reset - Flag aufrund eines technischen Problems gesetzt wird. Hat da jemand ein paar Details oder Erfahrungen?

Mein Hauptproblem ist nun wohl, dass ich die Nachricht nur ein mal versende und hoffe (davon ausgehe), dass sie auch ordnungemäß ankommt. Bei TCI-IP können wohl auch Daten "einfach so" verloren gehen (Bitte korrigiert mich, wenn falsch). Obwohl ich ein Netz habe, dass keine Verbindung zu einem Firmennetz oder gar zum Internet hat.

Rolf, wie oft kommen denn solche Verbindungsfehler bei Dir vor? Bei mir schwankt das so zwischen 3 und 24 Stunden.

Ich werde wohl eine retry Logik einbauen und gleichzeitig die Nachrichten zyklisch versenden. Sieht nach etwas Arbeit aus!

Vielen Dank für Eure Hilfe!
Jens

' schrieb:Die Fehlermeldungen von LabVIEW sind "Fehler 56 ist bei TCP - Lesen aufgetreten" Fehler 56 bedeutet laut Hilfe: Die Netzwerk-Operation hat die vom Benutzer oder System vorgegebene Zeitbegrenzung überschritten. Das wird der von Dir beschriebene Timeout sein. Dann habe ich noch den Fehler Nr. 62: Das System hat die Netzwerkverbindung abgebrochen.
Sind das die Fehler, mit denen Du auch zu kämpfen hattest?

Den Fehler 56 musst du abfangen, der ist völlig normal, wenn du innerhalb einer While Schleife das TCP Read ausführst und die Primitive nichts empfangen hat. Es ist ja nichts schlimmes, wenn mal nichts ankommt, es sei denn deine Geräte senden schneller als der Timeout von "TCP Read", dann deutet das darauf hin, dass das Gerät nichts mehr sendet.

Ich bin mir eigentlich sicher, dass das Gerät innerhalb des Timeouts sendet. Es geht ja auch mal 24 Stunden gut.
Der Ablauf ist immer komplett identisch und recht einfach. Daher komisch, dass ab und an mal nichts ankommt.
Kann das so eine wo auch immer verloren gegangene Nachricht sein?
Und wie kann dieser Reset zustande kommen?

mfg
Jens

' schrieb:Ich bin mir eigentlich sicher, dass das Gerät innerhalb des Timeouts sendet. Es geht ja auch mal 24 Stunden gut.
Der Ablauf ist immer komplett identisch und recht einfach. Daher komisch, dass ab und an mal nichts ankommt.
Kann das so eine wo auch immer verloren gegangene Nachricht sein?
Und wie kann dieser Reset zustande kommen?

mfg
Jens

das liegt mit am Prinzip von TCP/IP, das ist ja keine direkte Verbindung zwischen zwei Geräten sondern ein Fehlertolerantes Übertragungsprotokoll an dem mehrere Parteien beteiligt sind: Netzwerkkarten, Switches, Router, Firewalls ... etc. Es kann durchaus mal vorkommen, dass eine der beteiligten Parteien der Meinung ist, dieses eine Paket soll nun nicht weiter transportiert werden, weil dies oder jenes nicht passt ...

Hallo zusammen,
zunächst ein Dankeschöne für Eure Hilfe!

Eine Verständnisfrage wäre da noch:

Ich baue mit einer IP - Adresse und einem Port eine Verbindung auf, in LabVIEW arbeitet die Funktion TCP - lesen gerade nicht, und zeitgleich sendet die Gegenstelle Daten.

Werden diese in irgendeinem Zwischenspeicher gespeichert?

Wenn dann wieder die Funktion TCP - Lesen aktiviert wird, und die Anzahl der zu lesenden Byte steht bspw. auf 10 oder die Funktion soll auf ein CRLF warten, wird der Zwischenspeicher dann nach dem "first in first out" - Prinzip ausgelesen?