Error Handling (In the Feedback Evaporative Cooler sample project)

[GeorgeG]

I have some projects on the horizon that have to be more reliable than anything I have done in the past. And this new requirement has me thinking about how I deal with errors in LabVIEW more and more. Simultaneously I have been looking into the Actor Framework. The sample project in LabVIEW 2012 for the Evaporative Cooler does a great job of showing how many of the pieces of a full application fit together. However, as I have studied the example, I have noticed that in many places error handling has simply been ignored.

An example of this is in the water level control... specifically, I take issue with the word "guarantee". Documentation states: "Water Level is a concrete implementation of a Level Controller. We will use it to guarantee that the water in our evaporative cooler’s reservoir never falls below a minimum safe level."

What if the building loses water pressure? Or the piping fails? Or the valve doesn't actually respond? Or any of a million scenarios that result in the program being unable to really guarantee anything.

I'd like to open a discussion of how the Evaporative Cooler example could improve on its error handling so that it was robust enough to safely deal with all the "what ifs" of the world. This question is covering everything from "what if writing to the value property of a UI indicator fails?" to "what if the building water supply fails and the water level doesn't respond when I command the valve?"

And those seem like two great places to start! In the context of the Evaporative Cooler example project, I found three VIs whose error handling I would like to discuss:

1. Timed Loop Actor.lvlib:Timed Loop Actor.lvclass:Read Controller Name.vi

2. Live User Controller.lvclass:Update Current Temperature.vi

3. Level Controller.lvlib:Level Controller.lvclass:Update Core.vi

In the case of #1, the VI does not have error in/out terminals, but some of the VI's it calls does. This is a situation I have encountered before: how do you add error handling to a very low level VI that does not (and for the sake of discussion cannot) have error terminals?

In the case of #2, the VI writes to a property node and ignores the error terminals. In a big application there are soooo many property nodes! What are the implications of ignoring the errors? When is it safe to ignore them? This is probably very common, and has some overlap with #1... In general, in LabVIEW, when can you ignore error terminals?

#3 is the logic VI that determines whether to open or close a valve based on water level. But it doesn't keep track of time and whether things are "working". And certainly if you put a human operator in place of the VI, the human would after some time decide that opening the valve hadn't helped the water level. Can the VI mimic this?

For all of this error handling business, I think I am really asking four questions:

A) What should the software do on its own to respond to the error?

B) What should the software tell the operator (who might have never heard of LabVIEW or college) about the error?

C) What should the software tell the operator's supervisor about the error?

D) What should the software tell the software developer about the error?

It is pretty easy to write an application when everything works the way it should! But when things might go haywire, how do you write application then?

[JamesMc86]

I don't have the code in front of me now but in response to your final point:

A) (and possibly B) would typically be specific error handling. At the piece of code that operates you code responses to specific errors, e.g. Attempt to reconnect to a network connection.

B to D would often be handled centrally (not exclusively but often). Typical practice would be to have a central process which receives the errors. At the source the error is given a classification based on the source. This tells the error handler what to do such as log, notify user and/or shutdown the system.

For the specific instances you describe:

Case #1: depends on what you consider to be an error for this piece of code. Typical examples might be looking for invalid inputs and outputs General advice would be identify errors you expect manually, if there is nothing you can do at that level don't bother (e.g. The issue probably isn't with an add but whatever is feeding the add function, you don't want one issue to throw a huge number of errors).

Case #2: if there's nothing you can do at the source then you can't add specific error handling. I would typically string the errors together and at the end of the section of code send it to the central error handler to log.

Case #3: the classic issue of human vs machine! For this it is going to depend on the mechanism you are using. For the specific example you describe you would want to be preventative I.e. have outputs limited so the controller doesn't overdrive the system. Then have some alarming in place so if this is hit, or the system takes to long to reach the desired state. This could alert an operator or shutdown the system.

Hope this helps!