Ich habe einen RPC Client entwickelt, der sich für Events bei CUxD registriert. Die Übertragung und Dekodierung der Events von CUxD funktioniert auch. Allerdings nur bei positiven Werten. Negative Werte werden bei der Dekodierung verfälscht und als positive Werte interpretiert.
Wie kodiert CUxD negative Fließkommawerte? Bisher gehe ich von folgendem Format aus:
32 Bit Word: Mantisse (Vorzeichenbehaftet)
32 Bit Word: Exponent
Daraus baue ich den Fließkommawert dann so zusammen:
Mantisse / 0x40000000 * (2 hoch Exponent)
Codierung von Float Werten in RPC Schnittstelle
Moderator: Co-Administratoren
Re: Codierung von Float Werten in RPC Schnittstelle
Das sieht eher aus nach 11 Bit Exponent (inkl. Vorzeichen) und 53 Bit Mantisse (inkl. Vorzeichen).Skripdoku hat geschrieben:±1,7*10 ±308 , 15 signifikante Dezimalstellen
Versionen: HM-CC-TC 2.1, HM-LC-Sw1 1.9, HM-CC-RT-DN 1.1, HM-MOD-RPI-PCB 1.2.1 (keine CCU)
- uwe111
- Beiträge: 4821
- Registriert: 26.02.2011, 22:22
- Hat sich bedankt: 3 Mal
- Danksagung erhalten: 246 Mal
- Kontaktdaten:
Re: Codierung von Float Werten in RPC Schnittstelle
Alle sagten: Das geht nicht. Dann kam einer, der wußte das nicht und hat's einfach gemacht.
SPENDEN Download: CUxD 2.11, SSH KeyDir
SPENDEN Download: CUxD 2.11, SSH KeyDir
-
- Beiträge: 1796
- Registriert: 03.11.2010, 10:25
- System: CCU
- Wohnort: Aachen
- Hat sich bedankt: 58 Mal
- Danksagung erhalten: 261 Mal
- Kontaktdaten:
Re: Codierung von Float Werten in RPC Schnittstelle
@Paul53:
Bei BIN-RPC wird leider nicht die IEEE-Darstellung (11 Exp./52 Mant./1 Vorz.) verwendet. Warum auch einen Standard verwenden?
(Hinzuzufügen wäre noch, dass die Mantisse (nach der Division) immer größer gleich 0.5 und kleiner 1.0 sein sollte. Das betrifft aber nur das kodieren.)
Ein paar Testdaten:
0.0: [00, 00, 00, 00], [00, 00, 00, 00]
1.0: [20, 00, 00, 00], [00, 00, 00, 01]
-1.0: [e0, 00, 00, 00], [00, 00, 00, 01]
-10.0: [d8, 00, 00, 00], [00, 00, 00, 04]
Die Implementierung des BIN-RPC-Protokolls im CCU-Historian ist wohl vollständig (s.a. https://github.com/mdzio/ccu-historian/ ... itf/binrpc). Ich denke, dass ich die selben C-Quellen in der Hand hatte, wie sie auch die CCU verwendet. Es gibt z.B. zwei bisher nicht bekannte Datentypen (DATE und BINARY), die aber wohl nicht von der CCU verwendet werden.
Gruß
Mathias
Bei BIN-RPC wird leider nicht die IEEE-Darstellung (11 Exp./52 Mant./1 Vorz.) verwendet. Warum auch einen Standard verwenden?
Die Formel ist korrekt. Sie funktioniert auch für negative Mantissen. Eventuell liegt es an den Typkonvertierungen oder der Auswertungsreihenfolge.zap hat geschrieben:Mantisse / 0x40000000 * (2 hoch Exponent)
(Hinzuzufügen wäre noch, dass die Mantisse (nach der Division) immer größer gleich 0.5 und kleiner 1.0 sein sollte. Das betrifft aber nur das kodieren.)
Ein paar Testdaten:
0.0: [00, 00, 00, 00], [00, 00, 00, 00]
1.0: [20, 00, 00, 00], [00, 00, 00, 01]
-1.0: [e0, 00, 00, 00], [00, 00, 00, 01]
-10.0: [d8, 00, 00, 00], [00, 00, 00, 04]
Die Implementierung des BIN-RPC-Protokolls im CCU-Historian ist wohl vollständig (s.a. https://github.com/mdzio/ccu-historian/ ... itf/binrpc). Ich denke, dass ich die selben C-Quellen in der Hand hatte, wie sie auch die CCU verwendet. Es gibt z.B. zwei bisher nicht bekannte Datentypen (DATE und BINARY), die aber wohl nicht von der CCU verwendet werden.
Gruß
Mathias
Re: Codierung von Float Werten in RPC Schnittstelle
Danke für die Infos!
@Mathias: Die Beispiel sind sehr hilfreich. Muss ich jetzt mal testen.
Grüße
Dirk
@Mathias: Die Beispiel sind sehr hilfreich. Muss ich jetzt mal testen.
Grüße
Dirk
Re: Codierung von Float Werten in RPC Schnittstelle
Ich glaube ich habe es jetzt.
Problem: Die Perl Funktion zum Entpacken eines signed integers aus Binärdaten (unpack 'l') erwartet eine umgekehrte Byte Order. Wenn ich die vorher ändere, funktioniert alles. So wie es aussieht schickt CUxD die Daten nicht in "Network Byte Order".
Problem: Die Perl Funktion zum Entpacken eines signed integers aus Binärdaten (unpack 'l') erwartet eine umgekehrte Byte Order. Wenn ich die vorher ändere, funktioniert alles. So wie es aussieht schickt CUxD die Daten nicht in "Network Byte Order".