TCP/IP Verbindungs-Problem

Hallo Zusammen,

ich habe ein VI zur Steuerung eines Netzteils geschrieben und die Verbindung läuft über TCP/IP. Allerdings läuft die Verbindung über ein Netzwerk bestehend aus zwei Switches an denen 8 PCs und weitere Messgeräte hängen. Die IPs werden automatisch mittels DHCP verteilt.

Wenn die Netzwerkadressen übereinstimmen läuft das VI ohne Probleme.

Manchmal werden die IP-Adressen so vergeben, dass die Netzwerkadressen von PSU und PC nicht identisch sind. Und scheinbar tritt immer dann der TCP/IP-Verbindungsfehler Code 56 auf. Teilweise werden noch die ersten drei Befehle korrekt an das PSU geschickt, dann aber scheint es möglicherweise ins Timeout zu laufen, u.a. auch weil nicht nur gesendet sondern auch empfangen wird. Es scheint so als würde in diesem Fall die Verbindung deutlich langsamer sein und somit ins Timeout laufen bzw. gesendet und empfangen zur selben Zeit ohne auf Antwort zu warten, aber das ist nur eine Annahme meinerseits.

Was kann ich dagegen tun? Ich habe bereits versucht manuell eine feste IP festzulegen, dies scheiterte aber daran das ich keinen Zugriff auf das Netzwerk habe. Auch die Neuvergabe einer IP-Adressse über DHCP mittels "ipconfig release", "ipconfig renew", scheiterte.

Wenn ich das Netzgerät anpinge bekomme ich immer eine Antwort, trotzdem tritt der Code56 bei bestimmten IP-Adressen regelmäßig auf.

Gibt es eine Möglichkeit bei Timeout bzw. Verbindungsabbruch, den Code 56 zu umgehen und eine neue Verbindung herzustellen?

Für eure Hilfe wäre ich sehr dankbar.


Grüße Tom

Anzeige

Hallo Tom,

Zitat:Manchmal werden die IP-Adressen so vergeben, dass die Netzwerkadressen von PSU und PC nicht identisch sind.

Die IP-Adresse von PC und PSU müssen IMMER UNGLEICH sein…

Zitat:Wenn die Netzwerkadressen übereinstimmen läuft das VI ohne Probleme.

Wenn zwei Geräte mit identischen IP-Adressen im Netzwerk sind, dann treten Probleme auf!

Zitat:trotzdem tritt der Code56 bei bestimmten IP-Adressen regelmäßig auf.

Bei welchen IP-Adress-Kombinationen tritt der Fehler denn auf?

(10.04.2024 23:48 )SirTom schrieb:  Ich habe bereits versucht manuell eine feste IP festzulegen, dies scheiterte aber daran das ich keinen Zugriff auf das Netzwerk habe.

Hast du Zugriff auf das Netzteil? Dann sollte es reichen, wenn du dort eine feste IP-Adresse einstellst, die in dem Netztwerk gültig ist.
Wenn das Netzteil per DHCP Adressen aus dem Bereich 192.168.x.x bekommt, vergibst du zB die feste Adresse 192.168.10.10.

Für einen Verbindungsaufbau mit TCP brauchst du eine feste IP oder den Namen des Gegenübers. Wenn die Namansauflösung in dem Netzwerk richtig konfiguriert ist, kann man Rechner immer über ihren Namen ansprechen, egal welche IP-Adresse sie haben. Vielleicht kann dir deine IT das für dein Netzteil einrichten.

Danke für eure Antworten, der Code 56 tritt immer dann auf, wenn sich die Netzwerkadresse im dritten Cluster unterscheidet, ist diese identisch und sozusagen nur die Host-ID unterschiedlich, läuft alles wunderbar.
Meist kann ich das PSU trotzdem anpingen und das VI kann noch 2-3 Befehle an das PSU senden, bevor der Fehler auftritt.
Allerdings stelle ich für jeden Befehl den ich sende eine neue TCP/IP-Verbindung her und trenne diese sofort wieder.

z. B. bei

10.27.194.126 (PSU)
10.27.194.148 (PC)

tritt kein Fehler auf, jedoch bei

10.27.194.126 (PSU)
10.27.206.123 (PC)

schon.

Eigentlich sollte doch wegen Routing es egal sein, das sich die Netzwerkadresse an dritter Stelle unterscheidet, aber es wirkt so als würde PSU und PC manchmal zur selben Zeit senden bzw. das PSU nicht hinterherkommen.

Auf das Netzwerk habe ich keinen Zugriff. Ich könnte versuchen DHCP sowohl am PC als auch beim PSU abzustellen und die IP-Adresse + Subnetmaske manuell zu setzen, aber ob dann die Verbindung noch klappt, da beide Geräte nicht direkt miteinander verbunden sind?

Gibts vllt eine Lösung mittels Labview, die Verbindung wiederherzustellen und den Code 56 anschließend zu ignorieren?

(11.04.2024 14:01 )SirTom schrieb:  ..der Code 56 tritt immer dann auf, wenn sich die Netzwerkadresse im dritten Cluster unterscheidet, ...

Stimmt hier denn die Subnetzmaske? Kann die PSU eine andere Subnetzmaske? (Eine andere als 255.255.255.0)

Wir haben bei uns die Messkarten direkt mit eigener LAN-Karte am jeweiligen PC, nur eine ist über WLAN im Firmennetz und hier haben wir eine fest IP vergeben lassen (die IT arbeitet mit uns, da hab ich Glück).
Diese Variante würde ich auch empfehlen, sonst wirst du immer von der IT abhängig sein. Geht natürlich nicht immer..

Eine Option ist noch, ob die PSU vielleicht einen Broadcast sendet, bis eine Verbindung aufgebaut ist.

mfg Timo

Beide Geräte nutzen die selbe SubnetMaske 255.255.0.0 bzw. das gesamte Netzwerk.

Könnte es an meinem VI liegen? Und sobald Routing eingreift, die Verbindung minimal langsamer ist und deshalb es zum Timeout kommt? Letztendlich befeuer ich in manchen Zuständen der StateMachine das PSU nacheinander mit Befehlen ohne Delay dazwischen.

Anzeige

Ich war gerade nochmal vorort und habe eure Antworten berücksichtigt. Es scheint doch nicht am Unterscheid des 3. Clusters zu liegen, sondern eher daran, dass das Netzteil nur bestimmte IP-Adressen je nach Subnetmask akzeptiert und dem PSU manchmal eine IP-Adresse zugewiesen wird, die es nicht mag.

Danke nochmals für eure Hilfe!

(11.04.2024 17:36 )SirTom schrieb:  Ich war gerade nochmal vorort und habe eure Antworten berücksichtigt. Es scheint doch nicht am Unterscheid des 3. Clusters zu liegen, sondern eher daran, dass das Netzteil nur bestimmte IP-Adressen je nach Subnetmask akzeptiert und dem PSU manchmal eine IP-Adresse zugewiesen wird, die es nicht mag.

Das klingt plausibel - so ein Gerät ist mir auch schon einmal über den Weg gelaufen.

Nebenbei: DHCP Server lassen sich so einstellen, dass sie einer MAC Adresse immer die gleiche IP Nummer zuweisen. das ist, von außen betrachtet, so wie bei einer am Netzteil fest eingestellen IP-Nummer.