+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+--- Thema: String-Datensatzverarbeitung (/Thread-String-Datensatzverarbeitung)
String-Datensatzverarbeitung - ExXeQtor - 06.02.2014 15:03
Hallo, ich bin zwar inzwischen relativ LabView eingearbeitet, habe aber mit der Stringerarbeitung noch recht wenig erfahrung.
Ich habe nun ein VI laufen, das Daten von der seriellen Schnittstelle ausliest und in einen Stringpuffer schreibt. Der Inhalt des Puffers (ein String) sieht dann z.B. so aus:
Configuration finished. Leaving Config-Mode.
Module;Channel;Wavelength;Speedmode;ADC-Value;Timer-Value;
[0-3];[0-3];[0:750nm, 1:850nm];[1:on, 0:off];[16Bit HEX, *5/2^16];[16Bit HEX, 1/100s];
M0;C2;L1;S0;0D2D;05C4;
M0;C0;L0;S0;1817;05CB;
M0;C0;L1;S0;16DE;05D2;
M0;C1;L0;S0;11F5;05DA;
M0;C1;L1;S0;0EA8;05E1;
M0;C0;L0;S0;0DB8;05E8;
M0;C0;L1;S0;0DE3;05F0;
Speedmode On
M0;C1;L0;S1;0E1B;05F7;
M0;C1;L1;S1;0E4D;05FE;
Nun muss man noch dazu sagen, was hier nicht angezeigt wird: Jeder Absatz wird durch CR + LF gekennzeichnet (in ebender Reihenfolge).
Was ich tun möchte ist nun eigentlich relativ simpel: Die Datensätze (Zeilen) bestehen aus Header - z.B. "M0,C2;L1;S0;" und Hex-Daten "0D2D;05C4". Der Header gibt Modulnummer (M), Channelnummer ©, Lambda (L) und Speedmode (S) an. Ich würde nun gerne aus jeder vollständigen Zeile ein Cluster machen, das die Informationen und Daten trägt.
Alle anderen Zeilen mit Informationen (z.B: "Speedmode On") sollen ignoriert werden.
Mein Problem ist, dass ich nicht genau weiß wie das nun am besten zu bewerkstelligen ist, denn: Der Stringpuffer muss ja nicht zwangsweise ganze vielfache einer Zeile beinhalten (da kommt ja immer wieder etwas dazu).
Könnte mir da jemand kurze Hinweise oder Beispiele geben, wie ich den Puffer von vorne (d.h. älteste Daten zu erst) in vollständigen Zeilen auslesen und verarbeiten könnte? Hinten werdem ja laufend neue Daten angehängt. Der Rest ist in einer Queued State Machine implementiert, es sollte also alles darumherum bereits "optimal" laufen.
Viele Grüße und besten Dank!!
Alexander
RE: String-Datensatzverarbeitung - GerdW - 06.02.2014 15:13
Hallo exxeqtor,
mal eine Idee:
[attachment=48407]
Zitat:Jeder Absatz wird durch CR + LF gekennzeichnetDann lässt man das (voreingestellte) LF als TermChar aktiv und bekommt so schön eine Zeile nach der anderen vom SerialRead geliefert…
Zitat:Der Stringpuffer muss ja nicht zwangsweise ganze vielfache einer Zeile beinhaltenDoch, muss er. Wenn man das TermChar nutzt…
RE: String-Datensatzverarbeitung - ExXeQtor - 06.02.2014 15:17
Hallo Gerd,
herzlichen Dank - das probiere ich sofort mal aus!
Zitat:Jeder Absatz wird durch CR + LF gekennzeichnet
Dann lässt man das (voreingestellte) LF als TermChar aktiv und bekommt so schön eine Zeile nach der anderen vom SerialRead geliefert…
Da allerdings bin ich mir noch nicht ganz sicher ob das bei meiner Umsetzung auch so funktioniert: Derzeit überprüfe ich den Property Node "Bytes at Port" auf 0 - und lese wenn !=0 die angezeigte Anzahl Bytes über den VISA Serial Read Baustein aus. Das wäre aber ja dann nciht immer Zeilenweise. Was muss ich tun, damit ich immer nach LF eine Zeile bekomme? Den Bytecount nicht angeben (offen lassen)?
Viele Grüße
RE: String-Datensatzverarbeitung - GerdW - 06.02.2014 15:27
Hallo Alexander,
das wurde hier schon so oft erläutert, gefühlt jeden zweiten Tag…
Man stellt das TermChar passend ein, bei dir LF (wie default), und aktiviert es (ebenfalls default beim SerialPortInit). Dann liest man einfach mit VISARead und gibt eine "utopisch" hohe Zahl an Bytes vor (bei dir z.B. "100"). Denn VISARead stoppt, wenn
- die gewünschte Anzahl Bytes im Puffer vorhanden ist
- das TermChar im Puffer vorkommt (!)
- oder der TimeOut eintritt
Probier's mal aus!
Zum Bild:
- Von der Programmierung her schon sehr schön!
- Du könntest noch etwas mehr auf gerade Drahtführung achten, das erhöht die Übersichtlichkeit. Drähte hinter Strukturen zu verstecken ist auch nicht so gut. Die Queue könntest du z.B. durch den Case hindurch verdrahten, dann brauchst du den Draht hinter der Casestruktur nicht…
- Wenn du ein FALSE aus dem Case ausgibst, dann wird in einem anderen Case wahrscheinlich ein TRUE ausgegeben. Du könntest dann auf die FALSE-Konstante verzichten und den Tunnel auf "Default if unwired" setzen…
RE: String-Datensatzverarbeitung - ExXeQtor - 06.02.2014 15:29
Wunderbar, dankesehr!