NI-Week Session: Advanced Error Handling in LabVIEW

[crelf]

QUOTE (PeterB @ Jun 3 2009, 08:47 PM)

Greetings again from Magna Terra Australis (The Great South Land). I look forward to an archive of the presentation so I can continue my LV evangelism here at work with some authoritative backing.

Hallelujah cobber!

[crelf]

So I'm putting some work into the presentation, and I want to share an error structure that we came up with. Rather than the three elements in the native structure (status, code, source), we thought this was a great opportunity to expand that to include some of the items that we see all the time. Here's a idea that I'd like to present without comment, because I'd like to hear what you love/like/dislike/hate without me skewing your responses:

You've got the native three (so you can be backwards compatible), plus a few extras:

Time Stamp = when the error entered the error handling subsystem (or, alternatively, you can set this using a public method) so you can handle errors with respect to when they occurred.

Classification = categories: DAQ, UI, File, Database, VISA, etc

Priority = set a number here so that errors can be handled with respect to their priority.

Front Panel Title = notice that's the title, and not the name of the VI? Just so we can identify a VI that's either a dialog and/or had it's title dymamically changed. Ever had a situation where a user complains of a phantom error that they just clicked "OK" to?

CallChain = this is, we'', the callchain

Message = if you want something custom to be shown to the user once it gets to the general error handler, put it here

Custom Properties = a variant where custom things can be added as the variant's attributes (which are, conviently, variants themselves). Things like images (see Aristos' error module for an example) can be stuffed in here

[Aristos Queue]

Every item added to the error code cluster is a MAJOR increase in the size of every VI's memory footprint. I'd rather see a single Variant and have all of these be attributes of that variant. The allocation space in VIs would be SUBSTANTIALLY less. (Assuming you stay as a cluster... if it becomes an object, well, load it up as much as you want... the top level data size is just one pointer.)

[Michael Aivaliotis]

Good point Aristo. Is this an error object? Error class?

[crelf]

(Assuming you stay as a cluster... if it becomes an object, well, load it up as much as you want... the top level data size is just one pointer.)

Good point Aristo. Is this an error object? Error class?

You're right - I should have mentioned that it's an LVOOP object.

[Yair]

I would agree with the Error class way, but it should be a collection of errors. LV is parallel - we need a way to merge errors into a single wire without losing information. Once you do that, you can have the base error class with the items Chris suggested, but add specific data for specific error handlers (thus there's no need for the custom properties variant).

It would be great (actually, it would probably be a basic requirement) if LV was smart enough to coerce error wires into such an object, so that we have backward compatibility.

[crelf]

I would agree with the Error class way, but it should be a collection of errors. LV is parallel - we need a way to merge errors into a single wire without losing information.

Right - and that's what I'm working on - a base "error" class and an "errors" class that is a collection of "error" objects with some extra stuff thrown in.

Once you do that, you can have the base error class with the items Chris suggested, but add specific data for specific error handlers (thus there's no need for the custom properties variant).

You're right, but I haven't designed it that way for a couple of reasons: I'm under a wee bit of a time crunch, and I'd like this paradigm to be a community-driven effort after the initial paradigm idea is presented at NI-Week. I am toying with uploading a good chunk of the code here, but I don't want to derail my NI-Week preparation schedule with too much stuff.

It would be great (actually, it would probably be a basic requirement) if LV was smart enough to coerce error wires into such an object, so that we have backward compatibility.

Another great idea. I've created methods that convert native to verbose and vice versa (I'm calling the new structure a "verbose error" - anyone got a better name?), but it would be great if, sometime in the future, this process were to work automatically. That said, since we'd need to essential wire the verbose error list around native subcomponents to preserve the upstream error list, I'm not sure how this could be done without it looking a little icky. I like how the combine waveforms thingy is automatically added when you try to wire two waveforms into a log to disk express VI (or the like), and that technology might be an appropriate implementation to use, but this is all stuff that I'd like to talk about after NI-Week.

[Yair]

I'd like this paradigm to be a community-driven effort...I am toying with uploading a good chunk of the code

Which code? What I'm talking about is something that NI has to do. A direct replacement for the error cluster.

And yes, I'm aware they're not going to do anything about it soon.

[crelf]

Which code? What I'm talking about is something that NI has to do. A direct replacement for the error cluster.

Ummm, the code that I'm writing for the presentation... Yes, it'd be great if there was a central replacement for the current error handling schema, but I'm presenting a method of extending the current native implementation into something more comprehensive. NI doesn't have to do it, although I'm hoping that the result of my presentation will be community discussion and perhaps the design of a new schema that NI might want to adopt. NI certainly isn't against the idea of us helping them grow their product, and this is an opportunity for us to tell them what we don't like about the current implimentation and give constructive ideas on how to make it better - I figured the best way to do that was to build something ourselves that will either be leveraged directly by NI because of how awesome it is, be a catalyst for something else due to how okay it is, or be a warning on what not to do based on how crap it is.

[Chris Leyen]

This is my take on error handling

I use a FGV to store User event. On an error I generate a user event and pass the error to my event loop. In the dynamic error event case I have a state machine that can handle whatever error based on the error code, and then perform a custom action (i.e. shut down hardware, perform a certain action to correct the error, etc). I also log all errors generated to a text file.

This I have found works for me because the error dialogs are handeled in the event loop and I can still call other sections of code when the error dialog is displayed.

I am very interested in what other people do to handle their errors.

Dan

P.S. I hope NI gives you the big room for this presentation and doesn't have it at 4:00 on Thurs.

Dan,

How do you handle successive errors? My understanding is that you can only have one dynamic event at a time.

Why do you use a shift register on the Event Loop for the Dynamic Event wire?

Have you run into issues missing dynamic events?

Chris

[Michael Aivaliotis]

If this is an error class, then if we need to extend the error handling data to handle more stuff that you haven't thought of, we could create a child error class for our needs correct? So "Custom Properties" isn't really required I think.

[crelf]

If this is an error class, then if we need to extend the error handling data to handle more stuff that you haven't thought of, we could create a child error class for our needs correct? So "Custom Properties" isn't really required I think.

That's a good point.

[Aristos Queue]

That's a good point.

In fact, that's the entire point. :-)

[Rolf Kalbermatter]

Some time ago a published some application framework on the Dark Side; The error handling concept is scetched at the end of posting #2 and beginning of #3.

As far is I read the other posts, we all use events to pass the error data. Other ways of doing it?

Felix

Yes my error handling goes back to LabVIEW 5 or maybe even 4. So no events there. Instead I have a FGV that uses occurrences to do the event handling. The FGV has a method to initialize it, a method to post an event/error from anywhere, a method to poll the FGV, and a method to shutdown.

All those methods are wrapped in easy to use wrapper VIs that hide the complexity of calling the FGV completely.

A compromised overview what each method does:

start: create the occurrence, set the log path where all events/errors get logged, prepare the message buffer

post: it has two wrappers one trivial one to just log system events, such as when the application was started up or when a configuration was changed/save or anything else that might be interesting to protocol but does not indicate any form of difficulty/problem or such. The other wrapper is the most complex as it actually does all of the error handling VI and on first execution adding custom error codes from *.err files in a central location. The FGV method itself does format and add the message to the message buffer, does the logging to disk, and sets the occurrence.

query: its wrapper comes into its own loop on the main diagram that does use a wait occurrence to wait for an update, it also returns the contents of the message buffer as a string to display in a log string on the UI if desired. The most important thing it does is dsplaying a non modal dialog for all errors if the actual option is enabled. The dialog contains a checkbox to disable that option to prevent error dialog flooding. A boolean output indicates when the FGV has been shutdown to terminate the error handler loop too.

shutdown: sets the occurrence and the internal shutdown flag so the error handler loop will terminate properly.

clear: clears all internal buffers (optional step and not really necessary)

The addition of this to any application is fairly easy. It just needs a tiny little loop somewhere in the main VI and the initialization VI being called at application initialization. The event poster can be added anywhere and the error poster comes everywhere one would otherwise use the NI Error Handler VI. On terminating I call the Shutdown VI and the whole application terminates properly including the error handler loop.

Here is a use in a fairly simple application:

Rolf Kalbermatter

[crelf]

Just wanted to give everyone a head's up on the direction the presentation is going: yes, there are several layers of error handling, and we could discuss all of those layers for weeks so I've limited my 45 min session to the very core of LabVIEW error processing. I think building error handling modules on top of that core are vital (like several of those already mentioned in this thread) but we need to have a more comprehensive and flexible core first - and that's what I'll be presenting on. I really want this presentation to be a catalyst for further discussion and development of a new core, rather than an authorative lecture (I'll be presenting a couple of core ideas to get the ball rolling, but it certainly won't be a this-is-an-awesome-silver-bullet-that-will-meet-all-your-error-handling-desires presentation - in fact, I don't think either of the 2 paradigms I'm presenting are the answer to replacing the core, but I think they're steps in the right direction).

My current plan is to video the presentation and post it here the week following NI-Week, as long as that's okay with NI of course.

[TobyD]

My current plan is to video the presentation and post it here the week following NI-Week, as long as that's okay with NI of course.

Excellent plan

[Mark Balla]

For those planning to go to this session on Tuesday @ 4:45 it has been moved to Thursday

This email has been sent to notify you that Advanced Error Handling Techniques in LabVIEW has been moved to Thu, 06 Aug 1:00 PM.Your personal schedule has a conflict with this new time and you have been dropped as a registrant for this session.

For additional questions, contact niweek@ni.com

(888)564-9335

[TobyD]

I basically have the whole error/message logging encapsulated in a by-ref class.

Any chance that you would be willing to share this code? I'd love to look at it more in depth.

[crelf]

I've uploaded the presentation slides, audio and code in a new thread. I'm going to close this thread now - please continue the discussion in the new thread.