Ende von VISA Read

Sali allerseits

Ich habe folgendes Problem: Ich erwarte auf der seriellen Schnittstelle ein Kommando beliebiger aber definierter maximaler Länge, welches mit einem Endzeichen abgeschlossen ist und zu einem beliebigen Zeitpunkt eintreffen kann. Dies liesse sich ganz einfach realisieren, wenn ich bei der Konfiguration der VISA-Schnittstelle das Timeout deaktivieren könnte. Mir scheint jedoch, dass dies nicht möglich ist. Bleibt also wirklich nur die Möglichkeit, die Daten byteweise einzulesen, in einem Schieberegister aneinander zu hängen und manuell auf das Endzeichen zu überprüfen?

Grüsse
Roman

Anzeige

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

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

Das verstehe ich nun nicht ganz. Das Kommando, welches ich erhalte, folgt nicht etwa auf einen Befehl hin, sondern zu einem beliebigen Zeitpunkt, nämlich wenn ein Benutzer eine Taste drückt. Das heisst, das VISA Read wird einfach mal irgendwann, in diesem Falle zu Programmbeginn, ausgeführt und irgendwann tritt dann das Timeout ein, wenn bis dahin noch nicht das Endzeichen empfangen wurde. 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. Oder sehe ich das falsch, und der Timeoutcounter wird bei Datenempfang zurückgesetzt und in der Folge tritt gar nie ein Timeout während dem Empfang von Daten auf?

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:

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

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.

Im Timeout-Fall Daten im Schieberegister mit String anhängen sammeln. Falls also kein Timeout Fehler kommt - Daten des Schieberegisters auswerten und leeren.

Vergiss alles bisher Gesagte, es gibt was Besseres.
Du aktivierst in der Konfiguration das Visa-Ereignis "Termchar" (Endezeichen) und wartest dann in einer Schleife auf das Ereignis. Bei Timeout wird erneut gewartet. Wenn es da ist, wird die Schleife verlassen und dann erst kommt VisaRead zum Zuge. Dann liest Du den String aus - fertig.

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

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.

Danke euch.

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

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

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.

Rolf Kalbermatter

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

Das ist durchaus auch eine Möglichkeit
Ich finde auch, dass dies nicht schwierig ist und auch nicht schlimm, und bei mir hat jedes VI Error In/Out, auch wenn das VI gar keinen Fehler generieren kann. (Datenfluss)

Ich finde den TimeOut Fehler aber noch nützlich, um z.Bsp. eine Meldung auszugeben. (Ist das Kabel gesteckt?)
Ok, in dem Poster-Problem nützt das vermutlich nichts, da nicht bekannt ist, wann Daten kommen sollten.

Ich meinte auch bei meinem Vorschlag, dass der Termchar eingeschaltet ist, hätte ich schreiben sollen.