Pufferüberlauf bei serieller Kommunikation

Hallo!

Ich bin momentan dabei, mir Amplitudenwerte aus einem Spektrumanalyzer ausgeben zu lassen und diese dann graphisch darzustellen.

Jetzt bin ich auf folgendes Problem gestoßen: Wenn mein Programm eine Weile läuft, kommt eine Fehlermeldung, dass das nächste Zeichen bereits da ist, bevor das letzte gelesen werden konnte (sinngemäß). In der Sondenüberwachung zeigt sich nun, dass der Puffer nach und nach vollläuft, bis er die bei der Initialisierung eingetragenen 512 kB überschreitet.

Ich habe jetzt schon mal versucht, den Puffer zwischendurch zu leeren, allerdings kriege ich die "Reihenfolge" nicht so wirklich hin, da er mir dann auch meine ausgelesenen Werte gleich verwirft. (Deswegen hängt das "Puffer leeren" momentan einfach oben in der Ecke).

Anbei der entsprechende Ausschnitt aus meinem VI.

Hoffe, es kann mir (wieder mal) jemand helfen.

   

Anzeige

Hallo Yantit,

vielleicht solltest du den "Receive buffer" löschen anstatt den "Transmit buffer" wie bisher? D.h. eine 64 statt der 128 an VISA Flush anschließen!
Edit: Alternativ könntest du auch die komplette Antwort deines Analyzers lesen, so würde der Puffer erst gar nicht volllaufen...

Weitere Hinweise:
Aufräumen mit dem Button in der Menüzeile täte auch gut. Die beiden X-Achse-Properties kann man zu einer zusammenfassen, dann benötigt man auch nicht 2 Drähte für die Referenz und zwei Tunnel in die Schleife rein. Die ganzen CoercionDots tauchen gar nicht erst auf, wenn man Konstanten/Controls/Indicator per Rechtsklick erzeugt... Konstante (Rechen-)Operationen außerhalb von Schleifen erledigen. Warum setzt du bei jedem Schleifendurchlauf die X-Achse auf's Neue mit augenscheinlich immer den gleichen Werten - würde nicht einmal vor der Schleife ausreichen? Du hast den ErrorCluster nicht verdrahtet und ausgewertet... Mach dir eine Wartefunktion mit durchgeführtem ErrorCluster, dann brauchst du keine Sequenzstruktur mehr.

' schrieb:Hallo Yantit,

vielleicht solltest du den "Receive buffer" löschen anstatt den "Transmit buffer" wie bisher? D.h. eine 64 statt der 128 an VISA Flush anschließen!

Die Hilfe bin ich auch schon mehrfach durchgegangen, allerdings (wie bereits erwähnt), verwirft mir das Programm beim Leeren des Empfangspuffers meine ausgelesenen Werte. Ich habe auch versucht, mit Verzögerungen innerhalb der Sequenz zu arbeiten, jedoch ohne Erfolg. Daher rührte auch meine Frage bezüglich der Reihenfolge...

Weitere Hinweise:
Aufräumen mit dem Button in der Menüzeile täte auch gut. Die beiden X-Achse-Properties kann man zu einer zusammenfassen, dann benötigt man auch nicht 2 Drähte für die Referenz und zwei Tunnel in die Schleife rein. Die ganzen CoercionDots tauchen gar nicht erst auf, wenn man Konstanten/Controls/Indicator per Rechtsklick erzeugt...

Jep, stimmt wohl. Mit dem Aufräumen werde ich mich dann befassen, wenn das Programm sauber länger als eine viertel Stunde durchläuft, ^_^damit wäre mir nämlich schon sehr geholfen, weil das als Monitoring-System für 24/7-Betrieb ausgelegt werden soll...

Noch ein Tip: Soweit ich das sehen kann ändert sich an der Berechnung von f0 und df nix. Auch Min/Max der x-Achse ändert sich nicht zur Laufzeit. Also: Raus mit dem Kram (raus aus der Schleife...)!! Das hat nix in der Schleife verloren. Die Eigenschaftsknoten sind dazu elend langsam. In einer zeitkritischen Schleife solltest du nur das Nötigste drin haben.

Und um so eine Unordnung in ein BD zu hinzubekommen muss man sich schon echt Mühe geben ...

' schrieb:Jep, stimmt wohl. Mit dem Aufräumen werde ich mich dann befassen, wenn das Programm sauber länger als eine viertel Stunde durchläuft, ^_^damit wäre mir nämlich schon sehr geholfen,

Dir wäre sehr geholfen, wenn du direkt sauber programmierst.

Hallo Yantit,

das Aufräumen erfordert nur einen einzigen (!) Klick - und erleichtert es anderen ungemein, deine VIs zu "lesen"!
Wenn du Hilfe von anderen erwartest, solltest du auch einen gewissen "Respekt" durch ein aufgeräumtes BD zeigen...
(Ein Lob von mir für das Einstellen eines Snippets, da ich nicht immer an einem Rechner mit installiertem LabVIEW sitze und so trotzdem auf den Code schauen kann. Aufgeräumt wäre natürlich schöner)

Siehe auch die editierten Hinweise oben...

Okay, ich werde jetzt erstmal die Schleife bereinigen und dann ein (hoffentlich aufgeräumtes) Snippet hochladen..

Anzeige

Hallo Yantit,

bei den Funktionen zur seriellen Schnittstelle findest du auch eine, die dir mitteilt, wieviele Bytes im Buffer liegen. Damit könntest du herausfinden, wie groß die Antwort deines Analyzers ist, um sie dann komplett zu lesen...

Wie kommst Du überhaupt darauf, 5000 bytes auszulesen? Wenn z.B. Nach jeder Sendeanforderung 6000 bytes kommen aber nur 5000 gelesen werden dann ist unvermeidlich, daß der Buffer sich immer mehr füllt.
(Ich vermisse auch jegliche Konfiguration der Schnittstelle).

Eine primitive, aber immerhin gangbare Möglichkeit ist: Nach der Sendeaufforderung genügend lange warten, bis die Antwort fertig ist. Dann Die Anzahl der Bytes im Buffer bestimmen und diese Anzahl auslesen. Dann kann der Buffer nie überlaufen. (Primitiv deshalb, weil ich Waits in so einem Kommunikationsdialog nicht mag)
Nach besser ist allerdings, wenn die Gegenstelle ein Abschlusszeichen (TermChar) senden würde. Das ist die beste Art des Dialogs. (Einziger Nachteil: Gesendete Bytes müssen ASCII-Codiert sein, es kann nicht einfach der Bytewert 1 gesendet werden, sondern immer die zweistellige ASCII- HEX- Zeichenkette "01". Das scheint aber bei Dir der Fall zu sein)

So, hier jetzt mal die optisch etwas aufbereitete Version:

   

' schrieb:Wie kommst Du überhaupt darauf, 5000 bytes auszulesen? Wenn z.B. Nach jeder Sendeanforderung 6000 bytes kommen aber nur 5000 gelesen werden dann ist unvermeidlich, daß der Buffer sich immer mehr füllt.
(Ich vermisse auch jegliche Konfiguration der Schnittstelle).

Eine primitive, aber immerhin gangbare Möglichkeit ist: Nach der Sendeaufforderung genügend lange warten, bis die Antwort fertig ist. Dann Die Anzahl der Bytes im Buffer bestimmen und diese Anzahl auslesen. Dann kann der Buffer nie überlaufen. (Primitiv deshalb, weil ich Waits in so einem Kommunikationsdialog nicht mag)
Nach besser ist allerdings, wenn die Gegenstelle ein Abschlusszeichen (TermChar) senden würde. Das ist die beste Art des Dialogs. (Einziger Nachteil: Gesendete Bytes müssen ASCII-Codiert sein, es kann nicht einfach der Bytewert 1 gesendet werden, sondern immer die zweistellige ASCII- HEX- Zeichenkette "01". Das scheint aber bei Dir der Fall zu sein)

Die Schnittstelle wird vorher in einem eigenen Sub-Vi konfiguriert, da darüber auch die Initialisierung läuft. 5000 Bytes lese ich aus, weil ca. 4600 Bytes pro Sendeanforderung auflaufen (wurde vorher geprüft).
Leider sendet der Analyzer kein Abschlusszeichen, das wäre natürlich eine elegante Lösung...