2Byte Wert "aufteilen" und auslesen

(28.11.2013 11:21 )redhand schrieb:  Dann sollte ich das wohl lieber lassen Danke! Aber wieso genau würde das passieren?

Solange die Schnittstelle nicht geöffnet ist, gehen dir Bytes verloren...

(28.11.2013 11:21 )redhand schrieb:  Ein Synchronisationsbyte reicht ja aus, dann kann man sich die anderen zwei sparen.
Im Moment ist 0x01 der Synchronisationsteil.

Nicht komplett sicher, ein Byte 0x01 könnte auch das zweite Byte eines Kanals sein. Du kannst dir nur dann sicher sein, dass "richtige" Synchronisations-Byte erwischt zu haben, wenn das Byte danach ungleich 0x01 ist.

Wenn du das verstanden hast, machen wir weiter.

Gruß, Jens

Anzeige

(28.11.2013 12:25 )jg schrieb:  Nicht komplett sicher, ein Byte 0x01 könnte auch das zweite Byte eines Kanals sein. Du kannst dir nur dann sicher sein, dass "richtige" Synchronisations-Byte erwischt zu haben, wenn das Byte danach ungleich 0x01 ist.

Wenn du das verstanden hast, machen wir weiter.

Das habe ich verstanden. Das kann ja theoretisch bei jedem Synchronisationsbyte der Fall sein. auch bei 0x00.
Diese absoluten Anfangswerte werde ich bei der Wegmessung aber nicht bekommen. Also gehe ich davon aus, dass wenn ich 0x01 erwische, es das richtige Byte ist.

Davon ausgehen, dass es schon funktioniert, ist ungünstig.

Schau mal, ob du das hier verstehst:

  Wegmessung.vi (Größe: 17,07 KB / Downloads: 193)


Gruß, Jens

EDIT: Anhang korrigiert, da war noch ein Fehler im VI.

Die Operationen verstehe ich soweit.

Was ich nicht verstehe:
Im Case:0
-Wieso wird erst eine Byte-Anzahl von 6 und anschließend durch das Schieberegister eine Byte-Anzahl von 3 an "Visa-Lesen" gesendet?
-Wieso ist der Offset beim mittleren "Search/Split String" 1 und beim rechten "Search/Split String" 3?

Im Case:1
-Für was brauche ich den ganzen Case-Fall überhaupt?

Im Case 0 fange ich den Fall des "falschen" Sync-Byte ab. Deshalb zuerst 6 Byte. Deshalb beim mittleren "Split" Länge 1. Ich schaue nach, ob das nächste Byte nach dem ersten gefundenen 0x01 ebenfalls ein 0x01 ist.

Wenn diese erste Synchronisation auf den Datenstrom erfolgreich ist, können danach immer 3 weitere Byte ausgelesen werden.

Man könnte es natürlich noch geschickter und aufwändiger machen, aber daran darfst du dich versuchen.

Gruß, Jens

Vielen Dank, das macht auf jeden Fall Sinn! =)

Anzeige

Noch eine letzte Frage:

Wenn Case 0 abgearbeitet ist, kommen letztendlich noch 2Byte von den anfangs gesendeten 6Byte in Case 1 (richtig?)

Wieso ist im "Search/Split String" in Case1 der Offset 3?
Wenn nach einmaliger Byte-Anzahl 6 nur noch 3Byte gesendet werden, ist es dann egal in welcher Reihenfolge diese ankommen?

Danke und Gruß

(28.11.2013 15:52 )redhand schrieb:  Noch eine letzte Frage:

Wollen wir wetten, dass nicht?

(28.11.2013 15:52 )redhand schrieb:  Wenn Case 0 abgearbeitet ist, kommen letztendlich noch 2Byte von den anfangs gesendeten 6Byte in Case 1 (richtig?)

Nein, es kommen max. 2 Byte an.
EDIT: Ich sehe gerade, ich habe im Upload einen Fehler. Das erste VI im Case 0 muss ein "Match Pattern" sein, kein "Split String"; Upload ist ausgetauscht!!

(28.11.2013 15:52 )redhand schrieb:  Wieso ist im "Search/Split String" in Case1 der Offset 3?

Es werden 3 weitere Bytes ausgelesen und zu den bis zu 2 Bytes angehängt. Davon werden wieder die ersten 3 Bytes ausgeschnitten, sie müssen jetzt die nächste Kanal-Info sein. Und das geht dann immer so weiter.
Das ist übrigens der Case 1 und folgende (beachte die Default-Auswahl).

Spiel doch mal alle Fälle durch:
Du hast folgende Möglichkeiten
1) das erste Byte im ersten Lesezyklus ist das erste Byte eines Kanals.
- jetzt kann das zweite Byte 0x01 sein, muss aber nicht. Auf jeden Fall ist das dritte Byte ein 0x01
2) das erste Byte im ersten Lesezyklus ist das zweite Byte eines Kanals, es kann ein 0x01 sein, muss aber nicht.
- auf jeden Fall muss jetzt das 2. Byte ein 0x01 sein.
3) das erste Byte ist das Synch-Byte, also 0x01. Das nächste Byte MUSS also ungleich 0x01 sein, da die Kanal-Info in den 4 High-Bits steckt.

Überlege dir für jeden der Fälle, was das VI macht.

Gruß, Jens

(28.11.2013 16:24 )jg schrieb:  Wollen wir wetten, dass nicht?

Du hast gewonnen

Ich verstehe den Ablauf soweit. Für mein Verständnis habe ich noch eine Frage:
-anbei ist nochmal mein VI
-es funktioniert momentan nur, wenn die innere While-Schleife bei True stoppt(siehe VI)
-Dann wird ja jedes mal Case 0 und Case 1 durchlaufen.
-Wenn ich die Fälle durchspiele, kommen immer die "richtigen" Bytes an, auch in richtiger Reihenfolge.
-Anschließend kommen die "neuen" 3 Byte, wieso ist bei diesen "neuen" 3Byte dann gewährleistet das diese auch in der richtigen Reihenfolge kommen?

Oder verstehe ich den Ablauf der While-Case-Struktur falsch?


EDIT:
Bei der Überprüfung "Ungleich?" kommt bei allen Fällen ein True, kann ich mir dann nicht den mittleren Teil komplett sparen und den "Nach Teil-String" von "Match Pattern" direkt zum 2. "Search/Split String" schicken?

(29.11.2013 10:22 )redhand schrieb:  EDIT:
Bei der Überprüfung "Ungleich?" kommt bei allen Fällen ein True, kann ich mir dann nicht den mittleren Teil komplett sparen und den "Nach Teil-String" von "Match Pattern" direkt zum 2. "Search/Split String" schicken?

Nein, das kannst du nicht! Das ist die Überprüfung, dass das erste gefundene 0x01 nicht zufällig das 2. Byte einer Kanalinfo ist, was ja durchaus sein kann!

2 Schleifen ineinander verschachteln ist ebenfalls "Blödsinn". Somit öffnest und schließt du wieder dauernd die Schnittstelle und läufst Gefahr, dass dir Bytes verloren gehen.
Der Sinn meines VIs war, den Datenstrom kontinuierlich abzugreifen und nur am Anfang für eine Synchronisation zu sorgen.

Gruß, Jens