NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

How to modify (not completely override) an engine callback sequence

Solved!
Go to solution

I understand the general idea behind modifying engine callbacks, but how can I figure out what the original engine callback is doing? In other words, how can I see the steps involved in the default TestStand engine callbacks? Specifically, I am working with the SequenceFilePostStepRunTimeError engine callback. I want to add functionality that executes when a particular error code pops up, but have the engine callback run normally (i.e., have the "what do you want to do?" window pop up) for all other errors. I am confused because when I first "add" the SequenceFilePostStepRunTimeError callback to my client sequence file, the callback is empty. Does this mean that my specific-error handling code is the only thing that will execute? Or will it execute in addition to the default SequenceFilePostStepRunTimeError code? How can I see the code behind SequenceFilePostStepRunTimeError?

 

I appreciate the help!

 

-Bennett

0 Kudos
Message 1 of 6
(3,605 Views)

The engine callback are provided to the users to add in their code if required for that event.

By default it does nothing.Its just a place holder to do some extra things if required by user.

 

Its the TS engine code which runs in background and it cant be accessed.( unlike process model which is a sequence and can be modified by user).

 

For your use case add this in the SequenceFilePostStepRunTimeError  callback:

 

if(Parameters.Step.Result.Error.Code == -17303) \\ whaterver error code you need

{

do what you want to do for this error code

}

 

 

Hope this helps.

 

Ravi

 

 

 

 

 

 

Message 2 of 6
(3,571 Views)
Solution
Accepted by topic author bnaden

See this example:

 

<TestStandPublic>\Examples\Callbacks\PostStepRuntimeErrorCallback\ErrorHandlerExample.seq

 

In it you will see the comment:

"If this flag is set, TestStand does not send a UIMsg_BreakOnRunTimeError event to the GUI.  This step sets the flag to prevent the GUI from displaying a runtime error dialog because this callback has already displayed a runtime error dialog to the user."

 

where the following is done:

RunState.Caller.RunState.ErrorReported = true

 

That is what disables the normal teststand error processsing. There is no default callback you are overriding, there is a built-in default behavior.

 

Hope this helps,

-Doug

0 Kudos
Message 3 of 6
(3,554 Views)

Thanks to you both for the posts. I think I understand it now: it's the RunState.Caller.RunState.ErrorReported flag that controls whether TestStand shows the default runtime error box appears to the user. So, for example, I could do

 

if(parameters.step.result.errorcode == 1)

{

stuff

}

 

But if I don't clear the error by asserting "Parameters.Step.Result.Error.Occurred = false", or if I don't set "RunState.Caller.RunState.ErrorReported = true" in there, then the UIMsg_BreakOnRunTimeError event will occur, and the default error handling window will pop up. I tried that out in the example sequence, and it works as expected.

 

One more question on the callback in <TestStandPublic>\Examples\Callbacks\PostStepRuntimeErrorCallback\ErrorHandlerExample.seq: For case 3 "Go to Cleanup", the only step is to set the ErrorReported flag; no step in there says anything about going to cleanup. How does that work?

0 Kudos
Message 4 of 6
(3,456 Views)

@bnaden wrote:

 

One more question on the callback in <TestStandPublic>\Examples\Callbacks\PostStepRuntimeErrorCallback\ErrorHandlerExample.seq: For case 3 "Go to Cleanup", the only step is to set the ErrorReported flag; no step in there says anything about going to cleanup. How does that work?


That's just the default behavior of an execution in TestStand when an error occurs if you don't clear the error (i.e. if you don't set Parameters.Step.Result.Error.Occurred to false).

 

-Doug

Message 5 of 6
(3,432 Views)

Got it, thanks

0 Kudos
Message 6 of 6
(3,422 Views)