I like the Fault Engine, but I've usually gone with an either/or approach and haven't tried combining them before. You could certainly check for faults, conver them into errors, and then pipe them into SEH, or you could pull errors from the CEH and use them to throw faults for particular categories of error.
I have the GXML installed, and I tried using the latest VI Package Manager to install the ni_seh-184.108.40.206.vip and the manager just sits there "Resolving packaging dependencies.,,,,
I've let it sit there for 3 hours and nothing. I don't believe it should take that long. I'm using LabVIEW 2011 (no SP1). Windows Vista SP1, 32Bit.
Unfortunately no. I don't own or maintain VIPM, but that's definitely not normal. Usually takes me less than 5 minutes to install.
I had the same problem with LV 2011 SP1 and VIPM 2011. You can solve it by installing the ni_lib_gxml-220.127.116.11.vip first (attached) and then install the ni_seh-18.104.22.168.vip.
Regarding the "Resolving Dependancy" issue; a google search showed that JKI acknowledges a problem with VIPM 2011.0.1 and recommends going back to 2011.0.0 and provides a link. Here is the discussion link.
After rolling back it worked for me.
I have a question about the Call VI option. Is there a way to accept inputs and generate outputs with the VI ou call? For instance, I have a serial connection that sometimes gets terminated by the device. I get an error and I currently handle it by checking for that specific error code and then open a connection and generate a value change on a control reference. So I have to pass a reference in (actually I unbundle from a type def cluster of refences) and I get a comm port out. It seems like calling a VI only does things on the error cluster, not taking any action that requires ins/outs.
You are correct, the Call a VI option passes the error in question into and out of the called VI, but does not provide additional inputs or outputs. There are a few options:
1. You could flatten the reference into the source.
2. You could modify the SEH, as the SEH has all of its source provided. The VI you'd need to modify would be probably be SEH Execute Error Handling Code.
3. You could lookup the appropriate reference from inside the VI to call using something in the error cluster such as the code or source and pull the reference from a repository.
4. You could update your UI from the central error handler (best option IMHO).
I am running a program with 13 asynchronous loops and I need specific action on specific loops. I am thinking I could put 2 SEHs in series and have the first one clear the source and then flatten the reference into the source and then have the second call a VI that unflattens the input and flattens the output and finally unflatten the output in the main VI.
The problem there is I would need to know when to do it. Then I am back to using my own error checking code. So, I think the easiest is probably to use the SEH for logging this error but run my own code in line to handle it.
It seems that error handling code that calls a VI would almost always need inputs and outputs. Variant in/out?? Object interface to deal with an instrument with an error?
Thanks for the quick reply!
I'd personally rather not take the performance hit from adding an additional interface to there (dynamically setting a dynamically sized value). I try to only use the Call VI option for modifying error information (converting one error to another for example) and prefer to keep all of those more complex operations confined to my central error handler (you can use the Category to help you identify which look a given error came from so that you can update the appropriate control). However, if you use that option differently, you're welcome to modify the library and add a variant or object to the interface, that's why I provide the source.