04-03-2014 03:18 AM
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.
Solved! Go to Solution.
04-03-2014 04:29 AM
04-03-2014 04:58 AM
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!
04-03-2014 05:16 AM - edited 04-03-2014 05:19 AM
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.
04-03-2014 07:59 AM
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!
04-03-2014 08:14 AM