LabVIEWForum.de

Hallo!
Ich habe folgendes Problem:
Ich erhalte über eine Serielle Schnittstelle einen Stream, der in etwa so aussieht:
Das sind ADC-Werte eines Mikrocontrollers. Um sie zu plotten, durchsuche ich den Stream nach ":" und habe dahinter eine Case-Struktur, die dann je nach Vorterm "Bat", "LightL", "LightR", ... den hinter dem ":" liegenden Wert erst in eine Zahl umwandelt (VI: String nach Zahl).
Diese Zahl wird dann geplottet.

Nun endlich mein Problem: Aus irgendeinem Grund wird immer wieder (sagen wir mal einmal jede Sekunde) die letzte Ziffer meiner "LightL"-Abfrage abgeschnitten, weswegen der Messwert "LightL" z.B. zwischen Werten um 906 immer wieder auf 90 runterspringt...
in meinem Stream, den ich auch im Ganzen darstelle, ist diese Ziffer stets vorhanden.
WARUM?
Lustig ist auch, dass das wirklich nur bei "LightL" passiert und ganz selten mal bei "Bat". Die Abfrage ist aber quasi identisch zu allen anderen Darstellungen!

Danke Euch!
Fabian

Deine Informationen langen für eine fundierte Antwort nicht aus. Und meine Glaskugel ist mal wieder kaputt.

1) Zeig mal den Sourcecode deiner LabVIEW-Leseroutine.
2) Erzähl genau, was für Strings dein Microcontroller sendet. Vor allem, wie sind die einzelnen Werte voneinander getrennt.

Gruß, Jens

P.S.: nach VISA.

Hallo Fabian,

also bei mir wird immer exakt am ":" getrennt:
[attachment=37284]

Ansonsten:
- Ist dein String, den du da parst, immer vollständig?
- Zur Kontrolle kannst du ja auf vollständige Zeilen testen (sprich: Test auf Zeilenende-Zeichen)...

Liest du denn überhaupt zeilenweis aus dem seriellen Empfangspuffer aus? (Serial Config: EndTerm aktivieren).
Wenn Du stattdessen immer nur soundsoviele Byte liest, kannst Du nicht erwarten, daß das letzte gelesene Byte immer das Ende einer Zeile ist. Sehr beliebt ist bei Anfängern auch die unpassende Verwendung von "Bytes on Board" mit anschließendem Auslesen dieser Bytes. Wenn ich das sehe, wird mir immer ganz schlecht

So, hier mal, was ich mache. Nur in der kurzen Form, der Rest ist ja wurst!

Die Abfrage nach dem Zeilenende habe ich jetzt erst hinzugefügt, hat aber nichts geändert am Problem. Eine Kopie des Streams, den ich erhalte, habe ich auch mal angefügt.

Ich versteh es wirklich nicht
Vor allem, weil es wie geasgt nur an einem dieser Werte hakt, nämlich am "LightL"-Wert, alle anderen humpeln nicht ständig herum.

Lg

Hallo fabqu,

wie sagte Lucki schon so schön:

Zitat:Sehr beliebt ist bei Anfängern auch die unpassende Verwendung von "Bytes on Board" mit anschließendem Auslesen dieser Bytes. Wenn ich das sehe, wird mir immer ganz schlecht

- Warum also BytesAtPort?
- Warum bei jeder Iteration den ComPort neu öffnen (VISA-Open)?
- Musst du wirklich ein RTS generieren?
- Musst du wirklich in jeder Iteration die Baudrate neu setzen?
- Wo wird dein COM-Port initialisiert?
- Einfach mal die Threads hier zum Thema "Serieller Port" durchlesen!
- Dein Test auf Zeilenende dürfte nutzlos sein, da du den String "\n" suchst. Du meinst sicher die Konstante LF oder auch "\n" in Slash-Code-Darstellung!

- Aufräumknopf benutzen!
- Wozu die lokalen Variablen, wenn die Terminals ungenutzt herumliegen?

Tschuldigung, bei meinen "Bytes on Board" hatte ich wohl eher den Aufkleber "Baby on Board" im Sinn als die "Bytes at Port" der seriellen Schnittstelle

Ok, Ok, ich sehe ja ein, dass das alles nicht wirklich sauber ist, was ich so tue...
Aber das hat doch alles nix mit dem Problem zu tun, oder?

Denn wie gesagt, der Stream ist da und ist eins-a in Ordnung. Es klappt ja auch wirklich alles, bis auf diese Blöde Ziffer, die mir bei "LightL" immer verschwindet.

Ich versuche das alles umzusetzen, was ihr so geschrieben habt.
Aber wo liegt nun das Problem???

Bau erst einmal die Leseroutine um:
[attachment=37311]
Da dein Mikrocontroller jede Zeile mit einem newline abschließt, solltest du auch immer eine ganze Zeile auf einmal einlesen. Das geht mit der gezeigten Konfiguration der Schnittstelle VOR der Schleife (nicht drinnen) ganz einfach.

Gruß, Jens

Sehr gut, danke dir!
Wird gleich morgen umgesetzt.

Werde mich melden, ob das Problem weiterhin ebsteht!

Vg,
Fabian