Problem mit TCPIP

Hallo,

ich habe das Problem, dass ein Gerät über TCPIP sich deutlich langsamer ansteuern lässt als über GPIB. Im Detail:
Ich habe eine Widerstandsmessbrücke LakeShore 732, bei der es möglich ist ein Kalibrationskurve an das Gerät zu senden, so dass intern der gemessene Widerstandswert in eine Temperatur umgerechnet und angezeigt wird. Naturgemäß ist diese Kalibrationskurve ein größeres Datenpaket, das möglichst zügig übertragen werden sollte, damit der Nutzer nicht ewig Däumchen drehen muss.
Diese Widerstandsmessbrücke bietet als Interfaceoption sowohl GPIB als auch Ethernet. Benutze ich GPIB (mit der VISA Adresse GPIB0::15::INSTR) klappt alles wunderbar, verwende ich stattdessen Ethernet/TCPIP (mit der VISA Adresse TCPIP::192.168.0.12::7777::SOCKET) brauche ich zwingend die im nachfolgenden Screenshot rot eingekringelten Wartezeiten (Werte empirisch ermittelt - können auch etwas kleiner sein). Ohne diese Wartezeiten werden die Kommandos verschluckt/nicht ausgeführt.
Ist das jetzt ein Problem dieser Widerstandsmessbrücke oder mache ich da einen Fehler bezüglich TCPIP? Bin leider nicht so der Netzwerkexperte. Gefunden habe ich schon den TCPIP-Eigenschaftsknoten "no packet delay" - aber der ist von Hause eh schon aktiviert und da dran rumfummeln bringt mich nicht weiter.

Gruß, Thomas

p.s.: Das im Screenshot sichtbare Sub-VI "interf. cmd" benutzt "VISA write" aus der VISA-Palette - ob synchron oder asynchron macht keinen Unterschied.

Anzeige

(07.10.2016 08:34 )THL schrieb:  p.s.: Das im Screenshot sichtbare Sub-VI "interf. cmd" benutzt "VISA write" aus der VISA-Palette - ob synchron oder asynchron macht keinen Unterschied.

Und fügt dieses VI einen Terminationcharcter an das Ende des Kommmandos? Bei GPIB besteht eine spezielle Handshakeleitung die normalerweise beim letzten Messagebyte aktiviert wird um anzugeben dass die Message zu Ende ist. Bei Ethernet lässt sich so eine Datenleitung nur sehr schwer und äusserst unpraktisch realisieren.

Deshalb macht man das dort anders, indem man einen oder mehrere spezielle Character ans Ende anfügt. Dazu verwendet man oft ein carriage return oder line feed character oder beides zusammen. Viele Geräte antworten gar uicht wenn man diesen Terminationcharacter nicht verwendet, manche warten eine bestimmte Zeit und wenn dann nichts weiteres mehr kommt, interpretieren sie das bis dahin empfangene Kommando trotzdem.

Lies mal das Manual und mach Dich schlau, welchen Terminationcharacter Dein Gerät erwartet.

Danke für die Antwort, aber leider trifft deine Vermutung hier nicht zu:
Ein Terminationcharakter wird selbstverständlich bei der Initialisierung definiert und beim Senden auch entsprechend angehängt. Ich kann ja auch problemlos mit dem Gerät per GPIB oder TCP/IP kommunizieren, nur dass es über TCP/IP deutlich zäher geht als über GPIB.

Da noch keiner geschrieben hat "wenn du TCP/IP verwendest, musst du dies und jenes beachten um eine schnelle Kommunikation zu gewährleisten", nehme ich inzwischen an, dass das Kommunikationsproblem auf die nicht so optimal implementierte Ethernet-Firmware im Messgerät selbst zurückzuführen ist und nicht auf ein Fehler von mir bei der Verwendung von TCP/IP.
Der Satz aus dem Handbuch
"TCP uses error correction and collision avoidance schemes that make it a very reliable
form of Ethernet communication, but has drawbacks of having nondeterministic timing,
and can encounter relatively large delays depending on network conditions."
stimmt mich auch nicht gerade glücklich.
Ich habe derzeit das Gerät zu Testzwecken per cross-link Kabel direkt an einer separaten Netzwerkkarte. Ich denke, bessere Netzbedingungen kann man kaum schaffen; nichtsdestotrotz muss ich die im Eingangspost erwähnten Delays verwenden um eine einwandfrei Kommunikation zu gewährleisten.

Sieht also so aus, als ob ich (bzw. der Nutzer meines Programmes später) tatsächlich beim Betrieb des Gerätes des öfteren mal ein Wartepäuschen einlegen muss. Ist halt blöd, wenn man einen Ok-Knopf drückt und der Rechner erstmal eine Minute lang nur "please wait..." anzeigt. Ich denke ich werde dann wohl sowas wie einen Fortschrittsbalken implementieren, damit der User sieht, dass überhaupt etwas passiert

(10.10.2016 08:37 )THL schrieb:  Danke für die Antwort, aber leider trifft deine Vermutung hier nicht zu:
Ein Terminationcharakter wird selbstverständlich bei der Initialisierung definiert und beim Senden auch entsprechend angehängt. Ich kann ja auch problemlos mit dem Gerät per GPIB oder TCP/IP kommunizieren, nur dass es über TCP/IP deutlich zäher geht als über GPIB.

Da noch keiner geschrieben hat "wenn du TCP/IP verwendest, musst du dies und jenes beachten um eine schnelle Kommunikation zu gewährleisten", nehme ich inzwischen an, dass das Kommunikationsproblem auf die nicht so optimal implementierte Ethernet-Firmware im Messgerät selbst zurückzuführen ist und nicht auf ein Fehler von mir bei der Verwendung von TCP/IP.
Der Satz aus dem Handbuch
"TCP uses error correction and collision avoidance schemes that make it a very reliable
form of Ethernet communication, but has drawbacks of having nondeterministic timing,
and can encounter relatively large delays depending on network conditions."
stimmt mich auch nicht gerade glücklich.
Ich habe derzeit das Gerät zu Testzwecken per cross-link Kabel direkt an einer separaten Netzwerkkarte. Ich denke, bessere Netzbedingungen kann man kaum schaffen; nichtsdestotrotz muss ich die im Eingangspost erwähnten Delays verwenden um eine einwandfrei Kommunikation zu gewährleisten.

Sieht also so aus, als ob ich (bzw. der Nutzer meines Programmes später) tatsächlich beim Betrieb des Gerätes des öfteren mal ein Wartepäuschen einlegen muss. Ist halt blöd, wenn man einen Ok-Knopf drückt und der Rechner erstmal eine Minute lang nur "please wait..." anzeigt. Ich denke ich werde dann wohl sowas wie einen Fortschrittsbalken implementieren, damit der User sieht, dass überhaupt etwas passiert

Deine Beweisführung ist aber nicht lückenlos. Um VISA dazu zu veranlassen eine Terminationcharacter an gesendete Strings anzuhängen musst Du mehrere Attribute der VISA Session richtig setzen. Ich verwende immer nur die automatische Terminationserkennung von VISA für einkommende Daten, und hänge nötige Terminationscharacter immer explizit an die ausgehenden Kommandos.

Manche Geräte reagieren tatsächlich überhaupt nicht wenn man keinen Terminationscharacter sendet aber manche warten einfach eine bestimmte Zeit (mehrere 100 ms) und wenn dann keine neuen Daten eintreffen wird der bis dahin empfangene String trotzdem ausgewertet. Genau dieses Verhalten könnte eine gute Erklärung für das scheinbar träge antworten Deines Gerätes sein. Versuche deshalb mal explizit den nötigen Terminationcharacter anzuhängen um zu sehen ob das einen Unterschied macht. Schaden kann es nicht, um es auszuprobieren und ich habe ganz am Anfang mehrmals versucht das durch VISA machen zu lassen und die verschiedenen Attribute waren recht verwirrend, besonders wenn man das mit einem seriellen Port probiert der da noch extra Attribute hat die das Verhalten mitbeeinflussen.

Eine andere Möglichkeit wäre, dass gerade Dein Crosslinkkabel das Problem ist. Theoretisch haben heute alle Geräte autonegotiation für MDI-X. Aber bei gewissen Geräten geht das falsch wenn beide Seiten auto MDI-X versuchen zu machen und dann kann der Netzwerklink gar nicht oder sehr schlecht funktionieren.