From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

NI-Week Session: Advanced Error Handling in LabVIEW

This is a conversation that was started on LAVA. We wanted to post it here in case anyone on this forum missed the original thread and has thoughts they would like to share.

 

"One of the questions that has existed since man first used a LabVIEW error cluster is how can I make it scalable so I can have more than one error simultaneously. The next question was where do I put all this data? I've seen many different implementations, some concatenated their error structure to the "source" text field in the standard error cluster, some implemented a completely new system outside of the traditional error cluster (with appropriate converters to and from each system). The question is: which one is best? The former breaks less and required less retro-fitting of existing code, and can benefit from some of the existing error handling VIs that ship with LabVIEW, but it sometimes breaks when VIs misbehave and wipe the error cluster clean (yes, some primitives have been know to do it under certain circumstances). The latter is tempting because we can start from scratch and design whatever we want, but it requires integration into existing components that, by default, use the existing format is challenging. Thoughts? "

Message 1 of 2
(2,440 Views)

I have always gone the latter route when I needed it.  I usually use an action engine to keep track of the error messages.  Said action engine can be used to combine and suppress errors, as well.  I have posted an example below (LabVIEw 7.1).  In this case, the error propagation is occurring in a task handler which is processing multiple command/data pairs.  The command is set at the beginning of the task and the error handler is sprinkled liberally throughout the task code.  In this particular case, the desired behavior is to continue execution on error, but log the errors.

 

I prefer this type of method because it gives me complete control over the error propagation.  It has the down side of requiring more code and effort, but I think it is worth it. I like functionality to be explicit on my block diagrams.  It makes long-term maintenance much easier.

Message 2 of 2
(2,410 Views)