Additional Results Condition Not Working Correctly For Parameters

[~jiggawax~]

TestStand 2014

Trying to log a parameter only if the step status is "Failed" won't log the parameter when the step actually fails.  However, variables with the same condition will log just fine.

The attached sequence demonstrates this.  Basically I have a subsequence that returns a random number and a string as parameters.  I use the random number to evaluate against my limits for the test call.  I want to log the string parameter only if the step fails.  So I set it as an additional result and set the condition to

Step.Result.Status == "Failed"

The data never shows on the report.

But when I put an explicit additional result with the same local variable and put the exact same condition it shows on the report when the step fails.

I'm baffled as to why parameters won't log with this condition but explicit additional results work just fine with the same condition.

Any thoughts?

Thanks,

[4Matted]

Jiggawax,

Could you please clarify for me what you are expecting to see on the report. When I loaded your sequence and ran it, the test failed and in the report the parameter some string was included in the report. Is this not what you are seeing? Or am I misunderstanding the question? Thanks for clarifying.

[dug9000 · Accepted solution]

The condition for the parameter's additional result is evaluted before the sequence call's status is set to failed. The 'out' parameter additional results are probably being evaluated right after the code module call, so if the the step's status isn't changed by the code module call, then it will still be "Running".

I can see how it would be nice if it worked the way you are asking, but keep in mind for in/out parameters it's typically the same expression/variable in both the 'in' and 'out' additional result, so the time at which the result is logged is important. It has to be done before the code module call for 'in' parameters and after the code module call for 'out' parameters in order to accurately reflect the state of the variables at those points in time. I think the intent is that the additional result for parameters should reflect the state of the variables at the point in time immediately right before the call for 'in' parameters and immediately after the call for 'out' parameters. Thus if you want to conditionally log a value based on the status (where the status is not changed directly by the code module), then using a regular additional result like you discovered is probably the best way to go.

Perhaps for out parameters we could delay logging until the very end, but that might result in a change in behavior if the variable state changes again before that. If you would like for us to consider that or have another idea for how to handle this better please let us know or perhaps post something to the Idea Exchange.

Another possibility is that we could temporarily log the results before and after the code module call, but then not evaluate the condition until the very end and throw out the logged result if the condition is false. That might still cause a change in behavior though if the "Value to Log" expressions have side-effects.

Hope this helps clarify things.

-Doug

[~jiggawax~]

Thanks Doug,

Exactly what I was looking for.  As long as I understand how it all works I can work with it.  I'm not sure on a suggestion.  I can see pros and cons to doing it both ways.

Maybe updating this to reflect how additional results work:

http://zone.ni.com/reference/en-XX/help/370052N-01/tsfundamentals/infotopics/step_execution/

Much Appreciated,

[GarryG]

I'm strongly in favor of documenting it more thoroughly as Jiggawax suggested.  This was the first place I looked to see if I could find an answer, but there's nothing mentioned there about exactly when those conditions are calculated.

[dug9000]

I will look into getting the documentation updated.

Thanks for letting us know.

-Doug