Search the Community

I have some old VIs to which I need to give some love. All the error clusters were unwired, so I am working on that... I am wondering what would be the best practice when it comes to DVR. The IPE structure gives an error cluster on both the left and the right data node. The attached picture shows all the error handling I can think of, but I wonder if it's not an overkill. Here is the breakdown: 1) Outer case structure: If there is an error before going inside the IPE, it just skips the IPE altogether and propagate the error cluster. 2) IPE left data node: I don't need to merge it with any incoming cluster since we are in the "no error" case (what about warning? am I speaking too quickly?). 3) Inner case structure: as long as the code inside it knows how to deal with the error (likely skipping its own code and propagating the error), I probably don't need this structure. What do you think? 4) IPE right data node: in what scenario would it actually give en error? If the DVR is bad, the left data node will take care of generating the error... Is it there is case the DVR becomes bad during the IPE execution? If I wire the right data node, then I need to merge it with the error cluster coming from the code inside the IPE... Any comment more than welcome!

This thread is not a question, I just wanted to share the experienced I gained today by troubleshooting our application: Symptom: Engine A encounters an error (expected, so no problem so far) and display it to the user. Engine B, which is totally unrelated to engine A, freezes, and only comes back to like after the user acknowledges the error message from engine A. Consequence: The software engineer (aka me) is pulling his hair and yelling "what the h*** is going on in here?" Then he does some diligent troubleshooting and finds the culprit. Explanation: Engine A calls the "Simple Error Handler" VI, which itself calls the "General Error Handler" VI. This VI analyzes the error and opens a pop-up when there is an error to display. Engine B calls a subvi which calls a subvi...........which calls a subvi which calls "General Error Handler". This subvi doesn't have any error, but still calls "General Error Handler" because it knows that if there is no error, "General Error Handler" will simply return without doing anything. Problem: "General Error Handler" is not reentrant, meaning while it's busy waiting for the pop-up it called to be closed, it can't be used by the sub-sub...subvi of engine B. Therefore engine B is in a frozen state. Conclusion: Those error handlers are a great quick tool for creating super basic application, but not appropriate at all for large, professional applications. I'm pretty sure some of you will think "Well duh, we've been knowing that since LabVIEW 1.0!".

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?