08-03-2011 07:33 PM
I have inherited several TestStand sequences with about 35-40 pass/fail and numeric limit tests. The sequence is set to Fail if any step fails.
There seem to be several ways to notify the operator about the nature or reason for the failure. All that happens at the moment is that the red "Sequence Failed" popup appears, and the operator gets to install the next UUT. This uses the standard "Sequential" model provided.
Am I looking at either
1. Modifying each affected step and changing it to "Action", then adding a step afterwards which pops a message if the previous step "failed", then Fail the sequence. Or maybe a variation of this, to modify the step to get it to skip the next step if "Pass", the next step being to pop the message and Fail.
2. Learning about User Interfaces and then implementing one. (This feel like overkill but I'm open to suggestions.)
Or is there another simpler way? I would just like to be able to pop up some text with suggested corrective actions, just before the red "Test Failed" notice.
Thanks.
Solved! Go to Solution.
08-04-2011 01:05 AM
Have a look at the use of the SequenceFilePostStepFailure Engine Callback.
There is an example found in \Examples\Callbacks\PostStepFailureCallback\FailureHandlerExample.seq
08-04-2011 03:48 PM
Perfect.
All I need to do now is create a FileGlobal string, setup an appropriate explanation in there before each step which can fail, and display it on the popup. Perhaps I can also create a sequence that is called on every "Pass" which clears this string. It's self-documenting. I love it. Brilliant. Thanks.
08-04-2011 04:02 PM
You do realize that the Step and Result get passed into that as a parameter right? And you can extract a ton of info from them. Just put a breakpoint in there and cause a step to fail and you can see exactly what's in it. Just know that it will be 'different' for different step types.
Cheers,
08-04-2011 05:28 PM
I agree with Jigg. With the data that is passed to the callback, I can do a database query and have the failure reasons very dynamic. For example, if the measurement is between x and y, replace a. If less than z, replace b. I use this so I don't have to modify the sequence when a new failure reason is found.