LabVIEWForum.de

Hallo Labviewgemeinde,

ich habe folgende Voraussetzungen:

-ich habe ein MSP-EXP430G2 LaunchPad Experimenter Board
-über die UART-Schnittstelle werden Daten gesendet (hexadezimal)
-über ein TTL-232R-3V3-AJ Kabel ist das LaunchPad über die USB-Schnittstelle mit dem PC verbunden. Die Signale kann ich über einen virtuellen COM-Port auslesen.

Folgende Aufgabe:

Ich möchte in Zukunft einige Kanäle gleichzeitig auslesen. Zunächst aber jetzt mal einen
Dabei handelt es sich um eine Wegmessung

Die Signale kommen folgendermaßen:
Ich bekomme immer 2 Byte, wobei die ersten 4 Bit des ersten Bytes die Information der Kanalnummer beinhaltet (0001 für Kanal 1; 0010 für Kanal 2 etc.). Die restlichen 12 Bit geben den Wert für die Wegmessung wieder. Also 4096 Abschnitte.

Frage:
Wie kann ich die 2 Byte auslesen, dass zunächst die ersten 4 bit (für die Kanalnummer) und danach die 12 restlichen bit (für den Weg) ausgelesen werden?
Sprich wenn später mehrere Kanäle ausgelesen werden soll der Kanalnummer der richtige Wegwert zugewiesen werden.

Hallo redhand,

etwas elementare Mathematik ist dein Freund:
[attachment=47320]
Im Bild habe ich der Einfachheit halber nur die ersten 2 Byte deiner Geräteantwort ausgewertet...

Bist du dir sicher, dass du die serielle Schnittstelle in jeder Iteration erneut initialisieren musst?

Soviel also zum "Typecast to Single" und speichern von Float-Zahlen... Sorry, aber

EDIT & OnTopic:
Man kann auch ein wenig Bit-Geschiebe machen:
[attachment=47322]
Gruß, Jens

Hallo Gerd, vielen Dank für die schnelle Antwort!

(19.11.2013 14:36 )GerdW schrieb: [ -> ]Im Bild habe ich der Einfachheit halber nur die ersten 2 Byte deiner Geräteantwort ausgewertet...

Vielen Dank dafür, mir war nicht klar, dass man das so machen kann, wobei mir dazu etwas das verständnis fehlt.
Wieso wird das erste Teil-Array(1Byte, wenn ich das richtig verstehe?) durch 16 geteilt? Und anschließend der Rest mit 256 multipliziert?

(19.11.2013 14:36 )GerdW schrieb: [ -> ]Bist du dir sicher, dass du die serielle Schnittstelle in jeder Iteration erneut initialisieren musst?

Ich denke nicht, aber wie kann ich das umgehen?

Noch ein Zusatz. Momentan ist es noch so, dass immer nach den 2 Byte mit der Kanal- und Weginformation noch drei 8-bit Werte (0), also jeweils ein leeres Byte, gesendet werden. Argument hierfür ist, dass man sich so beim Auslesen mehrerer Kanäle orientieren kann, dass immer nach den drei Nullen der nächste Kanal kommt. Braucht man das überhaupt?

Grüße redhand!



@jg: Ich muss leider klein Anfangen und mich Schritt für Schritt weiterhangeln. Leider kann ich nicht 2 Probleme in die Zukunft schauen

Hallo redhand,

Zitat:Wieso wird das erste Teil-Array(1Byte, wenn ich das richtig verstehe?) durch 16 geteilt? Und anschließend der Rest mit 256 multipliziert?

- Das ist kein Teil-Array, sondern ein Element (ein skalarer Datentyp)...
- Zur Mathematik: du solltest deine Anforderung

Zitat:Ich bekomme immer 2 Byte, wobei die ersten 4 Bit des ersten Bytes die Information der Kanalnummer beinhaltet (0001 für Kanal 1; 0010 für Kanal 2 etc.). Die restlichen 12 Bit geben den Wert für die Wegmessung wieder. Also 4096 Abschnitte.

mal auf einem Blatt Papier aufmalen und das Rechnen mit 2er-Potenzen üben...

Zitat:Braucht man das überhaupt?

Wohl eher nicht, wenn die Botschaft ein "korrekt" definiertes Format hat. Wozu unnötigen Datenballast versenden? Du liest immer 10Byte vom Port, da machen 3 Bytes schon 30% Ballast aus...

(19.11.2013 15:01 )redhand schrieb: [ -> ]Noch ein Zusatz. Momentan ist es noch so, dass immer nach den 2 Byte mit der Kanal- und Weginformation noch drei 8-bit Werte (0), also jeweils ein leeres Byte, gesendet werden. Argument hierfür ist, dass man sich so beim Auslesen mehrerer Kanäle orientieren kann, dass immer nach den drei Nullen der nächste Kanal kommt. Braucht man das überhaupt?

Durchaus sinnvoll (EDIT: Ui, ich widerspreche Gerd). Wenn deine Gegenstelle einfach unaufgefordert "Werte" sendet, woher willst du dann bei Start der Kommunikation wissen, welches Byte du zuerst ausgelesen hast? Hast du das High-Byte mit der Kanal-Info erwischt oder das Low-Byte mit dem Rest des Wertes? Wenn aber immer 3x 0x00 Bytes gesendet werden, dann kannst du den Empfangsstring nach diesem Muster parsen und weißt, dass das nächste Byte der Beginn einer Kanal-Übertragung sein muss! Denn ein Muster 3x 0x00 kann kein Kanal sein. Wobei da genau genommen auch ein Muster 2x 0x00 reichen würde.

Gruß, Jens

P.S.: Lästermodus an: Ich würde ja erst mal korrekt die Daten umwandeln, bevor ich mich ums Speichern kümmere. Aber man lernt ja nie aus.

Hi Gerd

(19.11.2013 15:06 )GerdW schrieb: [ -> ]- Das ist kein Teil-Array, sondern ein Element (ein skalarer Datentyp)...
- Zur Mathematik: du solltest deine Anforderung
mal auf einem Blatt Papier aufmalen und das Rechnen mit 2er-Potenzen üben...

Danke, der erste Teil der Antwort hätte mir genügt, denn wenn ich das nicht weiß bringt mir auch die Mathematik nichts.

Also ist das folgendermaßen zu verstehen??
Wenn das erste Byte bsp so ankommt: 0001 0000 entspricht es dezimal 16(dem ersten Element), deshalb wird durch 16 geteilt, so weiß man welcher Kanal gerade gelesen wird.

(19.11.2013 15:10 )jg schrieb: [ -> ]... dann kannst du den Empfangsstring nach diesem Muster parsen und weißt, dass das nächste Byte der Beginn einer Kanal-Übertragung sein muss! Denn ein Muster 3x 0x00 kann kein Kanal sein.

Da liegt bei mir auch noch ein Verständnisproblem.
Zunächst: Bis eine Information (Kanal und Weg) aufgenommen wurde, werden 5 Bytes abgearbeitet (3mal 0x00). Muss ich dann bei VISA-Lesen bei Byte-Anzahl auch 5 wählen oder wie ist hier der Zusammenhang?

Wenn dann beispielsweise 3x 0x00 kommt, klar dann sieht man, wenn man den kontinuierlichen Datenfluss anschaut, welches das Byte mit der Kanalinformation ist bzw wann es kommt.
Wie kann man dann das Auslesen des Strings so steuern, dass die 3x 0x00 immer abgewartet werden und die zwei darauf folgenden Bytes entsprechend ausgelesen werden?

Danke für eure schnellen und guten Antworten!

(19.11.2013 15:35 )redhand schrieb: [ -> ]Danke, der erste Teil der Antwort hätte mir genügt, denn wenn ich das nicht weiß bringt mir auch die Mathematik nichts.

Also ist das folgendermaßen zu verstehen??
Wenn das erste Byte bsp so ankommt: 0001 0000 entspricht es dezimal 16(dem ersten Element), deshalb wird durch 16 geteilt, so weiß man welcher Kanal gerade gelesen wird.

Nicht ganz. Das erste "Datenbyte" wird nur selten 0001 0000 entsprechen, denn die letzten vier Bits bilden zusammen mit dem zweiten Datenbyte den "Kanalwert". Ganzzahlige Division durch 16 "entfernt" diese 4 "low bits.

(19.11.2013 16:10 )redhand schrieb: [ -> ]Da liegt bei mir auch noch ein Verständnisproblem.
Zunächst: Bis eine Information (Kanal und Weg) aufgenommen wurde, werden 5 Bytes abgearbeitet (3mal 0x00). Muss ich dann bei VISA-Lesen bei Byte-Anzahl auch 5 wählen oder wie ist hier der Zusammenhang?

Wenn dann beispielsweise 3x 0x00 kommt, klar dann sieht man, wenn man den kontinuierlichen Datenfluss anschaut, welches das Byte mit der Kanalinformation ist bzw wann es kommt.
Wie kann man dann das Auslesen des Strings so steuern, dass die 3x 0x00 immer abgewartet werden und die zwei darauf folgenden Bytes entsprechend ausgelesen werden?

Da kann ich auch nur spekulieren, du lieferst zu wenige Infos.
Punkt 1) Dein VI liest "nur" Daten von der Schnittstelle, ohne ein Write-Kommando.
Punkt 2) Dann hast du noch die Info mit den 3 0x0 Bytes nachgeliefert.

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. Mglw. wird aber auch nach jedem Kanal der 0x0-Block eingefügt.

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.

Gruß, Jens

(19.11.2013 17:26 )jg schrieb: [ -> ]Prinzipiell musst du die Schnittstelle öffnen, 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.

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?

Edit: Irrtum von mir. Auch wenn die KanalNr. 0 vermieden wird, sind Mehrdeutigkeiten bei der Startsynchronisation nicht ausgeschlossen. Wenn die letzten 16bits eines Datensatzes null sind, hat man mit dem nachfolgenden Datensatz 4 hintereinanderliegende Null-Bytes. (Und das erste Parkinsonsche Gesetz lautet ja: "Alles, was schief gehen kann, geht schief.")
Unter diesen Umständen kann man nur hoffen, dass die Übertragung der Datensätze nicht unmittelbar hintereinander erfolgt, sondern immer mit Pausen zwischendrin. Die Erkennung einer Pause wäre dann gewissemassen das Synchronisationszeichen für einen neuen Datensatz, und die Synchronisationsbytes brauchte man eigentlich überhaupt nicht mehr.