11-14-2012 08:52 PM
Up for grab, this easy bug (tested in LV 2012.0f3 (32 bit) on Windows XP)
From a clean start, create a new VI, drop a "Power of x" function and create control for all input and output. Set the representation of the controls/indicators to be "Extended" (I do that for "Y" first and then the other one are automatically created with the corect type). You get this:
On the FP, enter 300 for Y and 0.01 for X and run the VI (you expect a result of zero).
Just for fun, set the Display Format of the output (x^y) to Scientific just to check whether there is no hidden digit somewhere.
Well, surprise!
Here is what I get first:
Then, after pressing OK:
and after Cancel:
The VI is password protected, so I ended up my little experiment here.
Note that if you set the Display Format of x^y BEFORE you run the VI, there is no problem at all. However, once you have run it once, the dialog will pop-up at all times. This does NOT prevent you from changing the format, but it is annoying at the very least...
I tried it with Exponential as well, trying a value of X = -1000 (you expect again a result of zero), to the same effect. It sounds like an underflow of some sort.
There is no such problems with type Double.
Comments welcome.
11-15-2012 05:03 AM
@X. wrote:
Comments welcome.
Ignoring for a moment what the actual problem is, I think the sequence of events is fairly simple:
11-15-2012 11:14 AM
You're right that this is an internal dialog from Format Into String, which had recently been identified as CAR 339791 (filed against LabVIEW 2010). The property page VI already has auto error handling disabled, and wiring the error output will not suppress the dialog either.
The root cause seems to have to do with the EXT number being outside the precision of a DBL. Since the indicator string displays are limited to DBL precision, we get a funky wide display format that looks like zero for the very small nonzero result.
I see the same behavior in 2011, and assume it existed at least as far back as 2010.
11-15-2012 11:44 AM
Actually I think the fix for that CAR may not cover this behavior, so I created CAR 379095. One workaround is to convert to DBL before any indicators. That will avoid those corner cases and still give you as much display precision as you would have otherwise.
Jim
11-15-2012 11:49 AM
Is this EXT control/indicator precision limited to that of double documented anywhere?
11-15-2012 11:52 AM
11-15-2012 11:54 AM
Thanks for the link. I remember this discussion now. However, if I understand it correctly, this "feature" is NOT documented anywhere in the Help. Hence my question (to NI). Mind you, some people care!
11-16-2012 08:26 PM
Note added: this problem also arises when trying to change the format of an EXT CONSTANT.
If you create an EXT constant and type in, say 1E-400, you will end up with a zillion zeros. Try formatting the constant and you will get through these hoops. And eventually end up with the same meaningless result of 0 anyway, since the above value goes below the minimum DBL value.
Oh well...
08-02-2013 12:12 PM
CARs 379095 and 339791 discussed in this thread has been fixed in LabVIEW 2013. For a more complete list of bugs fixed in LabVIEW 2013, check the LabVIEW 2013 Bug Fixes. You can download an evaluation copy of LabVIEW 2013 at http://www.ni.com/trylabview/ or if you have an earlier version of LabVIEW installed and an active SSP subscription, you will be able to download the latest version of LabVIEW through NI Update Service.
Jeff Peacock
Product Support Engineer | LabVIEW R&D | National Instruments