Überlauffehler bei serieller Schnittstelle

Hallo Dominik,

Zitat:Ich habe weiterhin das Problem, dass der "Lesepuffer 2" beim durchlaufen der VI fehlende Bytes hat. Beim "Wiederholt ausführen" tritt dieser Effekt wieder nicht auf. Was mir noch aufgefallen ist, der Schlussteil der zu lesenden Daten ist vorhanden, anscheinend wird (wenn Daten fehlen) immer ein Teil der vorderen Bytes abgeschnitten. Dies passiert aber auch willkürlich, mal weniger Daten mal mehr Daten.

1. VISARead bricht ab, wenn ein TermChar empfangen wird, bei dir ist das ein LineFeed.
2. Man sollte mehr Bytes abfragen als man zu lesen beabsichtigt: wenn deine Botschaft 31 Zeichen (inkl. oder exkl. LineFeed?) enthält, dann solltest du eben 49 Zeichen abfragen! VISARead beendet das Lesen ja sowieso, sobald das TermChar empfangen wird!
3. Zwischendrin den Lesebuffer zu löschen, insbesondere bei "wiederholter Ausführung", ist extrem störend, wenn man Daten zuverlässig empfangen will!
4. "Wiederholte Ausführung" ist nur zum Debuggen - aber hier bei Abfrage der seriellen Schnittstelle nicht hilfreich!
5. Wenn du dein VI mehrfach ausführst, solltest du nicht andauernd den COM-Port neu initialisieren.
6. Wenn man einen Port öffnet, dann sollte man ihn auch wieder schließen - machst du aber nicht!

Beispiel:
   

Anzeige

Ich komme leider mit dem Problem nicht wirklich weiter. Habe dabei schon die Vorschläge probiert.
Außerdem habe ich jetzt versucht einen anderen Adapter (USB-Seriell) zu verwenden, das Problem mit dem Überlauffehler bleibt aber bestehen.
Deswegen habe ich das VI jetzt noch deutlich vereinfacht und ich versuche nur die Schnittstelle auszulesen.
Dabei kann ich jetzt feststellen, dass das VI die ersten 1-3 Durchläufe nicht richtig funktioniert, das heißt zu wenige Daten ausliest. Danach funktioniert es komischerweise immer richtig.
Der Fehler tritt dann erst wieder auf, wenn LabView komplett geschlossen und neugestartet wird. Dann habe ich beim Durchlauf des VI wieder die Probleme.
Kann sich jemand vorstellen, woher dieser Fehler noch kommen könnte?

Aktivierung "Termination Char" und Lesen einer festen Menge von Zeichen, das hat noch nie so richtig funktioniert. Die Logik bei VISA Read ist dann nämlich:

Lies max. 49 Zeichen, aber nur solange, bis der Termination Char erkannt ist.

Wenn deine Gegenstelle unaufgefordert Meldungen verschickt, dann hast du in den allermeisten Fällen beim ersten Lesen nicht genügend Zeichen, denn du weisst ja nicht, wann du das Lesen beginnst. Mit hoher Wahrscheinlichkeit mitten im Stream. Der erste Datensatz wird also zu kurz sein. Ab dem zweiten Lesen sollte dann aber alles passen - gesetzt den Fall dass du nicht dauernd die Schnittstelle schließt und wieder neu initialisierst.

Gruß, Jens

Voraussetzung, daß das alles wie gedacht funktioniert, ist natürlich, dass die Übertragung noch dem Master-Slave-Prinzip erfolgt. Der Slave (das angeschlossene Gerät) darf nur nach Aufforderung des Masters (dem PC) antworten. Niemals darf der Slave ohne Aufforderung etwas senden.
Dem Verdacht von Jens, dass das Gerät vielleicht auch ohne Aufforderung etwas sendet, solltest Du nachgehen. Das ist ja leicht zu prüfen.
Um Dir qualifiziert helfen zu können, könnte auch ein Posting der Schnittstellenbeschreibung deiner "Auswerteelektronik" hilfreich sein.

Vielleicht kann ich hier auch was zu beitragen, da ich gerade (phänomenologisch) das gleiche Fehlerbild sehe:

Ich habe eine Gegenstelle, die (soweit das Manual und das Leseverhalten nahelegt) unaufgefordert sendet. Das führt teilweise dazu dass ich mitten im Stream beginne zu empfangen und beim zweiten Lesen dann zum Teil einen Überlauf kriege (keine Ahnung ob die Gegenstelle auf das erste Lesen regelmäßig beginnt zu senden oder wo genau der Überlauf auftritt).

Es scheint allerdings so zu sein, dass nach dem initialen Fehler (der nicht jedes Mal auftritt) bei weiterem Abfragen der Schnittstelle der Fehler im folgenden vermieden wird (wiederholt ausführen meines TestVIs führte zu keinen weiteren Fehlern). Ich muss also scheinbar die Daten nur schnell genug abholen dann ist für meine Zwecke alles gut.
Für meinen Fall würde ich wahrscheinlich den initialen Fehler ignorieren (es sei denn er tritt wiederholt beim Lesen auf), da im Lesen direkt nach dem Fehler alles beginnt "richtig" zu laufen. Ich werd aber eventuell auch mal schauen ob sich das Auftreten des Fehlers irgendwie vermeiden lässt (Buffer leeren etc. wäre eventuell auch mein Ansatz).

Gruß Kiesch