How do you deal with repeating errors? Here is an example:
-VI is communicating with a Shared Variable,
-Shared Variable is undeployed
-SEH is set to notify and Display a Pop-up to user with Error Message
-Every time the VI executes, an error message pops up (effectively locking up the screen)
Is this something that should be dealt with at the source (low level), or at the central error collector?
The SEH has some built-in error filtering that will avoid enqueing two of the same error at one time (it will count them instead and return it in the number of occurrences field), but once you dequeue the error, it can be enqueued again. In the past I've taken an alarm approach to the situation you describe, where I illuminate some element on my UI, and don't turn it off until some other condition occurs (i.e. the user explicitly clears it, I get a good reading, etc). This would be best handled by the central error handler.
Would you recommend integrating this with the DSC Alarm Manager functionality (utilizing the "User Defined Alarm" capabilities)? I am already doing this to notify users of Shared Variable alarm conditions (Hi, Lo, HiHI, LoLo, etc..) and to display (once) error messages from my RT Target. Would it be best to have ALL display of error messages go through the DSC Module?
Also, I see the "Number of Occurrences" counter you have as part of the SEH. Is there a way to check this without dequeuing the error? That way you could say "Don't Display if "# of Occurrences is >2" or something to that effect.
Yes, the DSC Alarm Manager is a great way of handling those alarms. As to whether I would use it for all error messages, it would really depend on the application. In an ideal world, I'd be inclined to use alarms for common failures, persistent conditions or things that I want to latch, and error messages for less common failures or messages that require more specific information (such as not finding a file, etc). However, in many systems, particularly those that operate on manufacturing floors and such, pop-up error messages are a distraction and therefore all error displays need to be through alarms.
There isn't a built-in way to monitor the number of occurrences, but you could add one to the functional global easily enough. However, elements are always removed in order of priority (and are FIFO within the same priority), so if you didn't dequeue it, you could potentially back up other errors behind it. An interesting ability would actually be to add alarm capabilities to the specific error handler (through the DSC module or otherwise) as an alternate option to the priority queue, then you could chose to do one or the other for each error. However, that would involve editing the configuration, source, and data storage of the Express VI, so unless you're looking to make a project out of it, I think the best approach is just to pop them off the priority queue and then feed them to the DSC alarm manager from your central error handler.
Unable to install SEH in VIPM 2011. VIPM hangs on "Resolving Package Dependencies". My guess is that this is caused by the VIPM dependency on GXML which I installed separately outside of VIPM as it was not available for download as a VIPM package. Is it possible to get GXML as a VIPM package?
I installed GXML first, as a regular installer, then VIPM seemed to ignore the missing dependency, and installed SEH anyway. GXML was still listed as a missing dependency.
Thanks for the note. I tried installing GXML first, even rebooted the computer after installing it. Unfortunately VIPM still crashes when I try to install SEH.
Here is a .vip of GXML. I've installed before without the VIP and it didn't crash, but maybe they've updated VIPM. If this doesn't fix it you'll probably need to go to JKI for help.
I successfully implemented the SEH to DSC Alarm Manager (in the central error collector loop) like you had described, and it works great to keep reoccurring errors from popping up, while still keeping a record of them.
I was looking at ways to combine the RT_SEH and the cRIO Fault Engine in a similar manner on my RT targets, except this would be to keep repeated errors from spamming the error log .txt file on the cRIO. Do you have any suggestions on how to integrate the fault engine?