General error handling operation

[pwaszkewitz]

Hi,

I did not find a comprehensive explanation how error handling works in TestStand, only bits and pieces about the callbacks (perhaps I looked at the wrong places).

Anyway, I made some experiments with SequenceFilePostStepRuntimeError and StationPostStepRuntimeError - intentionally leaving out ProcessModelPostStepRuntimeError to reduce complexity - and came up with the attached flow chart. I would like to know:

• if that shows the correct operation of TestStand error handling (we are currently using 4.1, about to switch to 2010 or 2012, so it would also be interesting to know if anything changes with the new versions)
• if it is always the case that the combination of ErrorReported=True und Error.Occurred=True after the error handler leads to termination of the execution? I could not find any setting governing that (the "goto cleanup immediately" setting of the sequence was off;

Best regards

Peter

[RaviShrigiri]

Hi Peter,

1) Every step has :

error.code   - to set the error code

error.occured - boolen if set true displays a popup error message to the user

error.message - the popup contains this message

when you set error.occured=true it will bring up a popup message with the error.message and error.code.

Please note that this may not be acceptable in the manufacturing environment where operators may not be trained to check for errors.

The general practice in manufacturing is to fail all important steps that errors out so that the final result is failed.Then do a offline analysis.This is done by step.results.status = "Failed".You can also populate step.results.ReportText with proper values so that your test report reflects the type of error/failure.

2) Regarding the  SequenceFilePostStepRuntimeError and StationPostStepRuntimeError - they are optional error handling methods if you want to act on errors.

3)Every step has an option ( look for properties-->post actions).On Pass or On fail destinations can be set for each step.Cleanup is always executed except in cases of abort.

4) In the menu configure-->Station options-->execution there is an option for runtime errors ( one of them is run cleanup).

Hope the above information helps.

[pwaszkewitz]

Thank you SunRS for this summary.

We always have StationPostStepRuntimeError to carry out logging of errors for offline analysis and also to have more options for automatic reactions (e.g., show a dialog during development of the machine, log only during production).

What I find interesting is that behavior to terminate the execution when the error handler returns with ErrorReported=true and Error.Occurred=true.

The configuration you mentioned is set to "Show Dialog", not to run cleanup. ShowDialog happens, as my flowchart shows, in the case of ErrorReported=false and Error.Occurred=true -- which I find logically as ErrorReported has the purpose of suppressing the UIMsg for the error. But I cannot find a configuration for the termination.

Regards

Peter

[RaviShrigiri]

You can use the below command in a statement step type to terminate the execution whenever required.

RunState.Engine.TerminateAll()

This can be conditionally called in the error callbacks that you are already using.

[pwaszkewitz]

Thank you for the quick reply. My problem is not to terminate the execution, but to understand why TestStand does terminate it on its own.

Or, more precisely: is it expected behavior of TestStand, to terminate the execution, when after running StationPostStepRuntimeError the RunState contains

• RunState.ErrorReported == true
• RunState.Step.Results.Error.Occurred==true

and if so, what is the logic behind it and is it configurable somewhere.

[RaviShrigiri]

Each step has 4 execution status - pass,failed,done and error.

Whenever step.result.error.occured=true the step errors out (its execution status is set as error).

StationPostStepRuntimeError callback is automatically called whenever a step errors out. By default its blank ( does not do anything).Its upto the user to implement any specific requirements whenever a step errors out.Its just a place holder for the user to customize if required.

Teststand will not terminate on its own when StationPostStepRuntimeError callback is called.

You can find more details about the same in the Teststand Reference Manual.

Hope this helps.

[pwaszkewitz]

It seems like I am not making myself clear. I know all that. We need StationPostStepRuntimeError and it works just the way we want it to. But I made some experiments and found something I do not understand.

The handler is called with the Caller.Runstate. Usually, we set Caller.RunState.ErrorReported=true so that TestStand does not send an UIMsg for the error. We also set Caller.RunState.Step.Result.Error.Occured=false to avoid having another handler react.

When the handler does Caller.RunState.ErrorReported=false and Caller.RunState.Step.Result.Error.Occurred=true, then TestStand send the UIMsg and the SeqEdit displays the standard dialog. That I do understand. TestStand assumes that the error has not yet been reported/handled.

But when the handler does Caller.RunState.ErrorReported=true and Caller.RunState.Step.Result.Error.Occurred=true, then TestStand terminates the execution (not itself, I did not say that), although the sequence is not configured to go to cleanup immediately on failure and the station options do not say to go to cleanup, but to show the dialog.

It want to know, if this behavior is by design, if so what the rationale is for this behavior and if it will stay the same in versions > 4.1

Regards Peter

[dug9000]

There is no sequence setting to not goto cleanup on error that I am aware of. What setting are you referring to? You might want to consider changing Execution.RTEOptionForThisExecution to Ignore, though I'm not sure that will really give you the behavior you want and it will affect all threads in the execution.

-Doug

[pwaszkewitz]

I was referring to the setting "Immediately Goto Cleanup on Sequence Failure" in the Sequence Properties dialog. Obviously my thinking was faulty here.

Then I summarize to see if I understand correctly:

• this setting refers to the "Failed" status, not to a runtime error.
• TestStand always goes to cleanup when there is a runtime error in a sequence.
• When a PostStepRuntimeError sequence sets the Error.Occurred-flag of the calling step to False, TestStand considers the runtime error cleared and does not go to Cleanup.
• When a PostStepRuntimeError sequence leaves the Error.Occurred-flag of the calling step at True, TestStand considers the runtime error prevailing and
• sends a UIMsg, if the ErrorReported flag is False
• goes to Cleanup, if the ErrorReported flag is True

It is not that I want a different behavior; I merely wanted to understand this and wanted to know if I am correct in setting Error.Occurred to False in the PostStepRuntimeError sequence in order to have the sequence go on (e.g., for errors that we simply want to have logged).

Regards

Peter

[DowNow_]

Hi,

My advice is 1) study and experiment with the TestStand example, Examples\Callbacks\ErrorHandlerExample.seq, maybe you've already done this, and 2) call the Application Engineers on he phone and you should be able to nail them down for an exact answer.

cc