NI Home > Community > NI Discussion Forums

LabVIEW Idea Exchange

Showing results for 
Search instead for 
Do you mean 
Announcements
We've turned on a search before post feature in the LabVIEW Idea Exchange. This new feature will help cut down on the number of duplicate ideas in this space!

The NI Idea Exchange is a product feedback forum where NI R&D and users work together to submit ideas, collaborate on their development, and vote for the ones they like best. View all of the NI Idea Exchanges to post an idea or add your opinion on an existing one today!
X.

error output instead of error code output

Status: New
by Active Participant X. ‎04-28-2012 02:33 PM - edited ‎04-28-2012 02:40 PM

It's got to be a duplicate, but I could not find it...

A significant number of vi.lib VIs are still outputing error codes (I32) instead of an error cluster.

For instance, the famous Ramp.vi:

 

ScreenHunter_002.jpg

 

returns an error -20006 if you ask for zero samples. Type in this value in the "Explain Error..." window of the Help menu and you get:

 

ScreenHunter_003.jpg

 

So it's not that the error code is mysterious and cannot be interpreted (I must say I was a bit puzzled by this discussion on error codes).

NI has to fight with this problem themselves. For instance, here is the code you find in the NI_AALPro.lvlib:AAL Resample Filter Prototype Design.vi:

 

ScreenHunter_004.jpg

 

What is that "?!+Magnifier" VI , you'll ask (AAL Error Information.vi, in the same library mentioned above)? I am probably supposed not to post it, but I will nonetheless, considering what it REALLY does:

 

ScreenHunter_005.jpg

 

Yep, it simply returns the same numeric error code value (again) and the call chain for the VI generating the error (but it won't tell you that the real source is the DLL called in the "Kaiser" VI above). I assume (but I can't prove) that the codes returned by the analysis library are among those recognized by the Explain Error VI.

 

It is not only an annoyance to not be able simply connect VIs using an error cluster wire, it does not make error handling particularly easy (basically, the way I read the answers of Aristos Queue and Norbert_B in the thread I quoted above is: "reverse engineer our VIs if you really want to 1) get the complete list of error codes it can output, 2) understand their cause").

 

My suggestion: Hire a couple of interns to sift through NI's VI librairies and change error code outputs into error cluster outputs with proper messages.

 

Obviously, for compatibility reasons, open previous code with an added unbundle primitive which will return the old error code (with a list of warning after the first compilation). You've done that before and we have survived.

 

 

Comments
by Trusted Enthusiast on ‎04-29-2012 11:35 AM

It's a good suggestion, but in the meantime, you do know about Error Cluster From Error Code.vi, right?

by Active Participant X. on ‎04-29-2012 11:52 AM

Sure, but it is bulky. The guy who worked on the Analysis VIs I used as an example apparently did not, BTW :-) [or they were developed before that VI was released].

by Trusted Enthusiast ‎04-29-2012 11:52 AM - edited ‎04-29-2012 11:54 AM

Strike my previous comment about this being a good suggestion. I thought you just wanted to return error clusters instead of error codes and have the call chain lead to the Kaiser VI. You actually want to output string messages. Ah. No. That's a bad idea. It would make error reporting on FPGA impossible and on RT it would introduce jitter. It would not be after-the-fact localizable (i.e., the result returned on a French system could not be interpreted for an English user, or a Japanese user, etc).

 

Any individual error cluster does have the ability to attach additional information to that stored in the error code database or to override the error code database entirely, but it does so with the penalties noted above. Thus VIs that are core parts of LabVIEW avoid doing this unless backed into a corner (i.e., translation of a .NET exception into an error code cluster does not have a unique code for all possible .NET exceptions).

 

> [or they were developed before that VI was released].

 

Likely this.

by Trusted Enthusiast on ‎04-29-2012 12:04 PM

By the way... bulky? It is barely doing more than the Analysis library VI that you posted, and it addresses a couple of bugs that I see in the Analysis VI (propagation of upstream warnings, for example). About the only thing extra it does, on desktop, is fish out the VI Title so that the localized name of the VI is displayed instead of just the file names that you get from the Call Chain.

by Active Participant X. ‎04-29-2012 01:31 PM - edited ‎04-29-2012 01:36 PM

I thought you just wanted to return error clusters instead of error codes and have the call chain lead to the Kaiser VI.

Yes, that's obviously what I suggested. Not sure how you got the "String Message" thing from...

The Error Cluster From Error Code.vi is unwieldy because it does not provide an easy way to get the call chain (which is probably why the AAL Error Information.vi was introduced):

 

ScreenHunter_004.jpg=========>ScreenHunter_005.jpg

Unless I am missing something, there is no way without some significant code, to figure out the source of the error and as I remembered, the VI does actually not return the error message (the cause of the error, see my original illustration) either...

 

PS: And stop saying my ideas are bad! :-) It influences PC/easily-influenced/authority-respecting people out there who won't dare vote for the idea just because of that.

by Trusted Enthusiast ‎04-29-2012 08:49 PM - edited ‎04-29-2012 08:50 PM

> into error cluster outputs with proper messages.

 

I took this to mean you wanted messages to be in the error code cluster instead of the error codes. Kudos restored.

 

> PS: And stop saying my ideas are bad! :-) It influences PC/easily-influenced/

> authority-respecting people out there who won't dare vote for the idea just because of that.

 

Hah. I take you for one of the high-authority folks that people respect. Your commentary is generally of a very good quality, and you're good at rallying forces. :-)

Latest LabVIEW Idea Exchange Blog Posts
About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Idea Statuses
Top Kudoed Authors
User Kudos Count
58
48
46
36
36