Decimal precision is not correct about node-ethernet-ip HOT 4 OPEN

This is largely an issue with the PLC using 32-bit IEEE 754 floating point and Node using 64-bit IEEE 754 floating point.

Here is how Node stores 0.123456789 in hex (BE):
3f bf 9a dd 37 39 63 5f

Here is how the PLC stores it:
3d fc d6 ea

When the data comes into the EIP driver, it it's as a byte array. Then it's converted to a float. The bytes match. The issue is the conversion to a float. Node stores it as a 64-bit number and fills the rest with zeros.

3f bf 9a dd 37 39 63 5f - 64-bit rep of 0.123456789
3f bf 9a dd 40 00 00 00 - 64-bit rep of 0.123456789 converted from a float

Maybe a custom float conversion could be written to handle it, but it hasn't been an issue for me in practice.

You can get back to the original data and do the conversion yourself after the fact if you want.
If you take 0.12345679104328156 and write it to a buffer as a float, you'll get the original bytes back.
3d fc d6 ea

from node-ethernet-ip.

Interesting. Thanks for the insight. I'll have to look and see if there's a way I can do something in my script. The error, while very small, is actually a bigger deal for what I'm trying to do since I need to capture the exact value.

from node-ethernet-ip.

If you want to do that, you might be better off encoding it in a DINT.
Send 0.1234567889 as 123456789 and then divide by 1000000000 for the data.
Float/Real isn't the best for 'exact' representation, especially across systems with different representations.

Float/Real is typically okay if the binary error is less than your required precision, which doesn't sound like your use case.

from node-ethernet-ip.

Yeah that's exactly what I thought about doing.
To make it easier, I'm thinking a few different arrays. Maybe DINTX10, DINTX100, DINTX1000 to signify the scaling.

from node-ethernet-ip.