06-20-2016 01:41 PM - edited 06-20-2016 01:43 PM
Hi ouadji,
I did the following:
- place a modern numeric control on the fp
- change its datatype to U64
- change formatting (display format) to "floating point" with 19 significant digits (!!!)
- change range to min=0, max=1e19, incr=1, all set to coerce (to nearest)
After this the U64 control does not accept values bigger than 1e19!
I guess the problem is with formatting the numeric display for such big numbers. There are many other threads describing similar problems when displaying numbers with a lot of significant digits!
06-20-2016 01:56 PM
06-20-2016 02:15 PM
@GerdW wrote:Hi ouadji,
I did the following:
- place a modern numeric control on the fp
- change its datatype to U64
- change formatting (display format) to "floating point" with 19 significant digits (!!!)
- change range to min=0, max=1e19, incr=1, all set to coerce (to nearest)
After this the U64 control does not accept values bigger than 1e19!
I guess the problem is with formatting the numeric display for such big numbers. There are many other threads describing similar problems when displaying numbers with a lot of significant digits!
Technically you are not correct. It's not the issue of formatting the numeric display. The converting 1e19 to HEX is 0x8AC7230489E80000. You can still enter numbers larger than 1e19 up to 0x8AC7230489E80400 and it still displays 1e19. What ouadji and Ben said is more accurate, the problem is that you are trying to set the maximum value of a U64 integer with DBL precision.
06-20-2016 02:18 PM
@GerdW wrote:After this the U64 control does not accept values bigger than 1e19!
This is where it gets even more interesting. The U64 control does not appear to accept values bigger than 1e19 but if you examine the underlying bits of the data value it is in fact accepting the value.
If you leave the formatting alone, then the Control will accept 1e19+1024, display that value, and it will match the underlying data.
If you change the formatting then the Control will change the display to be 1e19 instead of 1e19+1024, but it will no longer match the underlying data which is still 1e19+1024.
06-20-2016 02:24 PM - edited 06-20-2016 02:25 PM
Hi jamiva,
thanks for your comment.
Two notes:
1) After the steps described before I cannot enter a value bigger then 1e19 in the control - atleast the display coerces as expected to 1e19.
2) When displaying the value of the control in an additional U64 indicator it shows the value is not coerced and bigger then 1e19…
The result can be seen here:
So we have two problems in this combination: LabVIEW showing no respect to data range properties AND incorrect formatting for numeric display…
@Darin:
Your comment just came in while I typed (and prepared) this message…
06-20-2016 02:25 PM - edited 06-20-2016 02:29 PM
If you change the "increment" to "1" you can then place your cursor to the right of the LSD and then use the up/down arrows to increment/decrement.
otherwise...
Anytime the most plausible solution is actual two problems there is a large possiblity there is a bug crawling around.
Ben
06-20-2016 02:30 PM
So, is this a bug??
Simple workaround is to use the Coerce Function which works properly.
06-20-2016 02:35 PM
@jamiva wrote:So, is this a bug??
Simple workaround is to use the Coerce Function which works properly.
A Bug?
Who knows?
One of the challenges of declaring a bug in LV is identifying a situation where something does not work as per the specification. When there is no written specification it becomes a fuzzy challenge to convince NI that what WE expect is correct.
Without testing it, you coerce could in a filter value change event may be a work-around.
Now to tie it up in a nice little package.
If it isa bug, the chances that the bug will get fixed depend on how many people are affected and if there is a work-around.
Ben