(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.
