Components

cancel
Showing results for 
Search instead for 
Did you mean: 

Structured Error Handler Library

To address generic errors:  Double-click the Specific Error Handler. Select Default in the error list (that covers all non-specific errors).  On the Notify tab, check Notify and Classify. Set the Classification to whatever level you want. We typically enter I/O Error. Note that each error type in the error list can have different settings.

 

To document these settings, pop-up on the SEH node and select Caption. Edit the caption to say something like "Defaults handled".  Then, any time you need this functionality, copy and paste this particular node and they will all work the same.

 

Gary Johnson

0 Kudos
Message 91 of 117
(6,126 Views)

I'm planning to update may project und want to implement SEH.

But before I do so I have a question.

At the moment I understand that the SEH runs on the WinOS und Real-Time seperately.

Does it also implements a way to easy exchange errors from the RT to the WinOS?

0 Kudos
Message 92 of 117
(6,113 Views)

The SEH toolkit doesn't provide communications. It's main purpose it to gather all errors within one application space (for instance, all your VIs running under RT) and process them in the Central Error Handler, which is also part of the toolkit. You customize the CEH for your application. Based on error classifications determined in each instance of the SEH node, the CEH can take various actions. One of those actions could be to transmit the errors to another platform. You could use network shared variables, network streams, or some other method, but it will be your choice. One thing we found especially useful is to add syslog (system logging) to the CEH.That way, every error gets reported via UDP to a server where it is logged for later viewing. NI has a library for syslog that you could use. http://sine.ni.com/nips/cds/view/p/lang/en/nid/209116

 

-Gary

0 Kudos
Message 93 of 117
(6,104 Views)

The link works now.  Thank you very much. 

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
0 Kudos
Message 94 of 117
(6,095 Views)

Hello,

 

I'm trying to use the SEH function to call a VI that pops up a message to the user. The program itself is pretty complicated, but I am loading the messaging vi (General Equipment Initialization Problem.vi) with the main application:

 

main program.PNG

and then calling it several levels down in the Initalize Equipment sub-vi. I can get it to clear the errors, but it won't call the vi that sends the message. I've tried putting in both "General Equipment Initialization Problem.vi" and "General Equipment Initialization Problem" (without quotes):

SEH Portion.PNG

I'm pretty new to LV, so I'm sure its something simple that I am missing.

 

Thanks,

Simon

0 Kudos
Message 95 of 117
(6,039 Views)

If I remember right LabVIEW might optimize out unused cases when the case selector is directly connected to a constant like that.  Try sticking a not inbetween and inverting the case logic.  You can also load it dynamically with VI server.

 

That being said, popping up dialogs directly from your specific error handler wouldn't generally be considered a best practice.  It's certainly possible, but there are a lot of things that can go wrong.  A better approach would probably be to communicate the error to a central handler and then call your pop-up from there.

0 Kudos
Message 96 of 117
(6,034 Views)

Sorry for the delay in responding, I got sidetracked with another project. When I get a little more advanced I might try to implement a central error handler, but I am just trying to use the specific error handle to cover a multitude of user input goofs and tell them to go back and fix it.

 

I put together a mock vi to try and figure out what I am doing wrong, but I'm still not having any luck. Perhaps you or someone else could look at it and let me know what I am doing wrong?

 

Thanks,

Simon

0 Kudos
Message 97 of 117
(6,015 Views)

You need to mark the VI you want to call as reentrant (in VI properies).

Message 98 of 117
(6,008 Views)

Thank you so much!

0 Kudos
Message 99 of 117
(6,005 Views)

I am using the non RT version of the SEH on an RT target ....which may not be ideal!.

 

The RT target has 3 timed loops and 4 untimed loops. One of the untimed loops is a comms loop which includes OPC UA comms with PLC's, UDP etc. Each of the loops includes SEH handlers to pick up errors which are handled by a central error handler loop similar to the SEH example error handler template. The central error handler prints the current error out to the RT console and sends it via Syslog to a collector.  There are 117 SEH specific handlers in the application distributed around the loops.

 

I have noticed that sometime after the RT application has started up, when I get the first error, the Comms loop stalls for a (long)  period (10 to 20 seconds) until the error is displayed on the console at which point the loop restarts and the RT application runs normally thereafter . Subsequent errors picked up by the SEH do not stall the comms loop.

 

The comms loop calls an SEH specific handler every iteration - as do all the other loops so I guess it is being blocked by its handler when the first error is received. Is this understanding correct?

 

How can I stop this stalling happening?

What is happening when the first error is received by the central error handler?

 

David Spall

0 Kudos
Message 100 of 117
(5,852 Views)