' schrieb:Am einfachsten, machst du einen Timeout (z.B. 1 Sekunde) und falls kein Timeout ist, dann Daten auswerten.

Zitat:Und wenn ich das richtig gesehen habe, liest ja VISA Read beim Timeout ebenfalls den Buffer aus. Das heisst, ich habe dann unter Umständen, nämlich wenn das Timeout mitten während einer Übertragung erfolgte, nur einen Teil des Kommandos am Ausgang von VISA Read und der Rest wird später in den Buffer geschrieben. Ich müsste dann also nochmals auslesen und die beiden Teile zusammensetzen

' schrieb:Der Timout läßt sich war nicht deaktivieren, aber reichen Dir denn die 7 Wochen, die Du mit der U32-Zahl in der Visa-Konfiguration immerhin vorgeben kanns, wirklich nicht aus?
Bessere Alternative: Timout ca.1 sec, bei Timeout den Fehler abfangen und Lesen so lange in der Schleife wiederholen, bis die gewünschten Daten kommen. Vorteil: Man hat - bei entsprechender Programmierung - die Möglichket des Stops durch Bedieneingriff.

Edit:
Du scheinst nicht zu wissen, daß das Aufsammeln der Stringzeichen mittels Shift-Register in mehreren Schleifendurchläufen nun wirklich eine ganz leichte Übung ist. Brauchst Du dazu ein Beispiel? Und bei Ende des Timeout brauchst Du nicht zu befürchten, daß dabei ein gerade übertragenes Byte zerstört wird.

' schrieb:Dass das Zusammenfügen per Schieberegister eine einfache Sache ist, ist mir schon klar. Aber ich wollte dennoch wissen, ob es eine elegantere Lösung gibt. Aber anscheinend ist das doch die beste Lösung und ich werde das daher wohl so implementieren.

' schrieb:Was auch noch machbar ist, vor dem Read, mit der Property "Byte at Ser.Port" schauen ob Daten anstehen, und dann erst das Read aufrufen.
Somit kannst du das Timeout klein halten und musst nicht Daten mit SR zusammenfügen oder die TimeOut-Meldung zurücksetzen.

' schrieb:Das ist durchaus eine Möglichkeit. Aber einschalten des Termchar und dann mit "kleinen" Timeout lesen erscheint mir nicht so besonders schwierig. Je nach Instrument muss man halt schon mal einen bestimmten Fehler wie den Timeout Fehler filtern. Das ist doch nicht schlimm. Manche Leute hier scheinen einerseits den Error Cluster oft komplett zu vernachlässigen und/oder andererseits eine panische Angst zu haben wenn eine Funktion einen Fehler zurückgibt. Sicher bei Kommunikation mit externen Geräten ist es oft unvermeidbar, dass man manchmal Fehler erhält, die halt nicht wirklich Fehler sind sondern ganz einfach "Expected Behaviour". Filtern dieser Fehler ist dann ganz logisch und sinnvoll.