2er Komplement

' schrieb:Um das das MSB der 12 bit-Zahl in das MSB des 16bit Containers zu bringen, kann man die Bits entweder um 4 Positionen nach links verschieben oder aber mit 16 multiplizieren. So weit so gut. Man darf aber danach die Bits nicht wieder nach rechts shiften, sondern muß das mit Ganzzahl-Division durch 16 machen. Also wie im Beispiel oben. Es bleibt aber alles nach wie vor ganz einfach, im Gegensatz also zu dem zitierten Google-Beispiel.

Ja so geht das.
Für mich ist das Maskieren der Bits verständlicher und einfacher.
Was ist dabei kompliziert?

Anzeige

' schrieb:Ja so geht das.
Für mich ist das Maskieren der Bits verständlicher und einfacher.
Was ist dabei kompliziert?

Es ist verständlich und auch nicht kompliziert, aber ich sehe nicht ein, daß ich auch nur den geringsten intellektuellen Aufwand betreiben soll, wenn LabVIEW das selbst machen kann. Die 12bit Zahl, die sowieso im I16 Format verpackt sein muß, weil es ein I12/U12 - Format gar nicht gibt, einfach mit 16 multiplizieren, und schon wird die Zahl, weil jetzt das MSB an der richtigen Stelle sitzt, von LabVIEW richtig als 2er-Kompliment interpretiert. Mehr braucht man nicht. Anschließend muß sowieso eine Skalierung vorgenommen werden, also z.B auf +-10Volt, da kann man auch gleich mit berücksichtigen, daß die ursprünglichen Rohdaten jetzt um den Faktor 16 größer sind. Mit Einbeziehung einer solchen Skalierung wird der Vorteil also noch offensichtlicher:
   

Hallo,

vielen herzlichen Dank für die vielen Tipps und Ratschläge! Ich habe jetzt die Version von RoLe und Lucki verwendet.

Leider läuft das Signal meines Sensor immer noch nicht unter 0.

Es wird ein Highbyte (8bit) und ein Lowbyte (8bit) übergeben. Nachdem ich die Daten so geschoben habe, dass die Statusbits nicht mehr angezeigt werden erhalte ich mein Signal als 2er Komplement, welches ich in das vorgeschlagene Schema einspeise.

Erkennt ihr zufällig auf die Schnelle einen Fehler?


  Programm_V6.vi (Größe: 21,01 KB / Downloads: 229)

Weiß nicht, aber was schon mal nicht geht ist der Aktivation von TermChar. Denn wenn Du im String direkt bytes überträgst, also 1 StringChar pro Byte, dann kann das Zeichen LF sowohl Endzeichen alsi auch Datenbyte sein, und das geht auf Dauer schief.
Wenn man Termchar verwendet, dann müssen die Daten im ASCII-HEX-Format, also mit 2 Zeichen pro Byte, übertragen werden (z.B Byte mit Wert 255 = "FF") Dann kommen sich Steuerzeichen und Datenzeichen nicht gegenseitg ins Gehege.
Oder aber man verwendet Termchar nicht, dann muß man aber genau wissen, wie viele Bytes ankommen.

Edit: Hier noch ein letzter Veruch Dir zu zeigen daß man all diese Cases, bits und Bytes für die Konvertierung überhaupt nicht braucht.
   

Bei dem Bit-Geschiebe, was du da machst blicke ich nicht durch. Was ist denn das für ein Chaos. Wieso eine Fallunterscheidung, wenn das höchstwertige Bit des ersten Zeichens 1 oder 0 ist? Und dann tauschst du nur die Reihenfolge der beiden Bytes in der Case-Struktur.

Aber es fehlt IMHO noch ein paar wichtige Infos:

1. Nehmen wir an, dass immer 2 Bytes im Binärformat gesendet werden. Wie Lucki schon sagt, muss dann aber der Termination-Char auf FALSE stehen.
Aber welches Byte der 12bit-Zahl wird zuerst gesendet? Das niederwertige Byte, wo dann alle 8bits gesetzt sein können? Oder das höherwertige Byte, in dem dann eigentlich maximal die vier niedrigsten Bytes gesetzt sein können, die 4 hochwertigen Bits sollten immer Null sein.
2. Wie unterscheidest du, ob du gerade das MSB oder das LSB empfangen hast?

In Ergänzung zu Lucki also noch hier, je nachdem, welcher Zeichen das MSB ist (oben MSB wurde zuerst empfangen, unten LSB zuerst empfangen):
   

Gruß, Jens

Vielen Dank euch beiden!

Ich hatte eine I16 Umwandlung vergessen. Jetzt funktioniert alles einwandfrei!

Das "Bit-Geschiebe" kommt von den Statusbits des Sensor, die ich so entferne!

Gruß