Clarifying error management

[rw2018]

Hello

I would be grateful for some feedback on my understanding of how to manage and use the error handling in VIs in LabVIEW 2017.

• The Error Clusters (e.g. 'Error in 3D.ctl) enable any errors to be caught during the execution of that particular VI.
• Any error caught in a VI is not passed through to the next VI in the data flow.
• The user can be informed of an error with a dialogue box by using either: i) the Simple Error Handler; or ii) the General Error Handler. If there is no error, there is no dialogue box.
• There is only need to have one 'error' path through the programme.

Thank you.

Ron

[TomMcQ]

Hi Ron,

When using LabVIEW, there are three main options when it comes to error handling these are:

1. Automatic Error Handling Disabled - Upon an error the user is not notified
2. Automatic Error Handling Enabled - Upon an error, the function that caused the error is highlighted and an error dialogue box is displayed
3. Manual Error Handling - Recommended - Using the error cluster we can wire the error through the code to a central error handler. Often the Simple Error Handler VI is used. By default this VI will show an error dialogue box.

When using manual error handling it is recommended to have case structures in your subVIs to change the behaviour when receiving an error input.

If you have more than one error wire in your code you can use the Merge Errors function to combine them. Often this would be used when there are parallel process happening in your code.

I hope this helps.

Cheers,

Tom

[Gregory]

---

@rw2018 wrote:

Hello

I would be grateful for some feedback on my understanding of how to manage and use the error handling in VIs in LabVIEW 2017.

• The Error Clusters (e.g. 'Error in 3D.ctl) enable any errors to be caught during the execution of that particular VI.
  • Error in allows an error to be sent into a VI. Often, you will want a VI to behave differently if there is an incoming error (perhaps doing nothing at all). You can put a case structure around most of your VI, with the error in as the selector terminal. 
  • Error out allows the error to be propagated out of the VI.
• Any error caught in a VI is not passed through to the next VI in the data flow.
  • That depends greatly on the VI. If you make the VI, it is obviously up to you what to do with it. If it is a LabVIEW primitive (yellow function off the pallet) then the error is usually passed through and the function does not operate, but you have to look at the help to see if it has "standard error behavior".
• The user can be informed of an error with a dialogue box by using either: i) the Simple Error Handler; or ii) the General Error Handler. If there is no error, there is no dialogue box.
  • That's true. And often that is enough for a simple lab application. When your users are on a production line or dealing with expensive / dangerous equipment, you will often want to take some action to put the equipment into a safe state. Also, logging the errors to a text file can save A LOT of time when someone comes to you and says "there was an error! can you fix it?"
• There is only need to have one 'error' path through the programme.
  • Larger applications will have many things executing in parallel all at once. For an application with a single loop perhaps, then I agree, one error wire running through the loop is enough. If you have VIs executing in parallel in the same loop, you will often want to use "merge errors" which actually only keeps 1 error, looking at the top-most error terminal first, then working its way down looking for an error. So if you have a main error wire, you would want that to be in the top input, and anything else that is lower priority into the lower inputs.

Thank you.

Ron

---

Hi Ron, you have a couple correct thoughts, and a couple misconceptions. My comments above in red. It is definitely good to be thinking about error handling!

[CFER_STS]

Using the dialog box VIs is just one way to handle errors.  You can customize this as much as you wish.

To implement standard error functionality in a VI you write, you take the error in and wire it to a case structure.  If there is an error, you pass it through the structure to an error out indicator, without executing any of your code.  This ensures that errors are passed promptly through even very complex code, minimizing the delay if e.g. you need to set outputs to safe states.  If there is no error in, then you wire that error through the code in your VI, making sure to capture any possible errors that can occur within your code.  This may involve a single error wire, or it may involve multiple branches and subsequent merges of the error wire. The point is to make sure that you capture all possible errors.  In a subVI, you typically pass such errors to an error indicator to be handled in a superior VI.  In your main VI, or a purpose-specific error-handling VI, you want to act on those errors.  This can be as simple as stopping the program and popping up a dialog, or as complicated as setting hardware outputs to safe states, timestamping and logging errors to file while simultaneously passing them to an error queue to be communicated over a network connection to an error handling program on another computer which executes a series of specific actions depending on what error occurred.

Either way, what you don't want to do is let errors occur unnoticed, or allow your VIs to do dangerous things if an error occurs.

[Gregory]

---

@CFER_STS wrote:

Either way, what you don't want to do is let errors occur unnoticed, or allow your VIs to do dangerous things if an error occurs.

---

All very well said, the last line reminded me of this: