I just checked on my machine and sure enough I see the same issue. It probably happened when I tried to reverse engineer the .vipm build because it was lost some time ago. The source and build is located here if you would like to look at it. I will say that I was thinking about removing RTEH portion of the library. My reason of thinking that is that the error handling that the library provides typically does not require the determinism. For example the RTEH was designed to go into deterministic control loops (like a PID loop) which would require determinism to allow for accurate iteration timing (aka control runs at exactly 1kHz). First, most people move that kind of control code down to the FPGA. Second, most control loops are not going to generate errors that need to be handled, they just run at a known rate and are simple math that can't "error". Third, when an error does occur in a control loop some action needs to occur, like moving to safe mode. At that point determinism does not really matter...speed is the priority. And the mechanisms are pretty much the same speed. Can you explain where you are trying to use the RTEH over the regular SEH?
as you describe, the use case for RTEH is within timed loops, but for all other places I'd rather use SEH with its richer error descriptions. However, I still see the use for RTEH and I don't agree that the code in timed loops always could do without an deterministically optimized central error handler.
If you removed the RTEH, I would have to do some kind of similar implementation myself instead, so please keep it.
If I could wish for a change around RTEH it would be the ability use both SEH and RTEH in parallell on a RT target. This would of course mean some additional logic on the "reciever"-side to handle both types of errors.
I went ahead and made two issues (one for the bug and one for the feature request) on the github page. I assume you are still able to get to the RTEH folder to use the VIs even though the palette isn't working.
Ok, nice to hear.
I didn't try to use the RTEH VI's directly but instead reverted to the earlier version, but I agree that it would probably work to use them directly also. I just didn't think of it then.
I need a little help getting this to work. I have 2 issues: 1) When I give the Specific Error Handler an error with Status=True, it generates that ole error dialog, Continue or Stop, yada, yada. I definitely don't want that, but there doesn't seem to be a way to tell it "no dialog", like I could with the simple or general LabVIEW error handlers. 2) I've got a bunch of user-defined error codes - I don't see a way to load my codes/strings in anywhere so that I DON'T get the ole "This error code is undefined yada yada". So maybe what's at the heart of my issues is that there's a LabVIEW error handler running inside the Specific Error Handler vi that I need to configure, but can't. Make any sense? Am I misusing the SEH somehow? thanks, paul
First of all thanks for this great tool, I am really enjoying learning more and more from it.
I learned about this tool from the following NI Webcast:
In this same Webcast, one of the slides shows a configuration of the Express VI using "comma-separated" Error values.
When I try this using the tool, it does not work, only the dash "-" feature works fine, but I was wondering if this functionality is actually available and if I am doing something wrong. This is very useful for sharing the same Specific Error Handling actions to Errors that are not in the close range.
Thanks in advance.