ifm SU6020 IO-Link Auswertung von Skalierungs-Bytes

RucksackSepp

Level-2
Beiträge
39
Reaktionspunkte
9
Zuviel Werbung?
-> Hier kostenlos registrieren
Servus miteinander,

ich möchte die Daten von einem SU6020 Durchflussmesser in vollem Umfang auslesen. Die Werte selbst stellen kein Problem dar, nur bei den beiden Skalierungs-Bytes komm ich nicht voran. (Schnittstellenbeschreibung ist angehängt)

Auf Seite 3 sind die Umrechnungsfaktoren in die jeweilige Einheit aufgelistet. Aber es fehlt mir eine Erklärung der Scale-Bytes für den Durchfluss und die Temperatur.
Bei Veränderung der Einheit über IO-Link im Gerät selbst, ändern sich diese auch nicht mit. Diese sind statisch bei 2#1111_1100 für den Durchfluss und 2#1111_1110 für die Temperatur. Durchfluss war zu dem Zeitpunkt bei 0 und die Temperatur bei ca. 30 °C.

Hat jemand Erfahrungen mit diesem Sensor, oder dieser Skalierung und kann mir weiterhelfen?

Viele Grüße,
Fabian
 

Anhänge

Servus Fabian,

ich habe kürzlich mit den VVB von ifm zu tun gehabt und da ist die Schnittstelle ähnlich aufgebaut. Ich bin auch darüber gestolpert das die Einheitsänderung im Sensor keinen Einfluss auf die Prozessdaten über IO-Link hat. Es ist nach meinem Verständnis nur für die interne Verarbeitung im Sensor, wenn man z.B. einen Grenzwert für den Prozesswert parametriert oder zur Anzeige an einem internen Display (wenn vorhanden).
Man kann die Scale Bytes als SInt (Short-Integer) einlesen (also in deinem Beispiel 2#1111_1100 = -4) und dann damit rechnen.
Messwert := Eingangswert * 10^Skalierwert

In SCL dann so z.B.: #Temperature := INT_TO_REAL(#iTemperature) * 10.0 ** SINT_TO_REAL(ScaleTemperature);
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Achso, dann bildet es die Zehnerpotenz. Wobei diese sich beim verändern der Einheit im Sensor nicht verändert hat, aber das teste ich heute nochmal aus.
Hab schon an ein paar Dinge Gedacht, aber so simple, dass es der Exponent sein kann, hab ich nicht. 😆

Danke schonmal für Deine Hilfe!
 
Das ist keine Spezial-Funktionalität der ifm electronic.
So funktioniert das SmartSensorProfil für messende Geräte V2 der IO-Link Community.

Rohwert * 10^Skalierungsfaktor ergibt den Wert in der SI-Einheit.

Einzige Ausnahme: Temperatur. Da niemand in °K denkt, hat die Community hier °C genommen.
 
Kurzer Test später:
Ich kann in den Parametern die Einheiten l/min, m/s, m³/h und l/h auswählen:
1750657205066.png

Aber das %IB gibt ausschließlich eine -4 dafür aus (m³/h), vermutlich deshalb:
Rohwert * 10^Skalierungsfaktor ergibt den Wert in der SI-Einheit.
Damit der Wert immer in der gleichen Einheit bleibt und man dann erst umrechnet. Wobei sich mir dabei die Existenz des Skalier-Bytes als überflüssig erscheint, wenn dieses sowieso konstant bleibt.

Danke euch beiden, habt mir gut weiter geholfen!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn du den Sensor durch einen anderen Sensor tauschst (anderer Hersteller, neue Generation) gibt er dir den Wert auch in der gleichen Einheit wieder wie der alte.

Das was du einstellst ist sozusagen nur die Vorort Anzeige, das verändert nie dein Prozessabbild.
 
Kurzer Test später:
Ich kann in den Parametern die Einheiten l/min, m/s, m³/h und l/h auswählen:
Anhang anzeigen 88541

Aber das %IB gibt ausschließlich eine -4 dafür aus (m³/h), vermutlich deshalb:

Damit der Wert immer in der gleichen Einheit bleibt und man dann erst umrechnet. Wobei sich mir dabei die Existenz des Skalier-Bytes als überflüssig erscheint, wenn dieses sowieso konstant bleibt.

Danke euch beiden, habt mir gut weiter geholfen!

Ich würde das nicht als überflüssig bezeichnen.
Du nimmst immer den selben Funktionsbaustein für Geräte die dem SSP V2 entsprechen.
Diese gibt es von der ifm electronic als auch von Siemens.
Links den Rohwert dran, rechts kommt der Wert in der SI Einheit, ohne dass man sich Gedanken über Kommastellen usw. machen muss.

Es gibt auch Hersteller, die eine Umstellung des IO-Link Prozesswertes zulassen.
Hier kann sich unter Umständen auch die Skalierung verändern.
Wenn man den entsprechenden Baustein verwendet, ist das aber ganz egal.

Solange man die Geräteüberprüfung abschaltet, kann man auch z.B. im Notfall einen 10bar Sensor durch einen 25bar Sensor ersetzen, ohne das SPS Programm anzupassen.
 
Wenn du den Sensor durch einen anderen Sensor tauschst (anderer Hersteller, neue Generation) gibt er dir den Wert auch in der gleichen Einheit wieder wie der alte.

Das was du einstellst ist sozusagen nur die Vorort Anzeige, das verändert nie dein Prozessabbild.

Vorsicht:
Der erste Satz funktioniert nur bei abgeschalteter Identifikation und abgeschaltetem Datastorage.

Der zweite Satz gilt nicht pauschal.
Es gibt sehr wohl Hersteller, die eine Veränderung des Prozessdatenabbildes zulassen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
In V2 wurden ja diese Scale-Bytes eingeführt, um eine herstellerunabhängige Übertragung der Werte in SI Einheiten zu ermöglichen. Ok, kann man so machen. Aber warum definiert man für die Float Werte nicht einfach den Si Wert? Dann braucht man den Hantier mit den Skale Bytes nicht?!?
 
In V2 wurden ja diese Scale-Bytes eingeführt, um eine herstellerunabhängige Übertragung der Werte in SI Einheiten zu ermöglichen. Ok, kann man so machen. Aber warum definiert man für die Float Werte nicht einfach den Si Wert? Dann braucht man den Hantier mit den Skale Bytes nicht?!?
Das gibt es auch.
Problem ist nur, dass Gleitpunktzahlen viel Rechenleistung erfordern.
Das braucht starke Controller in den IO-Link-Devices.
Bei höherpreisigen Geräten ist das OK, aber bei der Masse der Sensoren sind solche Controller einfach zu teuer.
 
Gleitpunktzahlen-Rechenleistung ist heutzutage wohl nicht mehr so das Problem.
Ich meine, die Lösung mit dem zusätzlichen Skalierungsbyte ist hauptsächlich zur Reduzierung der Kommunikationsmenge und um die Rundungs-Probleme des üblichen IEEE-754-Gleitpunktzahlen-Formats (Float, Real) zu vermeiden. Mit 32Bit-Gleitpunktzahlen hat man eine Auflösung von 6 bis 7 Ziffern und nicht jeder Wert ist genau darstellbar. Mit 32Bit-Festpunktzahlen hat man eine Auflösung von 9 bis 10 Ziffern und keine Nachkommastellen-Rundungsprobleme. Mit nur einem Byte mehr für den Exponent erhält man quasi ein 40Bit-Gleitpunktzahlen-Format mit den Vorteilen von Festpunktzahlen.
 
Zurück
Oben