groupthink | Meteor bulletin-board style forum | Collaboration library

I've got an electricity meter connected to a DCS (distributed control system) by PROFIBUS. The meter (Siemens Sentron PAC3200) supplies its count as an IEEE 754 double in Wh (watt-hours). Also, the counter overflows at 1.0e12 Wh or 1,000 GWh. (Cutaway scene: Several years earlier, Siemens development labs. "Let's see, how to transfer a 40-bit unsigned integer value? Let's use double!")

My goal is to log the count consistently in kWh precision.

The DCS however only supports single precision floats. So if I took the direct route, i.e. squeezed the data into a float, then at about seven decimal digits errors would appear in the kWh reading, i.e. at the latest from about 100,000,000 Wh or 100 MWh. The current count is 600 MWh already, so this is no feasible way.

So for now, I put the mantissa into an unsigned double integer (UDINT, 32 bits on this platform) and perform the conversion according to IEEE 754, which yields the correct value in Wh. This however entails an overflow at 2^32 Wh or about 4.3 GWh, which will last us barely ten years.

Since I need only kWh precision, I had the idea of dividing by 1000 early in the conversion. This would put the variable overflow at 4,300 GWh, and the meter's internal counter already overflows at 1,000 GWh. Problem solved, in theory.

As IEEE 754 is a binary floating point format however, I can only easily divide by 1024 (right shifting 10 times), which introduces a substantial error. Multiplying with a correction factor of 1.024 afterwards would only ever happen in single precision on this platform, nullifying the previous effort.

Another option would be to output a "high" and "low" UDINT in Wh from the conversion, then I could at least in theory calculate back to kWh, but this seems awkward (and -ful).

I'm having the subtle feeling I may have overlooked something (single-person Groupthink so to speak); I'm open for any other ideas how I could obtain the 1/1000th of the transferred double value.

Thanks and best regards

Björn

P.S.: For your viewing pleasure, this is the solution based on @EricPostpischil's answer -- tailored to platform and task specifics. The language used is SCL (structured control language) as per EN 61131-3, which is kind of a Pascal dialect.