Advanced Error handling

Question

Hi all,
I am developing an error handling system for an extensive LabView application, unfortunately I can't  call it's purpose due to confidentiality.
I just graduated for my university degree in Applied Physics, and therefore I am pretty experienced with LabVIEW (got core 1,2 and 3).
The used synchonization technique is a queue-operated producer/consumer  handler. The testing set-up consists out of the following hardware:
- Keithley 2700 multimeter
- A Stanford SR830 Lock-in
- PI-Mercury 863 (Z-stage controller, for moving up and down)
- NI DAQ 6244
My Question is:
How can you make sure that you cover most errors with your error handling application? What would be a correct approach to find all possible errors that could occur during a measurement?
For example: I could disconnect the K2700 and start the application, then a VISA error is most likely to occur. Besides that I could disconnect the power supply of the hardware and start the application and see which error would occur then.
Is there some general kind of rule of thumb to find the possible errors which could occur in the set-up?
Thanks for your reply in advance.
Cheers,
San
Solved!
Go to Solution.

Answer 1

Aha! Found it: https://decibel.ni.com/content/docs/DOC-20726
I think that was the presentation that I was trying to find earlier as it gives some information about actual strategies for dealing with errors and reporting them versus just how to wire up error wires and the general error handler.
As for your reply, you need to think about grouping sections of code and say to yourself "what should happen if an error occurs here?". You will probably end up identifying gating points in your code (e.g. at the end of a case)
As a couple of examples:
- During initialisation, if a device fails to initialise, should you retry and if so, how many times before giving up? Should you let the user attempt to reconfigure the device
- If you're using a queue based architecture and the reference gets destroyed
You end up having to analyse your code and saying "What if....?" a lot!
I think the errors boil down to something like the following:
- Critical application errors: A terminal error caused by a software bug such as accidentally releasing a reference to a main message queue. In this case you have to shut-down the software but you should report or log some information to help you debug the issue remotely!
- Device errors: Failed to initialise, device not present, lost connection, incorrect configuration - the software can't operate normally but maybe you could keep trying to re-initialise or allow the user to try to change settings rather than exit the application.
- User errors: User has misconfigured something such as entered an invalid path or selecting an incorrect file (type, format etc.) - in this case you should probably notify the user and let them try again.
- Known errors: errors that you expect might occur such as creating a folder that already exists - these would usually be ignored or handled in a case structure. Another example of this is errors out of 'close' subVIs in your exit case (the device might never have initialised or may have already shut down)
You'll never be able to catch every single error (and it's not possible to see all errors a VI might produce and you may want to generate your own errors) but you should try to properly handle (& rectify) errors that are more likely to occur (such as lost connection to a device because someone tripped over a serial cable) and leave the other errors to your general handler.
You also want to think about the experience for the end user of your software - something that the presentation linked above mentions. Chances are that the average user isn't going to be able to understand LabVIEW error codes and will be disappointed if the software just shuts down on launch because a device is missing. 
There is no holy grail of error handling/reporting - it's something I'm always reading/learning about and try to apply that as much as I can in my applications!
Certified LabVIEW Architect, Certified TestStand Developer
NI Days (and A&DF): 2010, 2011, 2013, 2014
NI Week: 2012, 2014
Knowledgeable in all things Giant Tetris and WebSockets