NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

How to detect the final loop iteration of a step in a PostStep Engine Callback?

I see the need to use a PostStep Engine Callback and look at the Step.Result container of the caller.
My issue: If the caller is configured to loop, the PostStep Engine CB executes with each iteration and I do not see how to detect the final iteration (which is the only iteration I am interested in).

Ideas are welcome. Thanks in advance,
Guenter
0 Kudos
Message 1 of 7
(4,161 Views)

Guenter,

 

maybe you should tell us what you are up to since i think there is a more elegant way to solve your requirement.

 

Nevertheless, you can always check the Caller.RunState.LoopIndex in order to evaluate if you have reached the last iteration. This only works if your loop index is RunState.LoopIndex.

You have to get the upper limit of loops in a different way and i highly recommend you NOT to use a fixed number of loops (since you have to enter the number in the ste/loop as well as in the callback. Changing one instance will lead to a functionality which might be considered a bug in your sequence!)

 

hope this helps,

Norbert 

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 2 of 7
(4,143 Views)
Thanks for your answer, Norbert.
In fact, I need a generic solution.
I am facing a client sequence file that needs some "report generation". But the Station Options currently say "Disable Result Recoding for All Sequences" - for good reason. (This may change in the future, but not right now.)
With result recording disabled, I do not see a good chance to gather step results except for using a PostStep Engine Callback.
Some of the steps in the client are configured to run in a loop.
Using the PostStep Engine Callback gives me access to what I want to see. The only remaining question is: Is there a chance to detect the final loop iteration of a step right here? (From the Step Execution table in the TestStand Reference manual I take that there is almost no chance to do it in a generic way: As soon as the Loop While Expression evaluates to "False", there is no Engine Callback remaining that I could use to look at the Step.Result.)  I do not intend to do all the checks that TestStand does when deciding whether to break the loop.

Regards, Guenter
0 Kudos
Message 3 of 7
(4,130 Views)

Guenter,

 

well, the way i discripted IS the generic way. The reason for this is the following:

You can compare TestStand very well with procedural programming languages. So you have variables with different lifetimes and scope. RunState is one variable, which is available in every scope, but it may have different content.

So you leaving the execution of your clientsequence in order to call the callback, you leave the scope of the RunState from your clientsequence. But only there the information is stored on how many iterations are left. It does not make sense to pass this anywhere, since the execution of your clientsequence has to decide if to loop further or not.

 

But, please note that there are different scopes for the "disable result recording" as well. You have found the most global one, the station option. But you can as well set this in the sequence settings (Edit >> Sequence Properties >> Disable Result Recording for All Steps) and at step-level (Run Options >> Record Result {uncheck it}).

Looping on a single step using the step settings, you can additionally choose not to record results for each iteration. This will lead to only a single entry in the ResultList, the overall result of the looped step (if resultcollection is enabled of course!).

 

hope this helps,

Norbert 

Message Edited by Norbert B on 08-22-2008 02:10 AM
Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 4 of 7
(4,117 Views)
Norbert,
thanks for your detailled answer. I know about all the features you mentioned in your post. However, they don't give an answer to my original question.
So I am still wondering if it would be best/easiest to solve my issue e.g. in the Report Callback - as soon as "Disable Result Recoding for All Sequences" is disabled.
Guenter
0 Kudos
Message 5 of 7
(4,102 Views)

Hi Guenter,

 

You mention that the reason you are doing this is to gather step results and you are interested only in the last itereation if a step looped.

Is there a reason we can't use a variable to store this? What I mean is everytime the step runs, save the result to a local variable. If the step iterates, then it simply overwrites the local variable with the new result.

 

 If you are trying to write these to an array, one element for each step, another option is to use the Caller.RunState.LoopIndex.

Basically, if LoopIndex > 0, then you know that the step is iterating and you overwrite the last element in the array.
If LoopIndex = 0, you know we are on a new step and you add a new element to the array.

For looping steps, the array will still have the result of the last iteration because we kept writing over that step's element. 

Jervin Justin
NI TestStand Product Manager
0 Kudos
Message 6 of 7
(4,063 Views)

Thanks for your answer, Jervin.

You are right with your idea concerning the use of a variable to store the results. In fact, we go one step further and write to a file (I forgot to mention in my posts that we are writing to a file). It would be very ugly to parse the file every time a step has executed and manage the entries of steps that are configured to loop ... and also introduces a waste of time ... ugly, ugly ugly.

I see that we have to take the "next step" and customise the process model (which we have not done right now - therefore my approach to do it in that EngineCB). That will make live much easier and do it the "TestStand way".

Guenter

0 Kudos
Message 7 of 7
(4,047 Views)