LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

error handling basic

Hi all,

 

I need some help on basic error handling concepts.  Let me give you an example.  In a subvi, if the output is 25, I would like the system to show an error and perform an action.  What do I need to do to define the error code and to set up the post-error action (go to another section of code or exit program).  I am trying to avoid creating a error txt file, but I would like to see all the alternatives.  Thanks!

 

Yik

------------------------------------------------------------------

Kudos and Accepted as Solution are welcome!
0 Kudos
Message 1 of 9
(9,940 Views)

* You can add into the source string the Tag '<Err>', everything that follows will be shoen under Possible Reasons by the general error handler.

* If there is an existing error code for that condition, use this code, otherwisesearch for the User Defined Error Codes Range.

* To catch errors, you can just do a comparison of the error code or wire the error code to the selector terminal of a case structure and write a case for every code you want to handle.

* The general error handler can be called with the parameters 'no dialog', exception code = your code, exception action = 'cancel error on match' to clear specific errors. 

 

Felix 

0 Kudos
Message 2 of 9
(9,930 Views)

You can do this:

 

error.png

Tim
GHSP
0 Kudos
Message 3 of 9
(9,928 Views)

This is an interesting presentation given at NI week2009 on Error Handeling

 

http://lavag.org/topic/10741-updating-the-labview-error-handling-core/

 

 

Dan Shangraw, P.E.


   

0 Kudos
Message 4 of 9
(9,888 Views)

Should the <append> and <err> tags be unique in the source field of an error cluster ? may I have multiple err/append? I guess no.

Do I need to create extra vi to manipulate/edit the source field? for example to append an extra description to the already appended string.

 

The <err> basically redefine an error even if its code is already defined in the internal labview error database. Correct?

 

I if use both <append> and <err> I got a messy message (the append is in the source part of the error window)

 

So afterall the general error handler shipped with Labview seems to me quite limited in functionalities, expecially compared to the error handling of object oriented paradigm, where error is an object, and the object is an abstract concept that has nothing to deal with user interface and windows. Where labview has a huge fail in it's nature is that it does not separate datas from their visual rapresentation.

One thing is data.

Another thing is the object that will represent the data graphically.

When you place a control in labview , you use it as a variable. Variable = control

In the real world, in the 99% of languages, these concepts are separated, as they are indeed different!

 

So what you get by Labview is that you end up with EXTRA code, drawing, frameworks, just to do normal things like error handling! and this cannot be changed even in Labview 20.1

 

Now I'm going to check the "new" (dated 2009....new...lol) error handling with OO.

0 Kudos
Message 5 of 9
(9,723 Views)
This is an old thread, but I wanted to go ahead and answer these questions so the info is recorded for future searchers.

@Slyfer wrote:

Should the <append> and <err> tags be unique in the source field of an error cluster ? may I have multiple err/append? I guess no.


 

Only the first one will be detected. If you include multiple, the later ones will be displayed as actual text of the error message.

 

 


Do I need to create extra vi to manipulate/edit the source field? for example to append an extra description to the already appended string.


 

Not sure what you're asking here as far as needing an extra VI, but, yes, if you're going to add info to an error cluster created elsewhere, you would need to strip off any existing <err> or <append> tag before adding your own. Encapsulating that work in a subVI seems reasonable. There's no VIs that ship with LV to do this because, honestly, taking an existing error cluster and modifying it is pretty uncommon -- the usual pattern is to generate a brand new error cluster if you're going to pass a lower level error up to a higher level as a new error code.

 


The <err> basically redefine an error even if its code is already defined in the internal labview error database. Correct?


Correct.

The <append> tag adds additional information to whatever is already in the internal LV error database. Note that the "internal LV error database" includes user files written using Tools >> Advanced >> Edit Error Codes...

 


I if use both <append> and <err> I got a messy message (the append is in the source part of the error window)


See my previous comment

 


So afterall the general error handler shipped with Labview seems to me quite limited in functionalities, expecially compared to the error handling of object oriented paradigm, where error is an object, and the object is an abstract concept that has nothing to deal with user interface and windows. Where labview has a huge fail in it's nature is that it does not separate datas from their visual rapresentation.

One thing is data.

Another thing is the object that will represent the data graphically.

When you place a control in labview , you use it as a variable. Variable = control

In the real world, in the 99% of languages, these concepts are separated, as they are indeed different!


The GEH is the error display dialog. Seen in that light, it is not limited. The data of the error cluster is largely separate from the functionality needed to display the error. An exception object in C#, for example, includes the call chain, the message string, and a type. That's pretty much the same information that LV's error cluster contains. There's only one place that we have broken that separation, and that's in the ability to embed <b> and </b> tags in the source string to force bolding of some text. There are various debates about how that could/should have been added differently, but even if you go with a context-free <strong> tag (or something like that), it's still relevant to encoding the message to be displayed.

 

One statement really bothers me:

> When you place a control in labview , you use it as a variable. Variable = control

 

If you mean variable in the C/C++/C# sense of the word, then Variable = Wire.  Control = function static variable.

 

In LV, the FP control *is* the object that will display the error graphically. If you wish to build a new cluster (or class) that represents the display of an error cluster, go for it. An XControl that takes such a configuration as input would be relatively straightforward to construct.

 

 

 

 


So what you get by Labview is that you end up with EXTRA code, drawing, frameworks, just to do normal things like error handling! and this cannot be changed even in Labview 20.1


Actually, you might be amazed at what we think we can do in this area in future versions. 🙂 But it is not on the short term road map at all, so don't hold your breath. We are constrained by 25 years of design -- which was very good design when it was originally done -- and it takes time to set up the infastructure to adjust that.

Message 6 of 9
(8,702 Views)

If you took the time to futher update this thread, you could have posted a simple VI to solve the problem instead of trying to defend a system (Labview) that is sittin at 0.01% of world usage of software development (see http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html), and fails miserabily vs any programming language created after 1990.


Anyway, I understand that you need to take the cake home everyday so there's a need to spam informations to raise up posts count, sponsoring the "eco-system", "adding value", being a "jedi NI-Knight" and other ridicouls US-patented things
What community needs is code, because Labview is missing so much code in the API that it can compare to Fortran or Pascal. The VI I provide is solving some of the problems (you can "force" an err or append, OR you can append the additional err/append message) of the labview platform, but still:

 

  1.  to gain "error propagation" one needs to remember to draw error in/error out FOR EVERY single VI. No error in/out -> No error propagation.Guess what? Since 1990 this is superflous, it's a waste of time and error proning, because the object oriented methods of "error throwing" gain this "for free".
  2. this GEH is being kept constant since ages, I mean I follow LV since 6.1 and you made ZERO improvements to it. That's great, isn't it? Why should a programmer wait other 2 years?What we got here is just a modal window with little more than plain text and an icon (error or warning). Customize this (behaviour, look, etc...) is *hell*. And this is lasting for a decade.
  3. about "variables" (FP/wires), you are trying to raise a glass wall, but it's not my problem. I am not paid to demonstrate that what you are saying is wrong.
0 Kudos
Message 7 of 9
(8,665 Views)

Just to reiterate what Aristos Queue said about variables, and maybe add a bit: LabVIEW does not have variables for MOST intents and purposes. There are use cases for globals, locals, and shared variables (Caveat: I have no experience with shared variables), but for the most part LabVIEW code is variable free. You don't declare variables, and you don't read and write their values. I've seen programmers who cannot let go of variables, so they create front panel controls to hold values, and then read and write to them using property notes. This leads to race conditions because unlike text based languages, LabVIEW is inherently parallel. Using dataflow prevents race conditions.

0 Kudos
Message 8 of 9
(7,518 Views)

Aristos Queue said " the usual pattern is to generate a brand new error cluster if you're going to pass a lower level error up to a higher level as a new error code."

 

How I wish NI had a good application note on this! I just figured this out on my own. When I ask experienced LV programmers about this technique they always answer that this has been a standard approach. Now in hierarchies of libraries, classes, and applications I define new errors at each level and translate the errors to something meaningful at a particular level.

0 Kudos
Message 9 of 9
(7,512 Views)