Sensor ausgabe zählt immer um 8 hoch

Hallo liebe LabVIEW-Profis,

also ich besitze folgende Hardware: Eine Beckhoff-Klemme KL3062. Sie hat eine Auflösung von 12Bit und einen Spannungspegel von 0-20V. Die Kommunikation fidnet über Modbus TCP statt.

Nun habe ich folgendes Problem. Wenn ich die Daten auslese wird der Wert immer in 8er Schritten eröht. Woran kann das liegen?

Ich lese die Register aus über den Modbus Funktionscode 4 dann werden die nach Namen aufgeschlüsselt, da insgesamt 7 Register ausgelesen werden. Dann wird das Array indiziert und ich verdrahte es mit einem Anzeigeelement und dividiere es zuvor für die Messbereichsanpassung durch 204.8. Allerdings muss man es nochmal durch 8 dividieren damit die Anzeige stimmt und ich weiß nicht den Grund dafür.
Die anderen Sensorsignale sind PT Signale mit speziellen PT-Klemmen da das Signal nur mit 0.1 multipliziert werden und man hat die richtige Auflösung.

Ich hoffe die Informationen sind ausreichend und es kann mir einer Helfen.

Danke
Gruß

Anzeige

Hallo gigi,

die 12bit-Messwerte werden als 16bit breite Datenworte übertragen. Wird der 12bit-Wert in der Klemme evtl. einfach auf 16bit erweitert, indem man 3bit unten "einstopft"? (Es werden wahrscheinlich "nur" 3bit eingestopft, um das oberste Bit immer auf FALSE zu lassen und so immer ein positives Sign für den 0…20V-Messbereich zu haben.)

Frag doch einfach mal Beckhoff…

Also laut diesem Dokument hat die Klemme 3062 eine Eingangsbereich von 0-10 V, nicht 0-20 V.

Laut Seite 4 dieses Dokuments entspricht 10 V dem I16 Wert 32767, du musst also durch 3276.7 teilen, nicht durch 204.8

Gruß, Jens

EDIT: Und das alles bestätigt die Vermutungen von Gerd.

Entschuldigung es handelt sich um die Sonderklemme 0011. Die besitzt einen Spannungspegel von 0-20V.
Hm ok. Ich schaue mir das jetzt nochmal nach euren Hinweisen an. Gruß

Hallo Jens,

laut Webseite gibt es eine Sonderklemme mit 20V Spannungspegel…

(19.01.2016 10:57 )mrgigi schrieb:  Entschuldigung es handelt sich um die Sonderklemme 0011. Die besitzt einen Spannungspegel von 0-20V.
Hm ok. Ich schaue mir das jetzt nochmal nach euren Hinweisen an. Gruß

Sags doch gleich!

(19.01.2016 11:01 )GerdW schrieb:  Hallo Jens,

laut Webseite gibt es eine Sonderklemme mit 20V Spannungspegel…

Dann entspricht also 20V = 32767, und somit landen wir bei deinem fehlenden Faktor 8.

Gruß, Jens

Anzeige

Ok, das macht jetzt mehr Sinn. Danke dafür!
Also da es keine 12Bit bei LabVIEW gibt wurde das auf die Wortlänge 16 erweitert. Dadurch "fehlen" quasi 4 bits. Das Erste wird wahrscheinlich für das Vorzeichen verwendet. Bit 2 und 3 sind 0 und Bit 4 auf 1 was den Faktor 8 ergibt. Hat das einen speziellen Grund, dass das 4te Bit auf 1 gesetzt ist?

Das hat doch nichts mit LabVIEW zu tun!
Beckhoff hat entschieden, den Messwert als Integer-Wert mit der beschriebenen Skalierung zu veröffentlichen (bzw. im Prozess-Abbild so abzulegen).
0 V = 0
10 V = 16383
20 V = 32767

Gruß, Jens

ok, vielen Dank!
Gruß

Hier noch eine Aufklärung über den Sinn des Ganzen:
Die Daten werden gewöhnlich Byteweise übertragen. Und genormte Zahlenformate sind U8, U16, U32, .. I8, I16, i32..
U12 und I12 gibt es nicht - dieses Format muß zur weiteren Verarbeitung in das U16/I16-Fomat reingepackt werden. Die Frage ist: Packen linksbündig oder rechtsbündig?
Antwort: Bei vorzeichenbehafteten Zahlen, also bei I12-Format, wird nur bei linksbündigem Packen das Vorzeichen richtig interpretiert. Der scheinbare Schönheitsfehler, dass die Werte dann um den Faktor 8 zu groß sind, ist überhaupt kein Nachteil, da ja die Rohwerte in jedem Fall zu skalieren sind, also beispielsweis auf die Endbereiche -5V..+5V.
Bei U12-Format schadet linksbündig auch nichts. Man darf dann nur nicht U12 in das I16-Format packen.
Darüber hinaus spricht noch etwas anderes für die Linksbündigkeit. Wenn die 12bit-Messkarte gegen eine 16Bit -Karte getauscht wird, muss nichts am Programm geändert werden. Es erhöht sich nur die Auflösung. (Dieses Argument bezieht sich allerdings nicht auf NI-Messkarten. Die Daqmx-Treiber haben von sich aus schon sehr viel eingebaute "Skalierungs-Intelligenz"; um Probleme in einer so tiefen unteren Ebene muß man sich da überhaupt nicht kümmern)