LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Throw an error?

This seems silly that I'm unsure about this...but, what the right way for me to throw an error in my SubVI?  Is there a built-in VI I can use to modifity the error cluster to add my error?  Would it be prudent to not throw my error if a previous error already exists?  Hrmm...  do I just make up my own code and source?

0 Kudos
Message 1 of 7
(3,887 Views)

The easiest way is to make sure you have an error out indicator with a connector panel attached to it on your subVI.  Then right click on the error indicator on the block diagram and pick create constant.  Now you have an error cluster you can copy and move where you need it to.  Edit each instance of the cluster to show whatever error# you want, a True Boolean, and a description.  For no error, just leave the constant at its defaults.

 

Usually negative error numbers represent true errors, and positive error numbers represent warnings.  There is a range of error numbers intended for user defined errors, but I don't remember what that range is.

0 Kudos
Message 2 of 7
(3,883 Views)

You can use the cluster tools to modify the incoming error cluster.  You set the status to true, set an error number (NI has a series of numbers they recommend you use), and the name of the VI (or further description).  You can create error descriptions within the LabVIEW interface so when the error pop-up occurs, it gives your reason for the error.  I have tended to shy away from this approach, as the file sits in your LabVIEW directory, and not with your code.

 

I have NEVER run into a circumstance where it is advisable to replace an existing error in the error cluster.  Think of it this way:  Is the error in your VI the result of the incoming error?  Your code indicates an error in your VI even though the source of the error may not have anything to do with your VI.  The error cluster, in my opinion, should always indicate the first error that occurred.

 

In most cases, your code should probably not even run if an error occurs.  This can be solved by putting a case structure around your entires subVI's code and wiring the error cluster into the case selector.  If no error occurs, your code runs.  If an error occurs, you do nothing but pass the incoming error to your outoing error.  There are some cases where you do want the VI to run regardless of error state (closing a reference, for example).  In this case you should use the Merge Error.vi with the incoming error being wired to error #1, and your subVI's error into error #2.  This way, if an incoming error occurs, your VI still executes and does what it is supposed to do, but the Merge Error returns the incoming error first (even if your code generates an error).  If there is no incoming error, then your code runs and if it generates an error, the Merge Error will pass out your error.

0 Kudos
Message 3 of 7
(3,879 Views)

See

http://zone.ni.com/reference/en-XX/help/371361E-01/lvhowto/creating_user_defined_erro/

 

This also explains the code values you should use as well as creating a XML based file for the codes.

Now Using LabVIEW 2019SP1 and TestStand 2019
0 Kudos
Message 4 of 7
(3,869 Views)
Should I raise the status flag even on a warning?
0 Kudos
Message 5 of 7
(3,867 Views)
No.  LabVIEW automaticaaly assumes a warning if the code is not zero.  The status only indicates an error.
0 Kudos
Message 6 of 7
(3,865 Views)

Here are two VIs I designed for that purpose.

The Call Chain part was copied from OpenG.

 

Felix 

Download All
0 Kudos
Message 7 of 7
(3,836 Views)