2Byte Wert "aufteilen" und auslesen

(19.11.2013 17:26 )jg schrieb:  Deshalb die folgende plausible Vermutung:
Deine Gegenstelle sendet unaufgefordert ihre Messwerte. Mglw. werden immer alle Messkanäle als 1 langer Block gesendet, wobei die Blöcke durch die erwähnten 3 0x0 Bytes getrennt werden.

Genau so ist es.

(19.11.2013 17:26 )jg schrieb:  Das ist aber noch nicht alles. Wenn man mitten in einen laufenden Datenstrom hineinhört, dann beginnt das Lesen nicht nur mit dem womöglich falschem Byte. Das Lesen kann sogar mitten ein einem der seriell übertragenen Bytes beginnen. Man muß also zu allererst so lange 1-Byte-weise Lesen, bis kein "Rahmenfehler" mehr auftritt.
Man sollte auch mal darauf hinweisen, dass Daten über die seriellen Schnitstelle normalerweise im ASCII-Format übertragen werden. Man braucht dann allerdings für jedes Datenbyte einen String von 2 Byte Länge, also z.B. für den Wert "255" den zweistelligen Srring "FF". Dafür fällt aber der ganze Shit mit Synchronisation-Bytes und Parsen weg. Ein Datensatz wird dann einfach mit dem Zeilenendezeichen abgeschlossen, das genügt zur Synchronisation.
In hier in diesem Fall bringt die direkte Übertragung von Datenbytes sogar überhaupt nichts: Es werden jetzt pro Datensatz 5 Bytes übertragen (3 Synchronisationsbytes und 2 Datenbytes). Eine ASCII-Übertragung würde auch nur 5 Bytes brauchen (1 Byte Kanal-Nr, 3 Bytes Daten, 1 Bytes Zeilenende)
Bei der Direkt-Byte-Übertragung gibt es immer das Problem, dass das Synchronisationsmuster nicht in den Daten vorkommen darf. Das könnte man hier dadurch erreichen, dass man die KanalNr. "0" nicht verwendet. Ansonsten könnte es passieren, dass bei gleichzeitigem Dateninhalt = 0 mehr als 3 Byte den Wert 0 haben und die Start-Markierung nicht eindeutig ist.
Das "Experimental-Board" hast Du doch selbst programmiert, nehme ich an. Was hindert Dich daran, auf ASCII-Format umzusteigen?

puh okay, da merke ich wieder, dass ich nicht so sehr mit der Materie vertraut bin wie ich es vlt. schon gerne wäre.
ich hatte das so verstanden, dass auch im Moment eine ASCII-Übertragung vorliegt und ich aber den ASCII-String mit "String to Byte-Array" konvertiere. Das Board wurde mir so gestellt.
Innerhalb einer Schleife müsste ich ja dann eine Bedingung erzeugen welche prüft, ob 3x 0x00 hintereinander kommt, und wenn nicht, das nächste Byte abgewartet wird um den gesamten String dann wieder daurauf zu untersuchen, stimmt das? Wie das funktioniert ist dann wieder eine andere Baustelle

Anzeige

Hallo jg

(19.11.2013 17:26 )jg schrieb:  Prinzipiell musst du die Schnittstelle öffen, in einer Schleife andauernd die anliegenden Bytes auslesen und solange zu einem String zusammensetzen und analysieren (Stichwort Schieberegister), bis du auf das Synchronisationsmuster "3x 0x0" triffst. Jetzt muss das nächste Byte im Stream untersucht werden. Ist es ungleich 0x0, dann ist es das erste Byte einer Kanal-Info, falls es dagegen 0x0 lautet, dann war es das letzte Byte eines Trennblocks und das darauffolgende Byte muss das erste Byte einer Kanal-Info sein.

Wie der "prinzipielle" Ablauf ist, ist mir klar.

Wenn ich die anliegenden Bytes innerhalb der Schleife andauernd auslese und mir die Werte der einzelnen Bytes anschaue (über Array dezimieren?!). Bsp:
Byte1: 0000 0000
Byte2: 0000 0000
Byte3: 0001 0000
Byte4: 1011 0101
Byte5: 0000 0000

dann sehe ich das beispielsweise so.
Wenn das bis hierhin richtig ist, muss ich jetzt innerhalb der Schleife irgendwas machen, dass geprüft wird, ob 3 aufeinanderfolgende Bytes 0x0 entsprechen. Ist dies nicht der Fall muss ich dann die vorliegenden Bytes "eins weiter schieben" und in das Schieberegister geben welches meine Werte wieder an den Anfang der Schleife übergibt und solange überprüft, bis man auf das Muster "3x 0x0" trifft.

Bei der Bedingung welche in der Schleife geprüft werden muss häng ich.

Ist die Grundlage so wie im Anhang ok (rechts unten)?

Vielen Dank
redhand

Edit: bzw so wie in Wegmessung UART2, kann mir zwar kaum vorstellen das es so umsetzbar ist, aber kann man mit der Logik evtl. etwas anfangen?

Hallo Redhand,

Zitat:Ist dies nicht der Fall muss ich dann die vorliegenden Bytes "eins weiter schieben" und in das Schieberegister geben welches meine Werte wieder an den Anfang der Schleife übergibt und solange überprüft, bis man auf das Muster "3x 0x0" trifft. Bei der Bedingung welche in der Schleife geprüft werden muss häng ich.

Im VI gibt es keine Schleife und kein Schieberegister! Stattdessen immer wieder dieses unsinnige DecimateArray...

Du erhälst einen Bytestrom der Form "abcdefg..." (jeder Buchstabe ein Byte). In diesem Strom suchst du nach "000". Also musst du neue Bytes an die vorhandenen anhängen (ConcatString und Schieberegister) und per MatchPattern einfach nach "000" (Hex-Darstellung beachten!) suchen.

Beispiel:
- Du hast "ab000g" im Schieberegister.
- MatchPattern liefert "000" an Index=2, außerdem die Zeichen davor ("ab", deine gesuchten Daten) und die Zeichen danach ("g", im Schieberegister aufheben und mit den nächsten Daten zusammenhängen).

So sieht das grob aus:
   
(Du musst noch Fehlerhandling, z.B. für nicht gefundenen Teilstring, ergänzen!)

Hallo Gerd,

(20.11.2013 13:13 )GerdW schrieb:  Im VI gibt es keine Schleife und kein Schieberegister!

Das war nur auf die Antwort von jg bezogen.

(20.11.2013 13:13 )GerdW schrieb:  Du erhälst einen Bytestrom der Form "abcdefg..." (jeder Buchstabe ein Byte). In diesem Strom suchst du nach "000". Also musst du neue Bytes an die vorhandenen anhängen (ConcatString und Schieberegister) und per MatchPattern einfach nach "000" (Hex-Darstellung beachten!) suchen.

Beispiel:
- Du hast "ab000g" im Schieberegister.
- MatchPattern liefert "000" an Index=2, außerdem die Zeichen davor ("ab", deine gesuchten Daten) und die Zeichen danach ("g", im Schieberegister aufheben und mit den nächsten Daten zusammenhängen).

Vielen Dank für den Tipp MatchPattern!
Ich habe es mal in mein VI integriert, jedoch ohne Erfolg :/ es stellt sich wieder komplizierter dar als ich zunächst gedacht habe
Ich bekomme weder für den übereinstimmenden Teilstring noch für den "Vor Teil-String" eine nützliche Ausgabe (wie ich den String auch umkonvertiere) :/
Hast du eine Vermutung warum es so nicht funktioniert?

Hallo redhand,

THINK DATAFLOW!
Was soll der Blödsinn mit einer endlos laufenden Schleife, die immer wieder die selben Werte (da außerhalb der Schleife gelesen) verarbeiten soll?
Habe ich das in dem Snippet oben so gezeigt?

Außerdem hilft es immer, sich die Hilfe zu einer Funktion durchzulesen - dann hättest du auch meinen Lapsus mit den Slash/Backslash bemerkt.
Dann funktioniert nämlich auch die Suche:
   

Hallo Gerd,

ich habe noch eine Frage zu "Match Pattern" und "Vor Teil-String" bzw "Nach Teil-String".
Der ankommende String setzt sich folgendermaßen zusammen:
Beispiel (Hex): 15F2 00
15F2 entspricht den auszuwertenden Daten
00 ist der Synchronisationsteil
Außerdem: In "Visa lesen" habe ich bei Byte-Anzahl 3 eingetragen

Das Problem:

Das die Daten richtig ausgelesen werden können, sollten sie schon zusammen weitergeleitet werden.
Also der "Vor Teil-String" sollte eigenlich immer den String, der aus 4Zeichen besteht, beinhalten.
Dies ist nicht der Fall, was ich nicht verstehe, denn der gesendete String hat immer das gleiche Schema.
Bsp.: 15F2 00 15F3 00 15F0 00 15FF 00
Dann müsste ja im "Vor Teil-String" ja eigentlich immer die richtigen Daten stehen oder sehe ich das falsch?

Im Bild habe ich die anderen Zustände die vorkommen zusammengestellt.
WICHTIG: Der Synchronisationsteil im Bild ist 01!!
Die "falschen" Zustände wiederholen sich immer nach einigen "richtigen".

gruß redhand

Anzeige

Wie ist denn der aktuelle Stand deines VIs? Screenshots vom Frontpanel und deine Erklärungen lassen nur Spekulationen zu. Also VI Upload.

Gruß, Jens

hier das VI:
-der Synchronisationsteil ist 01
-Case 2-6 ist noch leer, da wenn ich was ändere, ich das nicht immer in 6-facher Ausführung machen will

Bist du sicher, dass du das VI, das zu deinen Screenshots passt, hochgeladen hast?
In deinem VI hast du als Match-Pattern-String \01 (String in Normaldarstellung, in Hex ist das 0x5C3031) eingetragen, in deinen Screenshots sieht es so aus, als ob du nach dem String 0x01 (in Hex-Darstellung) suchst.

Wieso öffnest und schließt du dauernd die Schnittstelle in der Schleife? Damit können dir Bytes verloren gehen?

Wieso suchst du laut Screenshots jetzt nach 0x01? Bisher lautete die Info, dass nach einer Kanal-Info 3 0x0 Bytes kommen. Liest man deinen vorletzten Beitrag, dann sieht es so aus, als ob nur 1 0x0 Byte zwischen Kanal-Infos steht. Was denn nun?

Gruß, Jens

Vielen Dank für die minutenschnellen Antworten!

(28.11.2013 10:51 )jg schrieb:  Bist du sicher, dass du das VI, das zu deinen Screenshots passt, hochgeladen hast?
In deinem VI hast du als Match-Pattern-String \01 (String in Normaldarstellung, in Hex ist das 0x5C3031) eingetragen, in deinen Screenshots sieht es so aus, als ob du nach dem String 0x01 (in Hex-Darstellung) suchst.

ja, eigentlich schon
das der Match-Pattern-String nicht in Hexdarstellung eingestellt ist habe ich garnicht bemerkt. Warum es doch funktioniert hat ->

(28.11.2013 10:51 )jg schrieb:  Wieso öffnest und schließt du dauernd die Schnittstelle in der Schleife? Damit können dir Bytes verloren gehen?

Dann sollte ich das wohl lieber lassen Danke! Aber wieso genau würde das passieren?
[/quote]

(28.11.2013 10:51 )jg schrieb:  Wieso suchst du laut Screenshots jetzt nach 0x01? Bisher lautete die Info, dass nach einer Kanal-Info 3 0x0 Bytes kommen. Liest man deinen vorletzten Beitrag, dann sieht es so aus, als ob nur 1 0x0 Byte zwischen Kanal-Infos steht. Was denn nun?

Ein Synchronisationsbyte reicht ja aus, dann kann man sich die anderen zwei sparen.
Im Moment ist 0x01 der Synchronisationsteil.

Hier nochmal das aktualisierte VI.
Das Problem von meinem vorletzten Beitrag bleibt allerdings