LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
X.

Support Extended Precision for Wire Values in Debug Mode

Status: Completed

This was addressed with a bug fix in LabVIEW 2020 SP1.

I am probably the only one to be using Extended precision numbers considering the feedback on these requests:

 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-graphs-to-display-extended-type-values-i-e-creat...

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-All-LabVIEW-Supported-Number-Types-in-Formula-No...

 

but so be it.

One other area where LabVIEW ignores extended precision is wire values in debug mode. To illustrate what I am talking about, consider this snapshot of a debugging session:

 

ScreenHunter_001.jpg

 

The result of my modified Bessel calculation (that reminds me I haven't suggested to implement special function calculation in extended mode...) returns a perfectly valid extended precision number, such as 5.03E+418, but LabVIEW doesn't recognise this as a valid value and returns an "Inf" value (which would be the correct reaction if the wire could only display double precision floating point values).

This wire is connected to the logarithm primitive, which happens to be polymorphic and hence accepts the extended type. The result is the correct logarithm of 5.03E+418, i.e. 964.15.

On the face of it though, it appears that the output of my VI is +Inf, and that LV went wahoo and estimated an arbitrary value of log(Inf)...

My code actually stores such values in shift registers, so when I debug problems with the code, I have 3 or 4 wires carrying an "Inf" value, which, when I am trying to understand the reason of overflow problem, is not exactly helpful.

 

Suggestion: display Extended Precision wire values correctly in debug mode.

 

7 Comments
ToeCutter
Active Participant

I would almost go as far as to say the current behaviour is a bug.

 

You'll never get enough support for this in idea exchange - but maybe a bug report will be considered? Interested to see what an NI official makes of this if they see the thread.

crossrulz
Knight of NI

I agree that this is a bug.  I rarely ever look at the values coming out of highlight execution anymore.  That's what probes are for.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
X.
Trusted Enthusiast
Trusted Enthusiast

@ToeCutter: not sure it is a bug, since, as I mentioned, NI seems to not have considered it useful to properly display EXT values in most cases. I think it is a deliberate choice.

 

@crossrulz: I appreciate the feedback, but I have ~20 left-to-right propagating wires in this VI. Are you suggesting it is practical to use that many probes? I didn't think so either...

RavensFan
Knight of NI

@X. wrote:

@crossrulz: I appreciate the feedback, but I have ~20 left-to-right propagating wires in this VI. Are you suggesting it is practical to use that many probes? I didn't think so either...



No. Probes wouldn't be that practical to use in this case.

 

What would be nice is Attached Probe or Block Diagram Indicator  (just hoping to get more support for this idea.)

 

I did kudo your idea because I believe the highlight execution wires should more accurately reflect the data they are carrying.

crossrulz
Knight of NI

No, X, that isn't practical.  I admit that probes have their limits.  And I did give this idea a kudo as soon as I made that post.  This is something that should be fixed.  I just think it will turn into a CAR.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Christina_R
Active Participant
Status changed to: In Development
 

Christina Rogers
Principal Product Owner, LabVIEW R&D
Christina_R
Active Participant
Status changed to: Completed

This was addressed with a bug fix in LabVIEW 2020 SP1.


Christina Rogers
Principal Product Owner, LabVIEW R&D