Injecting error into standard error in / out scheme

[TripleAntigen]

Hi I am just starting in Labview, and to date I have been joining sub VIs with Error Out linking to Error In of the next sub VI so I can capture errors at the end of the line of VIs that make up my program.

It occurs to me that sometimes there will be errors occurring that are not thrown by the system, but rather are thrown, for example, during a product test, when a test parameter does not fall within a valid range. I am wondering how I convert say a boolean for test pass / fail, into an error with a message, that I can inject into my error path. Is this what is typically done?

For some context, I want to be able to test two manufactured devices in a single sequence. If one fails a sub test, say a voltage is out of bounds, I would like to inject that as an error and have it skip to the end of that test where it would be handled, and maybe a panel on the GUI then shows FAIL or something similar. But execution should then immediately proceed on to the second device and begin that test, without waiting for acknowledgement so that when the tester comes back, both have been tested and he can determine what to do with them depending on PASS or FAIL status.

I guess I am asking how do I throw a custom error and have it caught? I read a few articles on error handling that did not really answer my question. Thanks for any advice!

[RavensFan · Accepted solution]

You can use Bundle by Name to build the error cluster yourself with a True boolean for the error (false is a warning), a number (0 for no error, positive number for a warning, negative number for an error), and a string for a message.

Whether you should be using the error cluster in this way is a different question.  I would recommend against it.  I consider the error cluster to be there for program errors and hardware errors.  Basically if your program is running properly and you have no hardware issues, then an error should never show up on the error cluster.  For the situation where you are dealing with failures of a device under test, the Pass/Fail results, I would consider that to be a normal part of program operation, and that data should be handled separately as a part of your test data and not be forced into the error cluster data.  Any subVI's that should or shouldn't execute because an earlier test has failed should check the condition of the pass/fail data to determine whether to execute.

[TripleAntigen]

Great, thanks for the advice, that seems to make sense.

But the question that comes to mind now is, do I need a separate Pass / Fail In/Out mechanism that is similar to the Error In / Error Out? In other words, do I need to implement a similar mechanism (similar to the error passing method) for the pass fail testing sub VI's, so that they essentially pass their status to the next block?

I had in mind a string of sub VIs that perform individual tests on part of the Device Under Test, linked together daisy chain style. If you get to the end without error, the device passes. Do I have to reserve an additional two signal terminals on every testing block, to pass their pass fail status along? Would this be standard practice for test scenarios?

Thanks again

[nathand]

I disagree with Ravens Fan here; I think it is completely appropriate to inject a user-created error when a test fails if you want to skip the steps that follow.  I prefer the "Error Code to Error Cluster" function for this purpose.  Since most functions do not do anything when there's an error on the input, in my opinion it's unnecessary to add a second layer of pass/fail checking that duplicates the effect of an error condition.  If you need to proceed to a different test when the first test fails, but not when some other error occurs, it is easy to filter by error code and clear only errors that match a specific number or are within a specific range, indicating that a specific test failed.

[RavensFan]

I would assume there is a cluster of data you are already passing along from one test to another.  I would put the pass/fail results as another element in that cluster rather than creating putting them onto a new connector on the connector pane.

[Dennis_Knutson]

I agree with Ravens Fan. The issue I have had with updating the error cluster is that there is often/usually code that must run after a test is complete. This could be functions to return an instrument to a default state, communications to the UUT, etc. By updating the error cluster, then this code would not run. I much prefer to handle pass/fail data in a separate cluster.

[PhillipBrooks]

I was taught early on by some really good test engineers that error ≠ failure.

This is from the TestStand Style Guide, but is applicable to home-grown test executives:

Error Handling

An important element in any test system is error trapping and handling. As discussed earlier, the Cleanup step group is useful for handling errors and, if necessary, shutting down a test system gracefully. In addition, a certain amount of error trapping must be done in the test modules themselves. All the standard TestStand step types include a structure for error information. This structure includes a Boolean value to signal when an error occurs, a numeric for an error code, and a string for an error message. In TestStand, a run-time error is not a test failure; instead, it indicates that there is a problem with the testing process itself and that testing cannot continue.

http://www.ni.com/white-paper/4267/en#toc4