ryank

I'm not sure of the exact mechanism, since I've never tried doing it using VI Scripting. In most cases when I write an Express VI, it's to create a reusable block of code that I can easily reconfigure, like this one, and not necessarily to make a hard concept easy to understand (which is what most of the built in ones are designed to do). Therefore, for my Express VIs, I'm okay with making the user call an init and a close if I'm managing resources (under the hood the init and close just operate on a functional global, and I can use a reference into the FGV to handle multiple sessions). For the SEH library, I did experiement for a while with allowing the user to call handler VIs for each error, either asynchronously or synchronously, but I took it out of the posted version because I was worried about the implications and because I intend to use this in RT systems, where arbitrarily spawning VIs to handle an error would be kind of a no-no . That is a nice example, although I agree that it would make a good XControl.

Hehe, just to clarify, I'm not in R&D (not that there's anything wrong with being in R&D ) and I didn't write and don't maintain any of the core LabVIEW Express VIs. I'm referring specifically to the Express VIs linked above, which I did write. The forum I was referring to is linked from the document that contains the example. I won't post a direct link, because I know some forums frown on that. And for the record, I think the elapsed time VI accepts fractional numbers, so you can do ms resolution waits with it, you just have to divide by 1000 yourself .

Sorry, didn't mean to side-track things . At one point I did have the ability to call a VI as one of the actions to take in the SEH, but I took it out because I didn't want to deal with all of the potential implications.

There are some tricks they use to get around having to re-open resources every time (basically they use VI scripting to analyze whether the VI is being called in a loop), but they're very tricky and still have performance implications. You are correct that the Express VI Development Toolkit is now part of LV Core. I haven't checked, since I always install professional, but the original spec suggested that it might be in Base or Full as well, you definitely don't need Dev Suite. I believe the transition occured at 8.6, although it's possible it was 8.6.1.

Fair enough, although I do think you need to consider error handling when you think about the requirements of the core. For example, if you've got a good centralized handler and an easy way to get things to it, the core doesn't necessarily need the capability for multiple errors.

That's why I differentiate between specific error handling, and central error handling. For my solution to specific error handling, and error categorization check this: http://zone.ni.com/devzone/cda/epd/p/id/6253

I go back and forth on this. While I'd love the ability to handle multiple errors, I'm also very concerned with performance (I do a lot of RT programming) and passing around an arbitrarily large object gets tough performance wise (not that the current string isn't already unbounded, but multiple errors would be aribtrarily larger ). There are a couple of ways you could remedy this, one would be to store a table in memory and then pass around indexes to the table (i.e. pass by ref). Another, and the one I use currently, is just to use some sort of central error handler that recieves errors through a queue or FIFO. You still have to be diligent in invoking the message to the error handler before you overwrite the error or miss a subsequent one though. Thanks for posting this, I unfortunately got dragged into a meeting and couldn't make the presentation, so I'm glad I at least got a chance to review the slides. One thing I'm curious about, have you done any type of comparison, performance wise, between some code implemented with this object based method and the same code with the traditional method? I've found its useful to try to characterize the performance of error handling both in terms of what it costs when there isn't an error and what it costs when there is one. Regards, Ryan K. NI Systems Engineer

About Express VIs in general: There is nothing inherent in Express VIs that requires them to do an init/destroy sequence. However, Express VIs that work with open resources (i.e. the assistants) do have to have some way to open and close those resources, since there aren't explicit open and close operations as you'd get when using a lower level API. Therefore, it all depends on the Express VI, which is a good mantra to remember when thinking about Express VIs. At run time they're really not much different from a subVI, most of the gripes people have with them have to do with the way that certain Express VIs are implemented, not with the technology itself. About the Specific Error Handler: The nice thing about having one as a reference library is that its open source. If you don't like what it does, then change it . Or better yet, post me a comment in the attached discussion forum so that I can make it what people want it to be . The Specific Error Handler does not need any initialization or cleanup. Most of the processing of the error configuration is done when you hit OK from the configuration dialog, not at run time. At run time, it stores a fairly simple list of errrors and actions, the only performance hiccup will be that it does have to do a search in the event of an error. At the moment, I haven't done a whole lot to optimize the search, since I don't expect individual instances of the VI to have more than a dozen or so errors handled, but if anyone starts using larger lists in and individual instance, I'd be interested to know about it and I can consider doing some more optimization. Regards, Ryan K. NI Systems Engineer

QUOTE (jdunham @ May 27 2009, 08:22 PM) 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.

This is a topic I've been experimenting with for a while. Basically, I've found it's insufficient to have just a central error handler or just a local error handler. I think you need to have strategies for both. If you do just central error handling, it becomes difficult to do things like retry an operation, because it requires a lot of code for the central error handler to communicate with the specific section of code that threw the error. You also have to deal with the behavior of other code as you pass the error around, which is difficult, because different VIs and APIs treat incoming errors in different ways (which means that for any sufficiently complex secton of code, the behavior on an incoming error is essentially undefined). If you do just local error handling (I use the term "specific"), you end up calling dialogs or accessing files from loops you probably shouldn't be accessing them from (I do a lot of RT programming). My strategy has been to create a specific error handler which you call after each functional segment of code (which can be a loop iteration, subVI, or something more granular), and which can take actions based on specific error codes that happen in that segment (much like exception handling in other languages like Java). The specific error handler can take actions like retrying code, ignoring the error, converting it to a warning, or categorizing it. Ideally, the concept is that at the end of any functional segment of code, the errors from that segment have been handled if possible and categorized if not. You can then avoid passing them to other segments of code to get around the problem with undefined behavior that I mentioned before. For usability's sake, my specific error handler is an express VI that lets you configure a list of error codes or ranges and actions for each. 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). A categorized error feeds into the central error handler (you can pass them with queues, events, FGs, or whatever you like), which can take actions based on categories of error. Each error category can take multiple actions, examples of actions are notifying the user, logging, placing outputs in a safe state, and system shutdown/reboot. Of course, there is always the case of an error code you've never seen before, which I usually treat as a critical error that puts the system in a safe state, logs, and notifies the user. At some point I'll get the kinks ironed out of my code to the point where I feel comfortable posting it (at that point it will probably show up as a reference design on ni.com), but I think the concepts are solid no matter what implementation you use. Regards, Ryan K.