05-07-2012 05:35 AM
Thanks for the answer! Good to know that I can dig into the code and see for myself what kind of risk may it carry, and what tests should I build around it to test it if I need to do so.
08-31-2012 04:56 AM
are there nay plans on implementing this lib on base of the Actor Framework? IMHO this would fit quite nicely
08-31-2012 09:29 AM - edited 08-31-2012 09:30 AM
I've discussed it with Allen, and it's something we're planning to look into. No ETA on it though. Of course, the source is provided, so if you're feeling ambitious you could always take a crack at it
04-18-2013 04:39 AM
I just downloaded the latest version of the SEH and was using the "Repeating Error Handler" and CEH templates that ship with the SEH. It looks like the "Priority" configured in the Express VI is incorrectly being compared to "Number of Notifications per Priority" as set in the CEH.
In other words:
1. In the CEH I have "Number of Priorities" set to 3.
2. In the CEH I have "Number of Notifications per Priority" set to 5.
3. The Express VI throws error 537602 only if I set "Priority" to 5 or more. I think it should throw an error if I set the "Priority" to 3 or more.
4. If I set the Priority in the Express VI to 0-2, the CEH responds as expected.
5. If I set the Priority in the Express VI to 3-4, the CEH doesn't do anything.
A couple of other things which are not bugs necessarily but really should be changed:
1. The Tip Strips for some of the controls in the Express VI Configuration Dialog box are misleading or incorrect.
2. The "VI to Call" input requires that the ".vi" extension be included. The Express VI should figure out to add the ".vi" extension if it is missing.
3. Since the "Loop?" output of the Express VI is TRUE when we WANT an iteration to occur, the Conditional Terminal of the While Loop in the "Repeating Error Handler" snippet VI should correspondingly be set to "Continue if TRUE" and not "Stop if TRUE".
04-29-2014 05:13 PM
The SEH express dialog lets you save error configs in xml files. Where should the files be saved, particularly when deploying to an RT target? Should the file then be added to the lvproj?
04-29-2014 07:00 PM
The configuration for a given instance of the SEH node is stored within the scripted subVI that is created when you drop it. The XML files serve as an easy way of creating templates for error behavior, for example, if you want to have the same or similar configuration in many different locations in your project (they also made my life much easier when I was testing it, as I didn't have to manually reconfigure the test cases every time).
There is no link between an SEH node and the XML that was used to configure it (important, as the XML files are not a way of slaving many different nodes to a central configuration, I considered that, but was unwilling to accept the deployment complications and performance tradeoffs it created). To that end, you don't have to deploy the XML files in any way. You can save them with your source and/or add them to your project for organization purposes.