I have a question regarding the intended purpose of Error Clusters. It is clear that you should use error clusters and the LabVIEW error mechanism for catching and dealing with "internal" errors such as unable to open a comm port or even an unintended divide by zero. For the purpose of this question, I am categorizing these types as internal errors. However what about "process errors" such as the 'user opened the door' while a test was running? Is it "proper" LabVIEW programming to use the LabVIEW error mechanism together with error clusters to catch, propagate and deal with such errors or is better to create a separate error handling mechanism? If the latter, then does anyone have any useful tips (or better, links) on implementing such an error mechanism?

If it was me, I would not put the "process" errors in to the error wire. I would consider a process error an expected part of the normal operation of your code, while I would leave the error wire alone to handle errors within the programming that you wouldn't expect. You'd run the risk that an earlier "expected" error from the process would override a more significant unexpected error within your program that prevents you from seeing it and handling it. Also, most LabVIEW functions have what is called "standard error functionality" which means they don't execute on an incoming error. (Why would you want to try reading from a file, if the open file function just upstream had an error while trying to open it?) But if you have a "process" error, running down that error wire, it would prevent many of those downstream functions from executing. I would just create your own wire to handle your process errors. It could be a simple string or number. But perhaps you want it to be a cluster. You can structure it however you'd like. I would be careful though that any cluster that consists of boolean, integer, string in that order will automatically look like a regular LabVIEW error wire with the mustard color. That could be confused with your actual LabVIEW program error cluster.

LabVIEW

Intended use of Error Clusters?

Solved!

I almost never use custom error codes. The reason is because there are already so many error codes built into LabVIEW and those often meet the needs of my custom errors, sometimes with some more source string information. I have a utility that allows me to search existing error codes for free text and so I usually find an error code that is close enough.

Having difficulty opening a reference to a device? 40 is Cannot Open Device.

Reference goes bad? 23 is Input handle is invalid, 36 is Invalid device refnum.

Once I find the error code that I want to use I'll drop an error ring, choose Custom Error Code, then type in the code I want, along with additional descriptions. This node also accepts things like %s and %d for additional inputs.

Oh and I agree with everyone else error information to me isn't about how the test ran, it is about major issues that should prevent other actions from taking place. In a pinch it can be used for something like stopping a loop, or continuing a loop on a retry.

Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.

17 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord