NI-Week Session: Advanced Error Handling in LabVIEW

[Anders Björk]

QUOTE (Aristos Queue @ May 26 2009, 11:47 PM)

Not generally. You have errors that arise from code where the only returned value is a number. No strings, no clusters, no booleans, just a number. They may be C built DLLs like the GPIB drivers. They may be DLLs built with LabVIEW VIs that are then returning just the error code. They could be log files where people just wrote down the number and are now reading it back in. There are tons of places where the only bit of data that is preserved is the integer. Because of the way that error codes get used by many users -- both internal and external to NI -- there's no way to have any migration path. Back in 2001, I spent a year working with CVI and TestStand and driver groups to find a migration path, and we ultimately determined that there couldn't be one, which meant that we needed to strengthen the protections of the NI Error Code Database to make sure that overlaps never occurred. That's when we started reserving error code ranges, so that two products simultaneously in development wouldn't accidentally grab the same number, or something like that.

And something very much like that is what I prototyped and posted to LAVA last year.

I meant that you should add new information (the new error code series) and for compatibility add the old code at the end of the source text eg. ":ENo:000-000-000; code 7", then with would have to live with that "old error system" used a "occupied" error code. Its translated wrong but it will less wrong by time. But thats for the layer were we have error clusters.

From my point of view the basic error handling should not be to complicated, but it does not give engough information as it is.

[jzoller]

QUOTE (crelf @ May 26 2009, 04:01 PM)

...Thoughts?

Just throwing out ideas: instead of the standard error cluster line, imagine a bounded size queue of error clusters.

It has the advantages of an array in that errors can be added or removed at will. It controls error size by being, well, bounded. And it allows you to commit code timing suicide by handling errors out of dataflow band .

Joe Z.

[danielsan]

Hi,

very interesting thread.

I started to implement an oop base error handling.

Basically it consists of an Error class that contains this attributes: error cluster, minCode (int), maxCode (int), isCritical (bool). Another Class called ErrorCompound contains just an array of Error Objects which are initialized with the right values (ie one for VISA, Daq, etc...). This gives me the flexibility to control which VIs should be passed in case of an error occurence (Database error should not result in loss of daq-control etc...)

Complex VIs are entered with the object ErrorCompound then the specific error clusters can be checked out to be given to less complex VIs that do only one kind of action (ie Database access). Errors occured are checked to the right object according to their code. This concept can be modified by the use of inheritance but for now I have no need for that.

Errors are handled mostly locally because I want to decide what should happen and in most cases I dont want the programm to run in the background. Only the logging is in central place.

Hope you got the idea...

Greetings,

Dan

[jdunham]

QUOTE (crelf @ May 26 2009, 03:01 PM)

One of the questions that has existed since man first used a LabVIEW error cluster is how can I make it scalable so I can have more than one error simultaneously. The next question was where do I put all this data? I've seen many different implementations, some concatenated their error structure to the "source" text field in the standard error cluster, some implemented a completely new system outside of the traditional error cluster (with appropriate converters to and from each system). The question is: which one is best? The former breaks less and required less retro-fitting of existing code, and can benefit from some of the existing error handling VIs that ship with LabVIEW, but it sometimes breaks when VIs misbehave and wipe the error cluster clean (yes, some primatives have been know to do it under certain circumstances). The latter is tempting because we can start from scratch and design whatever we want, but it requires integration into existing components that, by default, use the existing format is challenging. Thoughts?

We use the former approach, putting XML in to the error source. Then it is easy to detect whether the right XML is on the wire, and so what class of error we have. The XML contains the panel name (often different than the VI name), any custom error message which is on the block diagram which generated the error, the call chain, and any run-time data which is autoformatted with something similar to the VariantConfig library.

[crelf]

QUOTE (danielsan @ May 27 2009, 11:27 AM)

Hope you got the idea...

I sure did Do you have any example code you can upload?

QUOTE (jdunham @ May 27 2009, 11:45 AM)

The XML contains the panel name (often different than the VI name)...

Including the panel name is a great idea!

[ASTDan]

Dear NI

Please Please Please put this presentation on Tues or Wed in a big room.

[jdunham]

QUOTE (ryank @ May 26 2009, 02:10 PM)

I categorize errors by using the <append> tag in the source field, which keeps them fully compatible with all of the normal error handling functions (one drawback is that this requires string manipulation, which is kind of a no-no time-critical RT code, I haven't yet come up with an alternative I'm comfortable with though).

In our system, you can pass in a variant of whatever data wires you want and they are formatted into a string. However, by default this code, along with the code to grab the call chain, only runs if there is an error. There is no string handling unless there is an error thrown. Presumably if there is some kind of exception, need for real-time performance is probably over.

All that stuff would be so much easier if it were supported internally by LabVIEW. It would be great for NI to show some leadership on this and modernize the error handling system. This would really boost my productivity. Hopefully at the very least they will attend the NI Week session

[danielsan]

QUOTE (crelf @ May 27 2009, 04:51 PM)

I sure did Do you have any example code you can upload?

I will but it´s in an early stage so I´d like to test a little bit more...

[crelf]

QUOTE (ASTDan @ May 27 2009, 07:45 PM)

Please Please Please put this presentation on... in a big room.

Have you gained a little weight since I last saw you Dan?

QUOTE (jdunham @ May 27 2009, 09:22 PM)

All that stuff would be so much easier if it were supported internally by LabVIEW. It would be great for NI to show some leadership on this and modernize the error handling system. This would really boost my productivity. Hopefully at the very least they will attend the NI Week session

Don't worry - NI is definately coming to the party - we're talking to a number of NI folks about how to do error handling better.

QUOTE (danielsan @ May 28 2009, 03:07 AM)

I will but it´s in an early stage so I´d like to test a little bit more...

Great! If you don't want to upload it to the public forum, you're welcome to http://forums.lavag.org/compose-new-message.html&MID=181' target="_blank">PM it to me.

[ryank]

QUOTE (jdunham @ May 27 2009, 08:22 PM)

In our system, you can pass in a variant of whatever data wires you want and they are formatted into a string. However, by default this code, along with the code to grab the call chain, only runs if there is an error. There is no string handling unless there is an error thrown. Presumably if there is some kind of exception, need for real-time performance is probably over.

All that stuff would be so much easier if it were supported internally by LabVIEW. It would be great for NI to show some leadership on this and modernize the error handling system. This would really boost my productivity. Hopefully at the very least they will attend the NI Week session

I also suggest only doing the string manipulation in the event of an error. Actually, because of the nature of the specific error handling, I only do the string manipulation if there is an error that can't be handled locally and needs to be passed to the central error handler.

However, I disagree that the need for run-time performance ends when an error is thrown. I think this represents a common misconception about errors: that once one happens, normal operation goes out the window. There are many "normal" errors that occur during the operation of most large systems. Timeouts are a prime example, but there are also lots of other examples (buffer overflows, underflows, the FTP toolkit's brilliant idea of throwing a warning after every operation, the timed loop error that is thrown every time you programmatically abort a loop). I find that particularly in real-time systems where we tend to have less complex messaging schemes, errors are often the method of choice for informing the caller of any unusual status as a result of their request (for example, reading from an uninitialized variable results in a warning that lets you know that the value might not be a valid data point yet). Most of these should be handled locally (ignored or retried) but some should be logged and/or reported (buffer overflow is a good example). I find that of the errors I commonly encounter, there are really only a very small number (out of memory, some problems with the filesystem, corrupt or missing OS or driver files, a code you've never seen before) that actually justify a system shutdown or the complete suspension of normal timing and operation.

As for NI doing something about errors, I'll certainly post my specific error handler code as soon as I feel like it's ready, and Aristos Queue has already posted his embedded object error code. Eventually I suspect more tools will become part of the shipping product, but as this thread shows, it's far from a simple problem, especially since any new system absolutely has to support the overwhelmingly large number of VIs that rely on the error cluster.

I'll certainly be at the session, and I imagine other NI folks will be as well.

[ASTDan]

QUOTE (crelf @ May 28 2009, 10:44 AM)

Have you gained a little weight since I last saw you Dan?

I just want to make sure the room is big enough for all the people who are interested in hearing you talk... So it's just you and me at the bar huh? :beer: Remember you promised to buy me drinks if I came.

[crelf]

QUOTE (ASTDan @ May 28 2009, 04:28 PM)

Remember you promised to buy me drinks if I came.

You know, I don't remember saying that... but it sounds like something I'd say

[jdunham]

QUOTE (ryank @ May 28 2009, 07:52 AM)

Actually, because of the nature of the specific error handling, I only do the string manipulation if there is an error that can't be handled locally and needs to be passed to the central error handler.

Ditto.

QUOTE (ryank)

However, I disagree that the need for run-time performance ends when an error is thrown. I think this represents a common misconception about errors: that once one happens, normal operation goes out the window. There are many "normal" errors that occur during the operation of most large systems. Timeouts are a prime example, but there are also lots of other examples (buffer overflows, underflows, the FTP toolkit's brilliant idea of throwing a warning after every operation, the timed loop error that is thrown every time you programmatically abort a loop).

Per above you don't have to do the string manipulation if you still care about runtime performance. I was just saying that in most cases you don't. If I get a timeout error, then it's not too likely that I can still count on my control loop performance, but of course I can see other situations where it would be essential. "Timed out waiting for flight control system response, ejecting pilot...". Of course if you use the built-in error routines, it takes quite a bit of diagram space to avoid the string manipulation whether or not there is an error. This is really a problem best solved by NI.

QUOTE (ryank)

As for NI doing something about errors, I'll certainly post my specific error handler code as soon as I feel like it's ready, and Aristos Queue has already posted his embedded object error code. Eventually I suspect more tools will become part of the shipping product, but as this thread shows, it's far from a simple problem, especially since any new system absolutely has to support the overwhelmingly large number of VIs that rely on the error cluster.

Well I know it's a hard problem, but I remember presentations about the deficiency of the error cluster in NI Weeks from the 1990s. I've always been kind of disappointed there hasn't been more action before now, though better late then never, I suppose. Suggestions to the Product Suggestion Center seem to go into a black hole from the submitter's perspective. It's actually hard to know what I've already submitted, but I think I have put error suggestions in there in the past. For example, I think the Clear Errors VI is poorly thought out, since it wipes out errors you expect along with errors you might not have. It should have the ability to clear out specific error codes, and to check before and after errors around a specific block of code. Without that, it's a very dangerous routine, and I believe it should be deprecated.

Over the past few years I've spent a lot of time working on an error handler, and I know from other LAVA threads that most other advanced users have as well. It's just frustrating that so many man-hours have been put into fixing something that NI could have improved (with user feedback willingly volunteered) long ago. Thanks a lot to Chris for getting the ball rolling for NI Week. I wish I could be attending this year just for that.

Do you have a link to AQ's error handler? I thought I remembered seeing it, but Google was no help just now, nor did a search on ni.com yield anything useful.

[Aristos Queue]

For those who are interested: I have confirmed that this NI Week session is going to be in the largest room available.

QUOTE (jdunham @ May 28 2009, 04:41 PM)

Do you have a link to AQ's error handler? I thought I remembered seeing it, but Google was no help just now, nor did a search on ni.com yield anything useful.

Yes. But http://lmgtfy.com/?q=LAVA+error.llb+Aristos' rel='nofollow' target="_blank">here it is in a slightly snarky way... I hope you are as amused as I was...

[jdunham]

QUOTE (Aristos Queue @ May 28 2009, 03:59 PM)

Yes. But http://lmgtfy.com/?q=LAVA+error.llb+Aristos' rel='nofollow' target="_blank">here it is in a slightly snarky way... I hope you are as amused as I was...

Snarky is fine. :laugh: I searched for "embedded object" which ryank had mentioned, but that didn't help. I guess you posted this a few months before I started paying more attention to this site. I'll check it out.

[crelf]

QUOTE (ShaunR @ May 25 2009, 05:13 AM)

I use local error handling... Nice and simple and just plonk it in your error case of the state machine.

Care to share?

[crelf]

QUOTE (ASTDan @ May 27 2009, 07:45 PM)

Please Please Please put this presentation on Tues or Wed in a big room.

Looks like NI was listening - the preliminary schedule has this presentation on Tuesday the 4th at 4:45pm in room 16B (that's a pretty big room as I recall... anyone else remember? I always get room 14 and 16 mixed up).

[Aristos Queue]

QUOTE (crelf @ Jun 2 2009, 05:01 PM)

Looks like NI was listening - the preliminary schedule has this presentation on Tuesday the 4th at 4:45pm in room 16B (that's a pretty big room as I recall... anyone else remember? I always get room 14 and 16 mixed up).

As I said previously, yes, it's the largest of the presentation rooms.

[Bjarne Joergensen]

QUOTE (Aristos Queue @ Jun 3 2009, 12:24 PM)

As I said previously, yes, it's the largest of the presentation rooms.

Does this room has a video camera :camera: , so the unlucky people that can't afford to come to NI week, can see the presentation in the future?

regards Bjarne

[dannyt]

QUOTE (Bjarne Joergensen @ Jun 3 2009, 11:57 AM)

Does this room has a video camera :camera: , so the unlucky people that can't afford to come to NI week, can see the presentation in the future?

regards Bjarne

Yes that would be a great idea for us outside the US, please ..... please

[crelf]

QUOTE (Aristos Queue @ Jun 3 2009, 06:24 AM)

As I said previously, yes, it's the largest of the presentation rooms.

Sorry Stephen - I must have missed the post where you said that.

QUOTE (Bjarne Joergensen @ Jun 3 2009, 06:57 AM)

Does this room has a video camera :camera: , so the unlucky people that can't afford to come to NI week, can see the presentation in the future?

I figure there will be a lot of ideas that will come out of the discussion portion of the presentation, so I'll commit to putting together a recorded version after NI-Week to include the extra stuff outside of our structure discussed on the day, and post it here to this thread.

[ASTDan]

I figure there will be a lot of ideas that will come out of the discussion portion of the presentation, so I'll commit to putting together a recorded version after NI-Week to include the extra stuff outside of our structure discussed on the day, and post it here to this thread.

As a member in good standing of the South East Michigan LabVIEW user group could you post the presentation there also

[crelf]

QUOTE (ASTDan @ Jun 3 2009, 01:35 PM)

As a member in good standing of the South East Michigan LabVIEW user group could you post the presentation there also

But of course - if you remind me

[ASTDan]

QUOTE (crelf @ Jun 3 2009, 02:35 PM)

But of course - if you remind me

No problem just remember reminders are inversely proportional to standing in SEMLUG

QUOTE (Bjarne Joergensen @ Jun 3 2009, 06:57 AM)

Does this room has a video camera :camera: , so the unlucky people that can't afford to come to NI week, can see the presentation in the future?

regards Bjarne

Official NI week cam

http://www.sandiegozoo.org/apecam/index.html

[PeterB]

QUOTE (crelf @ Jun 4 2009, 02:30 AM)

I figure there will be a lot of ideas that will come out of the discussion portion of the presentation, so I'll commit to putting together a recorded version after NI-Week to include the extra stuff outside of our structure discussed on the day, and post it here to this thread.

Chris,

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.

cheers

Peter