Verständnisproblem Messwerte im Little Endian im DB

[bycar]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Nachmittag zusammen,

ich habe mit der Interpretation einer Angabe aus der Betriebsanleitung eines Sensors Probleme.

Dort wird gesagt: "Der Datentransfer verwendet als Daten-Format Little Endian. Hier wird das Byte mit den niederwertigsten Bits (am wenigsten signifikante Stellen) zuerst gespeichert, d.h. an der kleinsten Speicheradresse".

Die Daten eines Messwerttelegrammes werden in einem DB (schön strukturiert mit UDTs) abgelegt.
In dem Telegramm sind z.b. Messwert (32 Bit), Timestamp (32 Bit), Status (16Bit) & Fehlerwert (16Bit) enthalten.
Der Messwert wird in nm übergeben!

Jetzt steh ich irgendwie auf dem Schlauch mit der Umrechnung der Messwerte in weiterverarbeitbare mm-Werte (Abstandswerte).
(Screenshot aus dem DB im Anhang)


Ich dachte mir dass eine Wandlung z.B. so erfolgen könnte:

//Little to Big Endian wandeln
L DB???.Block.Frame[25].Messwert[1].Messwert_LE
TAD
T #Temp_Messwert_BE
//...#Temp_Messwert_BE ist vom Typ DINT

//Konvertierung als Real-Zahl
L #Temp_Messwert_BE
DTR
T #Temp_Real

//von nm in mm umrechnen
L #Temp_Real
L 1.00e-006
*R
T #Temp_Messwert_mm

Leider gibt die Umwandlung aber Messwerte heraus, die einfach nicht stimmen können, da sie den Messbereich des Sensors bei weitem überschreiten.

Hat jemand zu dieser Thematik evtl. einen guten Vorschlag

 

[Matze001]

Erstmal: Stimmen die Werte die im DB stehen denn in Nanometer überhaupt?

Ist das der Fall: Lass mal TAD weg, und guck was dann im DINT steht!


Grüße

Marcel

 

[bycar]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also die Werte in nm stimmen natürlich auch nicht.
Die einfache Multiplikation mit den 1.00*10^-6 ist wohl nicht für den Fehler verantwortlich.

Mein Verdacht / Frage an jemanden der sich damit auskennt ist vielmehr:
Arbeiten S7-SPSen vielleicht sogar mit Little Endian?

Dann wäre das Weglassen des TAD natürlich die Lösung.

 

[Matze001]

Das ist es ja was ich meine:

Stimmen die Werte die du einliest denn überhaupt schonmal?

Grüße

Marcel

 

[bycar]

Hm alsoooo...
Ich hab die Werte gerade mal umgerechnet, und zwar ohne LE -> BE. Der DB geht ja noch weiter (Screenshot wäre sonst zu groß geworden). Unter anderem berechnet sich einer der Messwert[??].Messwerte_LE aus zwei anderen Werten (Dickenwert aus einer Differenzmessung).
Wenn man das zu Fuß nachrecnet stimmt die Dickenberechnung aus dem DB und aus meinem Taschenrechner schonmal überein (nach Adam Riese gilt ja wohl ungefähr: (-142,4569) + (-97,6037) = (-240,0606)).

Was mich aber nachwievor wundert ist der Wert 142,4560 mm. Das kann einfach nicht sein der Sensor misst Distanzen zwischen 200 und 700mm.
Es ist echt zu dämlich. :-x

 

[Matze001]

Zuviel Werbung?
-> Hier kostenlos registrieren

Okay mach es doch einfach

Stell den Sensor auf einen festen Wert ein (z.B. 300mm). Dann misst du, und guckst was du rausbekommst, in der Hoffnung da irgendwann 300mm stehen zu haben.

Grüße

Marcel

P.S: wie kommst du auf die negativen vorzeigen?

 

[bycar]

"P.S: wie kommst du auf die negativen vorzeigen? "

Die kommen aus den Verrechnungsblocks des Controllers, der das Telegramm schickt. Diese Blöcke haben als Faktor (-1) und werden in einer vom Hersteller vorgefertigten Config-Datei für Dickenmessungen genutzt.

Falls es interessiert, es ist der CSP 2008 aus dem Hause Micro-Epsilon mit 2 Distanzsensoren der Serie ILD 1700.

...Auf festen Wert einstellen habe ich hier an Ort und Stelle jetzt keine Möglichkeit werde ich aber morgen mal so machen.

 

[Paule]

Wenn du negative Zahlen bekommst, warum machst du im DB nicht den Typ DINT sonder DWORD?

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

..Arbeiten S7-SPSen vielleicht sogar mit Little Endian?..

Meines Erachtens verwendet Siemens das Motorola-Format, welches dem Big Endian entspricht. Die Wandlung mit TAD sollte also richtig sein. Weißt du, was der Controller macht? Sind es wirklich die absoluten Meßwerte der Sensoren?

 

[bycar]

@ Paule: Die UDTs habe ich relativ schnell zusammengestrickt, aber die Messwerte als DINT zu nehemn ist vielleicht wirklich keine schlechte Idee. So bräuchte ich in meinem FC zur Umrechnung nur noch in Real konvertieren und dann in mm, sodass dieser dann in nem anderen DB "Messwerte_mm_umgerechnet" abgelegt werden können.

@Dagobert: Also die ausgegebenen Messwerte sind wirklich Absolutwerte (Zitat Betriebsanleitung: "Messwert in der Auflösung 1 nm als vorzeichenbehaftete Integerzahl. Durch Multiplikation mit 0.000001 kann der Messwert in Millimeter umgerechnet werden".
...Wenn ich wie gesagt ohne TAD rechne stimmt zumindest die mathematische Verrechnung. Deswegen habe ich von TAD jetzt eher Abstand genommen.

 

[winnman]

hab zwar von dem Sensor keine Ahnung aber könnte es sein, dass der nicht den Absulut Abstand ausgiebt, sondern von einem Referenzpunkt? ev. von den 200mm?

 

[thomas_1975]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

der Unterschied zwischen dem little und big ist doch die Bytereihenfolge, nicht die Wort- und Bytereihenfolge ( oder irre ich ).
Ich denke TAD ist wohle eher der falsche Befehl,http://www.automation.siemens.com/doconweb/pdf/SINUMERIK_SIMODRIVE_04_2010_D/S7_AWL.pdf?p=1 Seite 58.
Du mußt doch eigentlich die 2 Byte im Wort drehen, also eher 2 mal ein TAW. Das high und low wort bleibt an seiner Stelle.

gruß Thomas

 

[Paule]

( oder irre ich )

Ich glaube schon.
Ein doppeltes TAW habe ich für eine Konvertierung noch nie gebraucht, ein einfaches TAD sehr wohl.

 

[bycar]

..., ein einfaches TAD sehr wohl.

Dem ist auch so. Ich habe die Messwerte noch mal beobachtet und irgendwie muss ich mich da getäuscht haben. Jedenfalls kann nun der Messwert in mm einfach mit dem TAD umgerechnet werden und anschließend mittels Konvertierung DINT to REAL & Multiplikation mit 0.000001 in einen mm-Wert umgerechnet werden.

Der zum Messwert gehörende Status (ein WORD) ließ sich dann halt mit dem TAW umwandeln.

Trotzdem nochmal danke für die Hilfestellungen.

PS: Noch eine kurze Frage hinterher, über die ich letztens gestolpert bin.
Kann es sein, dass wenn man diese Umwandlung sowie eine gleitende Mittelwertbildung auf insgesamt 6 versch. Messwerte anwendet, eine übliche 314er-CPU in STOP geht - und zwar allein aufgrund von Zykluszeitverletzungen ( >150ms)? Man muss dazu sagen, dass diese Frames aus 6 versch. Messwerten in einem 25er-Block zusammengefasst sind. Dieser Block wird natürlich in einer Schleife (halt 25 Durchläufe) ausgelesen.