Test.Step.Result as Enumerated type

[JÞB]

It is rather well known in the LabVIEW community that I only use TestStand when I need to.

Frankly, I do not consider that choosing the datatype for Step.Test.Result as Boolean was proper and hence, TestStand Results<> negated its application as an experiment development environment.  Specifically,  Test Results may "Pass" without performing complete experiments or, UUTs may "Fail" for Errored or Aborted sequences when "Partially Teasted."

My belief has always been that a Step.Result would necessarily be Enumerated with a default "untested" value that would update to Pass, Fail, Aborted, Skipped, Error, etc....

I do not understand why override of the Step.Result type has never been permitted which, has led me to write my own TestEngines more than once.

What would I really need to do to redefine the datatype of Step.Result from T/F to an enum?

[Oli_Wachno]

Hey Jeff,

don't know if I understand you correctly.

Step.Result is what TestStand calls a Container which is sth like a cluster in LabVIEW except it is not strictly typed.

Thus, dependeing on the TestType you are using, a typed property is added like Step.Result.Numeric (obviously Numeric Type) for a Numeric Limit Test or Step.Result.PassFail for a PassFail Test (Boolean in this case).

The actual evaluation of the Test is reflected in Step.Result.Status which is a string ("Passed", "Failed", "Done", ...)

So in fact, a TestStand Step is executed like

1.) Do some Pre-Module Execution Magic

2.) Call a (LabVIEW) Code Module

3.) Copy the result from the Code Module to Step.Result.Whatever

4.) Evaluate Step.Result.Whatever against Limits/ expected values and set Step.Result.Status to "Passed" or "Failed" (Evaluation Done via Status Expression)

5.) Do some Post-Module Execution Magic

Not really sure if this helps, yet I being aware of this concept, I don't know if you really need that enum.

If you do: you can always have a Custom Step Type based on the standard, which has that Enum added to the Step.Result Container, yet you have to make sure that the value is set correctly either during the evaluation of the Status Expression or the Post-Module Execution Magic.

Please also be aware, that you would have to do some things in the result collection to include this value into the standard reports. If you're using customized reporting you'd have to take care of this anyway.

[JÞB]

---

@Oli_Wachno wrote:

Hey Jeff,

don't know if I understand you correctly.

Step.Result is what TestStand calls a Container which is sth like a cluster in LabVIEW except it is not strictly typed.

Thus, dependeing on the TestType you are using, a typed property is added like Step.Result.Numeric (obviously Numeric Type) for a Numeric Limit Test or Step.Result.PassFail for a PassFail Test (Boolean in this case).

The actual evaluation of the Test is reflected in Step.Result.Status which is a string ("Passed", "Failed", "Done", ...)

So in fact, a TestStand Step is executed like

1.) Do some Pre-Module Execution Magic

2.) Call a (LabVIEW) Code Module

3.) Copy the result from the Code Module to Step.Result.Whatever

4.) Evaluate Step.Result.Whatever against Limits/ expected values and set Step.Result.Status to "Passed" or "Failed" (Evaluation Done via Status Expression)

5.) Do some Post-Module Execution Magic

Not really sure if this helps, yet I being aware of this concept, I don't know if you really need that enum.

If you do: you can always have a Custom Step Type based on the standard, which has that Enum added to the Step.Result Container, yet you have to make sure that the value is set correctly either during the evaluation of the Status Expression or the Post-Module Execution Magic.

Please also be aware, that you would have to do some things in the result collection to include this value into the standard reports. If you're using customized reporting you'd have to take care of this anyway.

---

It's been just Jay for a while.   Nice to know people remember "Jeff." (Still he him his) 😄

Step.Result as Boolean is "ubiquitous."  And, Step.Result was foundational in TestStand's development...and a poor choice of datatype.  Bare in mind that I've actually USED the LabVIEW 5.1 Test Executive. 

A Boolean result never made good experiment design.   "Test" must always be a subset of "Experiment" and always should have been thoughtfully approached with TestStand Step Results.  Boolean is a poor choice of datatype!

Hence, what is needed to expand the boolean to something that holds data?

Perhaps, that is a question for @Shauna Rae.