Error handling and good wiring habit

[EdoardoA]

Dear all,

I am re-writing a program that I developed in the past years which works well and doesn't crush... however after becoming more confident in LabVIEW (but not an expert, I try to keep learning as much as possible) I realized that is not fully optimized and I'm trying to make it more "correct" from programming point of view.

My question here is about the wiring of errors and how to treat them properly, because I don't know if I am doing a proper job with that!

In my case, the program controls an experiments with few different instruments (like a delay stage, a camera...) and I usually connect the error wires for each instrument separately without merging them together because i am worried that if a specific instrument gives an error might affect all the following steps, even if the error is not relevant for the experiment itself (for instance, an error coming from a specific sequence of property node I would keep it separate from the sequence of subvi of a certain instrument). in this way I know that a certain error is coming from a specific source and things don't mix... however the bad side is that the amount of error wires becomes larger! I know that merging them together could be a good solution (I saw many useful topics in the forum related to this), but I would appreciate a warm suggestion on how to keep the error wiring as clean as possible but also as functional and ideal as possible!

For instance: 

• Is it a good practice to keep errors separate? Or when is it ok to merge them?
• Is it always good to feed the "error out" indicator with every source of error (Like property nodes, LabVIEW subVI, instrument subVI) or in same case is better to exclude some errors? (For instance, connecting the errors of a series of property nodes for a specific task within them but then not displaying or merging the error out from the last property node?

Any further recommendations is very welcome!

Thanks for the support!

E

[Gregory]

In most cases it's good to wire the error wire through everything. Even if it's just a property node, you want to know if there's an error and probably correct the input to it so that it's not generating errors.

There is a main exception when I want the error wires to be separate and then merge them at the end. That is when I want to ensure that a certain function runs, whether the input has an error or not.

[paul_a_cardinale · Accepted solution]

 If you have LabVIEW 2020 or later, you can right-click on the "Merge Errors" function and select "Retain All Errors".

The built-in "Simple Error Handler.vi" doesn't support multiple errors, so I wrote my own (attached).

[paul_a_cardinale]

Note that, in general, if a piece of test equipment throws an error, you want to abort the test.

[santo_13]

---

@paul_a_cardinale wrote:

Note that, in general, if a piece of test equipment throws an error, you want to abort the test.

---

Along the same lines, any error from the instrument is catastrophic and is always good to abort and root-cause. One must write software robust enough to filter user commands to warnings on the software layer instead of letting it go to hardware and cause a hardware error.

[rolfk · Accepted solution]

---

@Gregory wrote:

In most cases it's good to wire the error wire through everything. Even if it's just a property node, you want to know if there's an error and probably correct the input to it so that it's not generating errors.

---

There were debates about that in the past and some people including Steve Mercer aka Aristos Queue lamented that the error cluster through each VI is a performance problem. Personally I still do it, for several reason:

- most instrument control is not performance constrained because of an error cluster that needs to be dragged along with the rest but because of having to wait for the instrument to answer.

- the same applies to many other parts of typical programming in LabVIEW. Trying to shave off a few nano-seconds is generally more than negligible compared to the rest

- it is easy to sequentialize functions that way and in most cases the hardware requires a clear sequence of events and doesn't like to be bombarded with concurrent requests

- it just looks cleaner than functions all over the place and then eventually try to bundle all the errors intelligently

One thing about the internal operation: It is a good idea to actually skip any operation on an active error in, but there are exceptions. For instance most VIs that close a resource or similar functions should try to proceed anyways (carefully).  It's very annoying when resources remain locked (such as serial ports, files or other such things) because there was some error in the software earlier on. Most LabVIEW Close functions do that themselves already but that won't help if they are in a VI that unconditionally skips everything on an incoming error.

[billko]

---

@rolfk wrote:

---

<snip>

One thing about the internal operation: It is a good idea to actually skip any operation on an active error in, but there are exceptions. For instance most VIs that close a resource or similar functions should try to proceed anyways (carefully).  It's very annoying when resources remain locked (such as serial ports, files or other such things) because there was some error in the software earlier on. Most LabVIEW Close functions do that themselves already but that won't help if they are in a VI that unconditionally skips everything on an incoming error.

---

I remember dark times when the various close functions did NOT do this...

[rolfk]

---

@billko wrote:

I remember dark times when the various close functions did NOT do this...

---

They still exist, at least until 2020. Haven’t checked in more recent versions. Registry VIs I’m looking at you!

[EdoardoA]

Thank you all for the good suggestions. However I attach a VI (very much simplified) that highlight my concern in merging and linking all the errors. the main part is that I have a delay stage that I don't always need but that I initialize in the very beginning of the program. It gives me an error with code 100 because it cannot find it if I don't plug it in. In this case, if I connect the error through other subVIs then the procedure request doesn't work. Probably would be better to initialize the stage in a controlled way, calling it only when I need it...so in this scenario is it a good practice to plug in the error as an error in in subVIs that don't really need an error input? Or is it good practice to do it just to obtain a clear sequential order?

E 

[Yamaeda]

---

@EdoardoA wrote:

Thank you all for the good suggestions. However I attach a VI (very much simplified) that highlight my concern in merging and linking all the errors. the main part is that I have a delay stage that I don't always need but that I initialize in the very beginning of the program. It gives me an error with code 100 because it cannot find it if I don't plug it in. In this case, if I connect the error through other subVIs then the procedure request doesn't work. Probably would be better to initialize the stage in a controlled way, calling it only when I need it...so in this scenario is it a good practice to plug in the error as an error in in subVIs that don't really need an error input? Or is it good practice to do it just to obtain a clear sequential order?

E 

---

The error is for you to handle. If you know that error 100 is a none issue you can clear that specific error or (better) pop a dialog asking if you want to abort or continue.