Thoughts on central error reporting?

[8bitbanger]

Hi Folks,

I'm working on a medium-large sized aquisition and control project, utilizing a QSM structure. I know there's a love/hate relationship with this, but so far it's been moving smoothly. 

Anyway I'm looking for thoughts on how to approach error reporting from multiple 'threads' to display and handle. As it is now, I queue these messages up to main for processing - unique errors are displayed in a listbox. Should I attempt to program in handling for every conceivable error? Queue back a 'response' function (ie stop acquisition, etc)?

What have you done in the past to handle general/unexpected errors that you haven't pre-programmed in (ie if an Error 7 is reported for a file operation, you catch this and prompt the user for another file)...

I hope this is coming across right - I thought about possible building a queue of errors, then offering them for individual handling to the user(?).

Happy wiring,

Jamie 

[Logan_H.]

Hey Jamie,

To program a different reaction for each possible error code seems like a nightmare! My suggestion would be to use the General Error Handler VI to take in the error code and output the error code's message into a Dialog Box where the user can decide to continue or quite. If there are a few errors that you specifically notice and want different reactions then all of these could be put into a Case Structure that performs these tasks for each specific error code.

Logan H

[Ben]

I have re-use code caleed an "Event Logger". We use it in 90% of our apps to log errors and is used as shown here.

The blue icons that have a warning icon and a scroll show it in use. Once launched (see rocket ship icon) it runs in the background until told to close (see "exit", yes this code dates back to LV 6 when string cases where all of the rage).

It creates a file when started and logs all errors to the file. My co-workers love it because they can get a phone call from a customer from a year ago and use the error log to tell the customer exactly what the problem was.

The Event Logger does not mean we don't care about errors. We still have to code to handle the expected errors (File not found etc.) so you still have to do that work.

So that is my 2 cents worth,

Ben

[8bitbanger]

Hi Ben - thanks for the suggestion. I haven't coded the log-to-file function in yet, but I do intended to (it would be collected in a TDMS run-log). An example of what I have so far is listed below. The buttons to the right are not functional - just some future thoughts carried over from my HMI days.

 

The two errors (from disconnecting LAN cable), show a bit of custom 'handling - I use a case select in MAIN on the error# to append a 'human-readable' message to the bottom, "...check cabling".

You can see that it 'collects' or groups errors with the same error# - the conundrum is preventing the program from continuously reporting the error. In the ACQ code portion, the state machine simply 'blows though' execution, and if an error is present from the state, it queue's it to MAIN for display. To prevent multiple errors *of the same code* from being re-reported seems easy (crudely: within ACQ, use a shift register for last error, if same error is still present, don't queue to MAIN). However for multiple different errors? This is where the thought of a queue of errors came to mind.

Happy wiring,

Jamie

Message Edited by 8bitbanger on 05-27-2010 07:06 AM

[DFGray]

I like to use a "current status"/"last error" approach to my error window.  Here is an example from the NI-SCOPE Soft Front Panel.

 

This is rather simple, since the SFP does not have error logging.  However, it demonstrates how to show the last error without staying in an error condition.

I prefer to handle errors locally in the module/object, but report and/or log them through a global module/object.  I usually create some sort of error server to receive and log messages, but the actually handling of the errors is done in the location they occurred.  If operator intervention is required to clear an error, the error message sent to the central server should be clear enough so the operator will take appropriate action.  You can set up a bi-directional communication system with the error server, should you need it.  User events probably work best in communicating to the error server; queues in communicating back to the error source (your user event for the error can contain a queue reference for response).

Good luck!