Both variables are number inputs that get populated from a button trigger.
Whenever the trigger is executed, the number value spits out more significant figures than it has been set to.
Both Quality Index (Lower & Upper Limits) variables have been set to Decimal setting '1.00" for 2 significant figures, but the table record consistently stores 3 sig figs.
Thanks for any help!
Hey @gentleboyjones -
The widget property for precision just adjusts how values are presented within the app editor, but doesn’t actually impact how that data is stored in the table itself. So regardless of that setting, all numbers are stored to ~9 decimals. The tables UI shows all numbers to 3 decimals, but if you pulled table data from a csv export or over the API, you would see all of those decimal places.
There is a feature request in the works to be able to control the decimal places throughout the data pipeline. While this feels like it should be a super quick change, there is a fair bit of engineering work on the backend to make this possible. One option currently to force a consistent number of decimals is to store that value as text using the TOTEXT expression function and TEXTTONUMBER function (if you need to convert back to a number).
Thanks for the patience!
Pete
Thanks, Pete. I’ll keep that in the back of my mind. (y).
Hi Pete, working on splitting device output data text string into the test value and Unit of Measure, then storing the numerical test value as a number, but TEXTTONUMBER is dropping the trailing zeros which are (potentially) significant digits. Any suggestions?
@jmlowden, good question. Try appending the ROUND() function before TEXTTONUMBER() for the number if 0s you need. If it still drops the 0s let me know and I can do some sleuthing to see if there’s a trick.
Also seeing that when I write the numerical data variable to a table, it is only saving three decimal places…
UPDATE: which I realize Pete explained above, just missed it first pass - the csv download has the same digits as what I am able to see in Player, but still dropping the terminal zeroes
I added the ROUND() function a suggested and even tried adding +1 to the second term in the function, but the output remains the same.
@jmlowden, I checked in with our product team on this. This is a known gap, and we have several projects in motion to address this. No hard delivery date right now but it is something we’re aware of and working on.
