Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

What is preferred way for creating custom instrument errors?

Solved!
Go to solution
I'm updating/improving an old instrument driver.  The instrument can create four instrument specific errors and warnings.
 
I know how to create custom errors, and which error codes to use.    But I just wonder what it the preferred method of supplying the error message that comes with it.
 
Looking the N.I. instrument drivers I've been using, I can choose between:
1.    Make an 'Error Message'  vi, that the user calls after using the instrument.  Then all custom error codes go in there.
2.    Directly attach the error message to the error code, when calling the 'error cluster from error code' vi within the instrument driver.  Then, you don't need to call a Err Msg vi, but it might take more programming within the driver. 
 
I see the first method being used in most drivers that's I've downloaded.  But the driver template from NI doesn't produce a Err Msg vi. In stead, the supplied Error Query vi seems to use the second method....
 
What would be the preferred way of doing things? 
0 Kudos
Message 1 of 2
(2,929 Views)
Solution
Accepted by topic author Anthony_de_Vries
This is a great question.  In an effort to sustain continuous improvement of LabVIEW instrument drivers, we are always considering the best methods to do things.  We incorporate new LabVIEW features that can improve the ease of use of instrument drivers.  The current NI recommended approach to reporting instrument errors is the approach you mention in #2, use the error cluster from error code VI to insert your custom error message at the exact place in the code where it occurs.  This also serves to better document your code.  You will see this approach used in our instrument driver templates and newer instrument drivers released in the past 2+ years.

Also, note that the Error Query VI is included to query and return errors from the actual instrument.  The method described above (your #2) is the recommended approach for inserting custom, developer-defined driver errors.

Message Edited by Jason Hobbs on 01-20-2006 10:12 AM

0 Kudos
Message 2 of 2
(2,924 Views)