Audit log shows tag write value

When writing a small decimal value, e.g. 0.03, to a float/double tag to an allen-bradley new PLC (L81 if it’s relevant), this value shows as 0.03 in the tag value, but in the audit log, it shows as 0.0299xxxxx. I realise that this is probably due to floating-point inaccuracies, but is there any way around this?

Also, when using Vision touchscreen mode, the default value presented when it’s brought up is the 0.0299xxxxxx number, and operators are really confused when they set it to 0.03. To me, this part is a bug

image

Should we be using integers with scaling instead?

That looks like what happens when a 32-bit float is stored in a 64-bit float. The 64-bit storage thinks it really has more significance, so it renders more digits.

I just checked a manual and these are the available data types for allen-bradley. We’re using FLOATs (looks like these are 32-bit, no 64-bit variety):

I don’t think you can get around this, no. Auditing ultimately has to coerce the value into a string somehow, and any rounding would be explicitly less correct than the most exact representation possible. Playing with https://float.exposed/0x3ce56042, I can reproduce several of the long decimal strings you have exactly.

That I can probably agree with - at least for numeric controls that have a format string, we should at least attempt to use that for the keypad.

2 Likes

Oh, I see why we’re not using the format string/the most explicit type. Are you specifically dealing with numeric text fields? I see a possible tweak that could make it work better (if you change the field’s type to integer/long).

I’ll have to check, but what’s the tweak in either case?

To clarify - it’d be a tweak in our code, not something you can currently do as an end user.