# Audit log shows tag write value **URL:** \ **Category:** Ignition\ **Tags:** ignition80\ **Created:** [January 20, 2021, 10:50pm UTC](https://forum.inductiveautomation.com/t/audit-log-shows-tag-write-value/42464 "2021-01-20T22:50:22Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [January 20, 2021, 10:50pm UTC](https://forum.inductiveautomation.com/t/audit-log-shows-tag-write-value/42464/1 "2021-01-20T22:50:22Z")
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](https://us1.discourse-cdn.com/inductiveautomation/original/3X/e/2/e2070b5800bc476c7dc73ac3948ba68a815c833b.png) Should we be using integers with scaling instead? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 20, 2021, 11:13pm UTC](https://forum.inductiveautomation.com/t/audit-log-shows-tag-write-value/42464/2 "2021-01-20T23:13:46Z")
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. ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [January 20, 2021, 11:18pm UTC](https://forum.inductiveautomation.com/t/audit-log-shows-tag-write-value/42464/3 "2021-01-20T23:18:24Z")
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): ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/5/a/5aa9527973fe18cbf5670c7d01c130aebda89b1c.png) ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [January 20, 2021, 11:35pm UTC](https://forum.inductiveautomation.com/t/audit-log-shows-tag-write-value/42464/4 "2021-01-20T23:35:30Z")
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](https://float.exposed/0x3ce56042), I can reproduce several of the long decimal strings you have exactly. > [@nminchin](#): > > 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 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. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [January 20, 2021, 11:43pm UTC](https://forum.inductiveautomation.com/t/audit-log-shows-tag-write-value/42464/5 "2021-01-20T23:43:54Z")
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). ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [January 21, 2021, 1:24am UTC](https://forum.inductiveautomation.com/t/audit-log-shows-tag-write-value/42464/6 "2021-01-21T01:24:36Z")
I’ll have to check, but what’s the tweak in either case? ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [January 21, 2021, 4:52pm UTC](https://forum.inductiveautomation.com/t/audit-log-shows-tag-write-value/42464/7 "2021-01-21T16:52:42Z")
To clarify - it’d be a tweak in our code, not something you can currently do as an end user.