poststepruntimeerror

[pwaszkewitz]

Hi,

I did some experiments with the ErrorHandler-Example in TS 4.0 and I wanted to ask whether my observations lead me to the right conclusions. It seems that

• if a sequence file contains a PostStepRuntimeError sequence, this sequence is called in case of a runtime error; in this sequence a retry can be done by manipulating the step index, the error can be ignored by setting ErrorOccurred to false, a cleanup or a termination can be triggered.
• If there is no PostStepRuntimeError sequence in the file, then TestSTand tries to find a StationPostStepRuntimeError sequence in the StationCallbacks.seq. This can do the same things as the PostStepRuntimeError sequence.
• I would assume that the next step would be trying to find and execute a ProcessModelPostStepRuntimeError sequence which somehow does not seem to work in my installation.
  

If the runtime error treatment in the Station Options says "Show Dialog" and if the above sequences do not set the ErrorReported flag to true, then a UiMsg_BreakOnRuntimeError is generated which, in the Sequence Editor, causes the well-known dialog to be displayed (with essentially the same options).

So the following questions:

• Is it correct that by defining a PostStepRuntimeError sequence in a sequence file, I can override the default runtime error treatment such that  each sequence file has its own individual error handling?
• How do I cause the ProcessModelPostStepRuntimeError sequence to be called?
• Is it correct that the sequence that caused the error is stopped until the error handler sequence returns resp. until the UiMsg_BreakOnRuntimeError is acknowledged by the GUI (which, in the case of the sequence editor, is not until the user confirms the dialog)?

Best regards

Peter

[RayFarmer]

Hi,

I think it sees if the ProcessModel callback exists before the StationCallback.

To make the ProcessModel version called, make sure you dont have any other version in your SequenceFiles or the StationCallback.

Even having an empty Callback or one with the steps set to skipped will cause the ProcessModel callback not to be called.

Which every callback you use, this will override the default Dialog from showing.

Regards

Ray Farmer

[pwaszkewitz]

Hi Ray,

yes, you're right. My mistake was that I did not use one of the execution entry points but executed the MainSequence directly. I missed that the documentation said "sequences called from the process model" which is clearly not the case without the entry point.

When using Single Pass or Test UUT, the ProcessModelPostStepRuntimeError is indeed called before the StationPostStepRuntimeError. They are both called in that sequence and if none of them sets the caller's ErrorReported property true, then the UiMsg_BreakOnRuntimeError is also generated.

However, as you said, having a PostStepRuntimeError sequence directly in the sequence file overrides both.

Thanks

Peter

[WeiL]

Hi,

I do not have problem with using StationPostStepRunTimeError callback in the StationCallBack.seq to handle multiple sequences with multiple Process Models under the same TestStand Engine (single run time engine), i.e., only open one TestStand editor.

But the problem is that, if I run multiple sequences under two TestStand Engines,  i.e., open two TestStand editors, the errors raised from multiple sequences will be caught by the same StationPostStepRunTimeError and the StationPostStepRunTimeError will be confused. The StationPostStepRunTimeError does not know where the error came from (from which TestStand engine) and them makes wrong action. Do you have any idea to handle this please?

By the way, I do not want to use ProcessModelPostStepRunTimeError to handle the system error as it has some limitations, like it is not able to handle errors from sequenceFileLoad/Unload, etc.

Many thanks,

Wei

[RayFarmer]

I believe there is only one TestStand Engine and hence only one Station.

Have you tried using the SequenceFilePostStepRunTimeError?

[pwaszkewitz]

As far as I know, the Engine is individual to each process, but of course both Engines work from the same settings in the registry so they have the same Station callback. I am fairly sure that the engines are different because we are regularly using several TestStand processes on one machine, and they start with the same set of StationGlobals with the same default values, but can change the values individually.

One might try to check the process ID to see if it can distinguish between the processes.

Regards

Peter

[RayFarmer]

You might start with the Same StationGlobals but everything is held in memory until you start down, then the StationGlobals are saved out to the StationGlobals file.

You can force save the StationGlobals but usually you get a warning from the other TestStand App telling you that StationGlabals has changed and do you want to reload.