Advanced Error handling

[San_Punt]

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.

[Sam_Sharp]

It sounds like your question is more about how to test your software that errors are captured and handled correctly rather than how to actually implement the error handling...which boils down to testing your application.

Obviously it's quite difficult to capture and handle *every* single distinct error that occurs in your software but there are probably some errors that are more likely to occur such as:

- unable to initialize a device
- connection to device lost (while running)
- etc.

One thing you could do is 'simulate' the errors at different stages of your application by using (conditional) disable structures (for example) - you could replace your hardware SubVIs with an error constant (or a SubVI that generates errors) for the errors you want to test for.

You will also need to test that your error handling strategy handles unknown errors as well (which could occur at any time).

There are a few interesting presentations on the topic:
http://www.themoehrings.com/wordpress/wp-content/uploads/2010/12/LabVIEW-Exceptions.pdf
http://lavag.org/index.php?app=core&module=attach&section=attach&attach_id=537
There was another one that I tried to find that talks a lot about error handling but I can't find it - I think it was an NI Week session or something!

[San_Punt]

Hi Sam,

Thanks for the reply!

Indeed, It is about the capturing and handling of the Errors. I already have a design structure for handling of the errors, which catches every error.

At this moment I am trying to sort the most important/ likely to occur errors, just like you already said. For the unknown errors there is a default action: Restart the system, or else give a call. As I am making progress, I am finding and implementing  more errors and their specific actions to solve them.  Though I thought there could have been some sort of general approach to be sure to catch most errors up to a certain level, since I am pretty sure I am not the only one with this problem.

I think your links are very valuable, and I most definitely appreciate that you shared them.

Much obliged!

[.aCe.]

I understand you are trying to preempt the error codes but that as pointed out previously depends on your system.

I found this library http://www.ni.com/example/31253/en/ after doing pretty much what you did, implement my own errorhandling with lot of the functionality that this library provide off the shelf. It also allows you to define a range of error codes to trap etc. which may be useful in your case.

[Sam_Sharp · Accepted solution]

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!

[San_Punt]

Great, this is what I was looking for. thanks both for replying to this topic, I learned a lot from it; definitely an eye-opener.

Keeping all of this in mind, I am going to continue expanding the application and continue my hunt for errors.

Again, Thanks alot! Have a nice day.