Pufferüberlauf bei serieller Kommunikation

' schrieb:Langsam frage ich mich echt, woran das denn jetzt konkret liegen könnte...

Ziemlich spät, meiner bescheidenen Meinung nach!

Wie schon anderswo angesprochen ist es wirklich fraglich ob das Gerät so antwortet wie Du es Dir vorstellst. Zurst mal die Tatsache dass das Gerät kein Endezeichen zu haben scheint. Da Du zu Beginn 5000 Bytes lesen wolltest aber nur 4400 und etwas rein kam hättest Du da jeweils ein Timeoutfehler kriegen müssen. Da das scheinbar nicht reinkam, müsste doch irgendwie ein Endezeichen sein. Auch zeigst Du die Initialisierung der Schnittstelle nicht, so dass man nicht sieht ob Du die Endezeichenkonfiguration wirklich ausschaltest (die ist bei Serial VISA Default eingeschaltet und auf Line Feed eingestellt). Und Dein Filterstring hat ja eindeutig ein rn am Ende und das ist anders dann der n den Du schickst, also ist die Aussage dass das Gerät kein Endezeichen zurücksendet schlichtweg falsch! Tut es eben schon und scheinbar sendet es jedes Kommand als Echo zurück und danach die eigentlichen Daten als seperate Zeile.

Der einzige mir logische erscheinende Grund dass Du einen Bufferüberlauf bekommst, wäre dass das Instrument nicht einfach antwortet wenn es ein Kommando bekommt sondern konstant Datentelegramme ausspuckt. Dein VISA Read liest dann jeweils ein solches Telegramm und wartet danach 500 ms bevor es die nächste Loop startet. In der Zwischenzeit spuckt Dein Gerät weitere Telegramme aus und beim nächsten Schlaufendurchlauf liest Du dann das nächste Telegramm ein, was inzwischen schon alt ist.

Das grosse Rätsel ist noch warum das Flush Buffer in Deinem Post #12 diesen Umstand nicht verhindert. Hast Du schon mal versucht mit dem Wert 16 statt 64?

Und zu guter Letzt: Der Error Cluster ist nicht nur zum Spass vorhanden. Zu einer guten Gerätekommunikation gehort auch Fehlerbehandlung. Du solltest den Error Cluster zumindest durch alle VISA Funktionen durchschlaufen und am Ende auf dem Frontpanel darstellen. Dann bekommst Du zumindest eine Idee wenn etwas falsch geht. Ein guter Treiber zeigt aber nicht nur alle Fehler an sondern versucht auch an geeigneten Stellen bestimmte Fehler zu erkennen und ein Retry oder andere geeignete Massnahmen zu treffen um den Fehler zu beheben.

Notiz: Dass Du zu Beginn einen Bufferüberlauf bekamst ist gar nicht verwunderlich. Du sendest ein Kommando und das Gerät antwortet mit zwei Zeilen: Die erste ist das Echo des Kommandos und die zweite ist der Datenstring. Aber Du liest immer nur eine Zeile pro Schlaufe aus (da Du die Endezeichenbehandlung von VISA mit 99.9999% Sicherheit eben nicht ausgeschaltet hast. Also sendest Du in jeder Schlaufe ein Kommando und liest nur in jedem zweiten Durchgang die eigentlichen Daten. Dass da einiges and Daten ansammelt im Laufe der Zeit sollte ja logisch sein. Und jetzt bitte nicht die Endezeichenbehandlung von VISA ausschalten, das wäre wirklich das Pferd am Schwanz aufzäumen. Anstelle davon machst Du am Anfang (vor der Schalufe ein Flush mit 196 um beide Buffer komplett zu leeren) und danach in der Schlaufe erst ein VISA Read mit etwa 100 als Characters to Read um das Kommandoecho zu lesen und wenn Du das Echo des Kommandos detektierst (Dein Gleichzeichen mit dem String) noch einmal ein VISA Read, aber diesmal mit 5000 Charactern und das sind Deine Daten und wenn das Kommandoecho nicht stimmst machst Du ein Flush im anderen Case.