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
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 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 Float Exposed, 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.
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).