Unexpected behavior with the "Result Recording Option".

[josymar_guzman]

Hi,

I have an unexpected behavior with the "Result Recording Option".

I have some steps contained in the subsequence "X", this subsequence passes a boolean parameter; according the parameter value i modify the "Result Recorgind Option" to report it or not. The thing is that if "Result Recorgind Option" is set to "Disable" and at running time i modofy it by changing Step.ResultRecordingOption value to "Enable", the Step is not reported until the same subsequence "X" is called for a second time (without changing the passed parameter).

For example: (Preconditon: All step's Result Recorgind Option value in Subsequence X are set as Disable)

1. CallSubsequenceX(Parameter: Enable)

2. CallSubsequenceX(Parameter: Enable)

3. CallSubsequenceX(Parameter: Disable)

4. CallSubsequenceX(Parameter: Disable)

Expected Result:

1. Steps were reported.

2. Steps were reported.

3. Steps were not reported.

4. Steps were not reported.

Result:

1. Steps were not reported even Step.ResultRecordingOption value was changed to "Enable". (Not Ok)

2. Steps were reported. (Ok)

3. Steps were reported even Step.ResultRecordingOption value was changed to "Disable". (Not Ok)

4. Steps were not reported. (Ok)

I'm using TestStand 2013 (5.1.0.226)

Thanks in advance.

- Josymar.

[Omar_R]

Hii josymar_guzman

I'm trying to reproduce the behavior using the Step.ResultRecordingOption callback. By some reason, Testand tooggles the state of "Step.ResultRecordingOption" until the next loop iteration. Can you upload the sequence so we can debbug it ? 

[josymar_guzman]

Hi Omar,

I attached a sequence file with the conditons i described in the initial post. Hope this help.

Any comment, let me know.

Thanks.

- Josymar.

[Omar_R · Accepted solution]

Hi josymar_guzman, 

I just review the sequence and indeed we´re experimenting an unexpected behavior with the Step.ResultRecordingOption callback. By some reason, when you run the callback in the Pre-expression section of each step, the instruction only executes until the next sequence is called, which is not what we want. 

In order to avoid this, you can place a statement before every step in the sequence, so you can change the state of the "Result Recording Option" for the running sequence, (and not until the next one). You can try something like this 


  

where the statement expression will be the callback "RunState.NextStep.ResultRecordingOption = YourCondition". With this we guarantee that the next step results will be recorded or not. I also remove the expession in the Pre-expression section for every step, because now the condition is on the statement before each step.

I tried this and it works just fine. I´ll attach the sequence you share with me, with the modifications. I hope this will help you and resolved your problem.

[James_Grey]

The Step Execution table in the help at Fundamentals>>Executions>>Result Collection>>Step Execution,
shows that allocating the step result is step 1 and evaluating the pre-expression is not done until step 13. Thus the pre-expression can't alter the result allocation for the same execution of a step.

This is the expected behavior.

[josymar_guzman]

Thank you very much Omar, it was exactly what i wanted to do.

- Josymar.

[josymar_guzman]

Thank you James, i will definitely consider this table (amount other things i found out because of your comment) for better sequence designs from now on. You're right it is an expected behavior. Thanks again for your feedback.

- Josymar.

[Omar_R]

I also did some research and indeed is an expected behavior. 
http://zone.ni.com/reference/en-XX/help/370052M-01/tsfundamentals/infotopics/step_execution/

Glad to heard the solution did work !