NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Step.Result.PassFail

I have upgraded from TestStand 1.0.3 to 2.0.1

In version 1.0.3, I used to set the "Data Source Expression" to Step.Result.PassFail to have TestStand test the PassFail Flag boolean in the Test Data Cluster.

How do I do this in version 2.0.1?

I can only find Step.Result.String, which is a string and not a boolean.

Thanks.
0 Kudos
Message 1 of 6
(4,471 Views)
Hi qedesigns,

Its the same.

The String Test Value step type gives you the Step.Result.String property!

Regards
Ray Farmer
Regards
Ray Farmer
0 Kudos
Message 2 of 6
(4,471 Views)
Hi,

I don't understand.

What do I have to put as the Data Source Expression to get the Pass/Fail Flag boolean in the test data cluster? I want to have TestStand test the state of this boolean.

I would expect to use Step.Result.Status (string)
with "True" (ignore case) as a limit, but this does not work.

Thanks
0 Kudos
Message 3 of 6
(4,471 Views)
Hi,

Ok,

TestStand 1.0.x evaluated the Pass/Fail Step as 'Step.Result.PassFail ? "Passed" : "Failed"'

Teststand 2.0.x evaluates the Pass/Fail Step as
'Step.DataSource != "Step.Result.PassFail" ? Step.Result.PassFail = Evaluate(Step.DataSource): False, Step.Result.PassFail ? "Passed" : "Failed"'.

Therefore for TestStand 1.0.x Step Type the result must be in Step.Result.PassFail.

If you as using a TestStand 2.0.x Step type you will be able to use another data source because the result will be obtained from the Evaluate(Step.DataSource).

Eg If your result was in a string variable Locals.MyResult = "False" and your DataSource was set to Locals.MyResult. The Evaluate(Ste.DataSource) would give a result as False in the boolean Step.Result.Pa
ssFail.

Check whats in the Status Expression in the property of your step.

Regards
Ray Farmer
Regards
Ray Farmer
0 Kudos
Message 5 of 6
(4,471 Views)
I am afraid that it is not very clear what you want to do. However, you must know that the step types have NOT changed from TestStand 1.0.3 to 2.0.x. If you know how to use them in TS 1.0.3 you should be able to use them in TS 2.0.x.

The Pass/Fail step type will have its Data Source Expression set to Step.Result.PassFail by default, while a String Value Test step will have it set to "Step.Result.String". Probably you were checking this last step type instead of a Pass/Fail Step type.

You can change the Data Source Expression to point to any property that you wish (although it's NOT common to change its default value). The Test Data Cluster will ALWAYS write to the "PassFail" property of a Pass/Fail Test step, to the "String" property of a String
Value Test step and to the "Numeric" property of a Numeric Limit Test step. This is true EVEN when the Data Source Expression points to ANY other property.

I hope it is clearer this time.

Regards,

Carlos Leon
0 Kudos
Message 6 of 6
(4,471 Views)
Ray is correct in that the method has not changed between TS 1.0.x and 2.x. It sounds like the problem is that you are using 2 different step types in TS 1.0.3 and 2.0.1.

In TS 1.x you were probably using a Pass/Fail Test step type. This step type has the the property Step.Result.PassFail. In 2.x you are probably using the String Value Test step type that has the property Step.Result.String. Each of these step types base their outcome on these properties, respectively. This outcome is determined by the status expression of each step (go to the step properties dialog box and switch to the Expressions tab to view the value of the Status Expression control).

The Pass/Fail Test step type does not have the property Step.Result.String, and the String Value Test ste
p type does not have the property Step.Result.PassFail. In addition, in the dialog box that you use to set the Data Source Expresion, you will find 2 tabs for the String Value Test step type, one for limits and one for sting limits and one for data source expression, while there are no tabs for the Pass/Fail Test step type which only allows you to set the data source expression.

I hope this explanation allows you to deduce the cause of the problem.
0 Kudos
Message 4 of 6
(4,471 Views)