Wertunterschiede X1-Logik / GPA-Datenpunktmonitor / ETS-Diagnose

[araeubig]

In einem X1-Logikblatt lasse ich mir über einen Baustein HCL-Werte (ich benötige und nutze davon nur den Helligkeitswert) berechnen. Dies funktioniert auch einwandfrei. Um die Buslast zu reduzieren, runde ich diese Werte und lasse nur "Ganzzahlen" durch einen Send-by-Change ausgeben.

Was ich nicht verstehe ist, dass die Logik mir einen Wert von "24.0" ausgibt aber in der ETS respektive im GPA einen Wert von "23.9"/"23.921569" anzeigt. Wie kann das sein, wenn der Ausgangswert "24.0" ist?

Ein Anzeigefehler durch den Formelbaustein kann es ja nicht sein, oder?

Screenshot (938).png Screenshot (939).png Screenshot (940).png Screenshot (937).png

[knxPaul]

Das liegt an der speziellen Definition des DPT 5.001: Es gibt 255 Werte für den Bereich 0 bis 100 %. Das sind keine ganzzahligen Prozentwerte wie beim DPT 5.004 sondern 255 Werte im Abstand von etwa 0,4 %. Also höhere Auflösung erkauft durch den Verlust an exakter Darstellung von ganzzahligen Prozentwerten.

[araeubig]

Und hier noch ein Auszug aus der Logik mit aktuellem Wert (und falschem Wert in der ETS):

Screenshot (941).png Screenshot (942).png

[willisurf]

Die ETS kann Floatingpointzahlen mit 16bit nur mit einer geringen Genauigkeit abbilden. Daher ist die Verfälschung normal. Du kannst das auch völlig unabhängig vom GPA mal im Gruppenmonitor ausprobieren, wenn Du auf eine Test GA mit entsprechenden DPT mal Werte sendest und Dir das Ergebnis anschaust. 16bit sind halt nicht viel für floating point.

[araeubig]

16bit sind halt nicht viel für floating point

Absolut richtig aber es ist eigentlich genau "umgekehrt" ich gebe 24.0 aus und bekomme 23.921569 (als Beispiel) in den Wert X1 geschrieben und in der ETS gekürzt auf 23.9.

[araeubig]

Ich schreibe im Gruppenmonitor auf eine GA (die als 5.001 definiert ist) und mit einer Prozentvariable des X1 (1 byte) verbunden ist den Wert "87" und erhalte auf der RM-Adresse "87.1" zurück. Ich sehe da eher den Fehler beim X1 und der "Prozentvariable".

[willisurf]

Kann auch sein, ich hatte jetzt in den Screenshots nicht Deinen verwendeten DPT gefunden. Aber wenn der Wert in der ETS/auf dem Bus dargestellt werden kann und trotzdem verändert wird, dann wird das Problem im GPA liegen.

[mumpf]

Das ist normal. DPT 5.001 ist ein Byte Wert im Bereich von 0-255, der auf 0-100% abgebildet wird.
Damit ist dann z.B. 87% = 87/100*255 = 221.85 und wird als 222 auf dem Bus gesendet. Die Rückrechnung in % ergibt 222/255*100 = 87.05 und wird als 87.1% ausgegeben.

Letztendlich musst du nicht runden, damit Du Buslast reduzierst, DPT 5.001 ist immer ein Byte.

Gruß, Waldemar

[knxPaul]

Das liegt an der speziellen Definition des DPT 5.001: Es gibt 255 Werte für den Bereich 0 bis 100 %. Das sind keine ganzzahligen Prozentwerte wie beim DPT 5.004 sondern 255 Werte im Abstand von etwa 0,4 %. Also höhere Auflösung erkauft durch den Verlust an exakter Darstellung von ganzzahligen Prozentwerten.

[araeubig]

nicht runden

Danke für die Aufklärung. Das Runden passiert ja in der Logik, so dass nur ganze Zahlen gesendet werden (diese natürlich als ein Byte) und nicht auch alle Zwischenwerte.

[araeubig]

Habe die Logik nun dementsprechend angepasst und nun generiere jetzt Helligkeitswerte mit 3 Nachkommastellen - diese sende ich bei einer Mindestdifferenz von 1 auf die GA und nun sind die Werte auf der GA mit DPT 5.001 "annähernd" wie in der Logik.

Manchmal sieht man den Wald vor lauter Bäumen nicht. Danke für die Hilfe bzw. das "Es hilft den Datenpunkttyp genau im Kopf zu haben".