letzte Zeile eines Strings anzeigen

Soso, der Anschiss hat gesessen
Also zum Thema:
Ich empfange von einem uC via WLAN, TCP (also nix mit VisaRead und so) meine Daten, wobei der uC diese Daten andauernd sendet und dabei nicht etwa auf meine Synchronisation wartet. Das könnte man vielleicht ändern, ich kann es momentan noch nicht. Auch das asynchrone starten der Programme vom uC und von LabVIEW ist voraussichtlich nicht änderbar.
Daher muss ich mit diesem gegebenen Problemen irgendwie arbeiten!

Das TCP-Protokoll ist aus den NI-Beispielen geklaut und funktioniert mittlerweile ganz gut innerhalb meines restlichen Codes.

Meine Weiterverarbeitung geht laut Anhang (wobei die Version hier grade mal nicht funktioniert).
Alles innerhalb einer Zeile vor dem ":" kommt in die Case-Abfrage, alles nach dem ":" wird als Messwert interpretiert. Im Beispiel hier ists der Batteriemesswert ("Bat"), welcher zur Verrechnung in Volt noch durch 102 geteilt werden muss. Also alles recht einfach.
Das ganze hatte ich vorher in einer seriellen Bluetooth-Lösung (Bluetoothmodul, das ein COM immitiert) und hat super funktioniert (wobei da, wie ihr schon gesagt habt, die Zeilen nur vollständig geladen wurden und auch mit deutlich weniger Daten in gleicher Zeit als jetzt mit WLAN).

Leider klappt die Lösung oben auch nicht Oder mache ich wieder was falsch?

Anzeige

(28.07.2012 11:00 )fabqu schrieb:  Also zum Thema:
Ich empfange von einem uC via WLAN, TCP (also nix mit VisaRead und so) meine Daten, wobei der uC diese Daten andauernd sendet und dabei nicht etwa auf meine Synchronisation wartet. Das könnte man vielleicht ändern, ich kann es momentan noch nicht. Auch das asynchrone starten der Programme vom uC und von LabVIEW ist voraussichtlich nicht änderbar.

Sorry, ich bin von Datenkommunikation über die serielle Schnittstelle ausgegangen. Datenübertragung über TCP habe ich selbst noch nicht gemacht und kann da nicht helfen.
Nur um ein Missverständnis zu klären:
Mit Synchronisation meinte ich nicht, dass irgendein Handshaking mit dem µC stattfindet und die Art und Weise der Übertragung geändert werden soll. Ich ging davon aus, dass der µC kontinuierlich Daten sendet, ohne das er irgendeine Rückmeldung erhält. Es geht nur darum, dass man beim Hineinhören in den Datenstrom zu einem willkürlichen Zeitpunkt erst mal den Anfang des nächsten Datensatzes finden muss, bevor man verwertbare Daten empfängt, die sich aufzuzeichnen lohnen. Das meinte ich mit "Synchronisation"

Das Problem kann doch gar nicht soooo schwer sein! Ich hab doch bestimmt nur nen Wurm im Kopf.
Versuchen wirs anders:
Ich hänge ja alle empfangenen Datenblöcke zusammen zu einem endlosen String.
Wie kann ich die LETZTEN sagen wir 30 Zeilen DIESES Strings Zeile für Zeile untersuchen???

Und warum geht es eigentlich nicht wie unten im Anhang???
In meiner lokalen Variable hänge ich jetzt stets die neusten Daten oben an, also sind die obersten Zeilen stets die aktuellsten.
Dort gehe ich Zeile für Zeile durch, 30 Mal und durchsuche auf ":".
Ich bekomme aber maximal drei verschiedene Werte wie z.B.
"SpeedL" "37"
Wobei er in der folgenden Case-Abfrage dennoch nicht diesen "37" in die Anzeige für "SpeedL" schreibt.
WARUM NICHT???

Mittlerweile habe ich einen wunderschönen String beieinander:

Code:

Bat:887
PowerL:0
PowerR:0
SpeedL:0
SpeedR:0
LightL:928
LightR:944
ADC0_Base:917
ADC1_Base:898
BumpL:0
BumpR:0
ObsR:0
ObsL:0
NUM:00023
Bat:887
PowerL:0
PowerR:0
SpeedL:0
SpeedR:0
LightL:928
LightR:944
ADC0_Base:951
ADC1_Base:968
BumpL:0
BumpR:0
ObsR:0
ObsL:0
NUM:00022
Bat:886
PowerL:0
PowerR:0
SpeedL:0
SpeedR:0
LightL:928
LightR:944
ADC0_Base:932
ADC1_Base:916
BumpL:0
BumpR:0
ObsR:0
ObsL:0
NUM:00021

Genau so sieht er in meiner Variablen "Response" aus.
Den untersuche ich mit einer For-Schleife 20 mal, Zeile für Zeile (siehe Bild vom letzten Beitrag) nach ":".
Aber der einzige Wert, für den das funktioniert, ist der Wert für "LightR".
Warum nur? Alles andere funzt schon. Nur das noch nicht.

Wie man an den Werten sehen kann, wiederholt sich ein Datenblock stets nach "Num:00xxx", wobei "Num:xxxxx" die gerade angesagte Blocknummer ist. Der neueste Block wird stets an den alten String OBEN angehängt.

Hallo Fabian,

hast du meinen Vorschlag mal einer näheren Betrachtung unterzogen?

Zitat:Der neueste Block wird stets an den alten String OBEN angehängt.

Warum machst du denn sowas? Das macht es doch unnötig kompliziert, wenn man ständig im String hin- und herspringt...

- neue Daten hinten (aka UNTEN) anhängen
- Daten von vorn (aka OBEN) zeilenweise auswerten und entfernen(!)
- auch bei TCP/WLAN sollte dein PC solche Strings schneller auswerten können als sie geliefert werden...
- die von Lucki erwähnte Synchronisation ergibt sich dabei sofort nach dem ersten entfernten Zeilenende (bzw. sofort, wenn man man eine Zeile entfernt und beim Auswerten hinterher "verstümmelte" Zeilen verwirft)

Tipp:
Hänge bitte Snippets oder richtige VIs an: man hat nicht immer Lust, ein Bild nachzuprogrammieren, um deine Probleme zu lösen...

---

Edit nach Time-Limit:
Wenn ein kompletter Block immer mit NUM:xxxx beendet (oder auch gestartet) wird, dann trenne doch doch Blöcke aus dem empfangenen Datenstrom ab. Dann kann man z.B. so auswerten:
   
In der FOR-Loop dann deine Case-Struktur zur Behandlung der einzelnen Befehle/Werte...

Anzeige

Welches ist denn das Mittlere der drei String- oder Array-VIs?
Ein solches habe ich nicht (2009er LV-Version)...

Danke dir.
Werde künftig stets ein VI dranhängen, sorry.
Dein VI vom letzten Beitrag (mit dem Queue) habe ich ausprobiert, hat aber nicht geklappt.

Hallo Fabian,

ich bin mir ziemlich sicher, dass es IndexArray auch schon bei LV2009 gab!

Zitat:Dein VI vom letzten Beitrag (mit dem Queue) habe ich ausprobiert, hat aber nicht geklappt.

Ich bin mir auch ziemlich sicher, dass dieses Verfahren funktioniert. Ich verwende es auch bei dem einen und anderen Gerät, welches selbständig Daten sendet...

YEAHHHHHHHHHHHHHHHHHHHHHHHHH



Juhuuu!
Danke dir!!!!!! Danke, danke für die Geduld mit mir, i bin halt manchmal a bissl am Schlauch.

Alles funkzt wie ne 1!

Grüße und a gutes Nächtle.
Fabian

Nochmal zwei Kommentare zu dem TCP IP:

Beim Read könntest du ausprobieren, ob Modus 2 funktioniert:

Code:

2 CRLF—Wartet, bis die unter Zu lesende Bytes angegebenen Byte-Anzahl eingetroffen ist oder bis innerhalb von Zu lesende Bytes ein Wagenrücklauf (CR) gefolgt von einem Zeilenvorschub (LF) auftritt oder bis der Timeout (ms) erreicht ist. Die Funktion gibt die Bytes bis einschließlich CR und LF aus, sofern CR und LF im String gefunden werden.

(aus der LV Hilfe)

Damit könntest du wenn dein Sender im entsprechenden Format Zeilen beendet wirklich Zeilenweise einlesen. Dann könntest du schon beim lesen deine Zeilen trennen und kriegst auch immer nur komplette Zeilen.


Falls das nicht geht (oder zu langsam wird): Ich würde bei sowas immer ne Auswertung vorschalten die in die einzelnen Nachrichten auftrennt (in deinem Fall also die einzelnen Zeilen). Sprich: Der Teilstring den du empfängst wird an den Rest vom letzten Durchlauf angehangen, du trennst nach Zeilen auf, schiebst den Rest (letzte Zeile) in ein Schieberegister und die eigentlichen Daten Zeilenweise in eine Queue. Aus der entnimmt dann ein separates Programm und macht die eigentliche Verarbeitung. Wie schon angemerkt das ganze eventuell um Verlustbehaftetes einfügen ergänzen, wenn wirklich zu viele Daten kommen.

Alternativ entnimmst du der Queue halt bei jedem Durchlauf und arbeitest das Array das du gekriegt hast vom Ende her ab bis du alle notwendigen Werte aktualisiert hast, oder das Array abgearbeit hast.
Anschließend halt wieder nächster Durchlauf.
Die Daten aus der Queue würde ich persönlich anschließend wegschmeißen oder (in ner separaten Schleife) ausschreiben wenn du die loggen willst.

Gruß Kiesch