NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Process Model Error Handling

Helloeveryone,

 

I’m tryingto create a custom error handling scheme for my process model in TS4.1 andLV8.6. I’ve coded the ProcessModelPostStepError (which handles the clientsequence errors) and SequenceFilePostStepError (which handles the process modelerrors) callbacks and everything is working great so far…

 

Iunderstand that the MainSequence itself is a callback itself so it makes sensethat other callbacks in my client sequence (e.g. PostUUT, SequenceFileLoad) reportthe error to the ProcessModelPstStepError callback. However, I’d like to treatthe errors in other callbacks as if they were Process Model Errors not ClientSequence Errors.

 

So I’m lookingfor a way to distinguish between a sequence/step included in the MainSequencecallback and a sequence/step included in some other callback. I’ve tried runningthe Runstate.Sequence.Type property and Runstate.Sequence.GetEffectiveType() method in my PostUUT callback but they both return0 (The sequence is not a callback or an entry point)

 

The onlything I can think of at this point is to look recursively in the call stack forthe Runstate.Sequence.Name property to see if I find the ‘MainSequence’ untilthe property Runstate.IsProcessModel is equal to TRUE. This would probably workbut still I’m looking for alternate methods… any ideas??

 

Thanks,

 

<<-N->>

0 Kudos
Message 1 of 3
(3,352 Views)

Hello <<-N->>,

Thank you for posting on the NI Discussion Forums.  If there is something that you want to tell which step is calling the ProcessModelPostStepRuntimeError callback, you can use the property RunState.Caller.Step.UniqueStepId.  Each step created on your machine has a unique StepId, which is only used in reference to that particular step.  If you prefer to filter the calling step by name, you could also use RunState.Caller.Step.Name. 

If you would like the name of the sequence which the error occurred at, you can also use RunState.Caller.Sequence.Name, or one of the other properties of RunState.Caller.Sequence.
Chris_G
Sr Test Engineer
Medtronic, Inc.
0 Kudos
Message 2 of 3
(3,327 Views)

Hello <<-N->>,

After discussing with one of my colleagues, I was shown a much better (more modular) way of going about solving your problem.  If you want to just distinguish whether the error came from your process model or your client sequence file, then you can get the file path for the sequence file that the error occurred at using parameters.Step.Sequence.SequenceFile.Path, and comparing it to the path of the current process model, which is returned by using runstate.Root.SequenceFile.Path.  If the comparison results in a match, then you know the error came from the process model, but if it does not result in a match, then the error came from a client sequence file.  This is a better implementation because then you do not have to keep track of step IDs, and will be an all-encompassing solution for future changes to the test sequence as well.

Chris_G
Sr Test Engineer
Medtronic, Inc.
0 Kudos
Message 3 of 3
(3,313 Views)