RunState.Step.TS.NoResult setting persist after execution

[ebalci]

Hi,

I used to think that if a property in the RunState container, like RunState.Step.TS.NoResult, is modified it would only affect the execution-time properties.

However when I set RunState.Step.TS.NoResult (or similarly RunState.PreviousStep.TS.NoResult and RunState.NextStep.TS.NoResult) to False, the Record Result setting in the Run Options is modified.

If the step is set to record its result and if I put a statement step just next to it with RunState.PreviousStep.TS.NoResult = True, I see (after the execution) that checkbox for Record Result is cleared for that step.

I also tried the ActiveX version using TestStand 3.5 API call but I got the same effect.

Is this the expected behavior?

If so, how can we "volatilely" disable result recording for a single step so that the edit-time properties are not affected??

[AndrewMc]

Hey S. Eren,

What you are seeing is expected behavior.  Not everything in the RunState container is a run-time copy.  In this case, notice that everything in Step.TS has the same behavior.  If you modify any of the variables in that container, the change is reflected both at run-time and edit-time.

That being said, if you are wanting your change to modify the run-time copy only, what you can do is set NoResult back to false after the step has executed.  Notice that the NoResult property is evaluated during the run-time of a particular step; once that determination has been made, the result will either be present in the ResultList or not, regardless of what setting is later specified.  Using this knowledge, you can simply set RunState.Step.TS.NoResult = false in the Post-Expression of your step.  If NoResult has been set to true previously during the execution, the result for that step will remain unrecorded while the edit-time copy of the setting is retained.

Hope this helps!

[ebalci]

What I am actually want to do is to hide a step's result if it passes and to display it if it fails.
Such an easy thing -unfortunately- takes an extra step to program in TestStand.
It should be an inherent property within each step, a separate option in, for example, Run Options tab.

Let's say I have 2 initialization steps for a device.
If any of them fails test cannot start and I want to display the error message if this happens.
If both are OK then no results in the log file.
Now I can accomplish this with 4 steps total.
I believe it is not possible to do it with no extra steps. Am I right?

[AndrewMc]

If that's all you're wanting to do, there are several ways to do it and one is very easy.  Simply go to Configure>>Report Options and modify Result Filtering Expression.  Most likely you are seeking the preconfigured option if you select the drop-down menu and select "Exclude Passed/Done/Skipped".  If not, you can select it and then modify the conditions.

[ebalci]

Hi Andrew,

I am aware of the solution you have suggested. There is a Turkish saying about this: "I asked you to hit him, you killed him" 🙂

We use test reports to prove that a UUT has actually "passed" the test and keep it for later reference.
Because someone may want to examine it to solve a later problem.

If I exlude every measurement that passes, then for a successful UUT, there would be "nothing" to log actually!
Device initialization is a part of the test. Because if smth is wrong with the device itself or the device drivers in the test PC or the connection between them, then the test operator should be informed with an exact error message (not a simple "test setup initalization failed"), so that necessary action can be taken.
If there is nothing wrong with the test equipment hardware, then it is completely unnecessary to display "Passed" in the log for the power supply initialization. Because it adds a considerable amount to the line count of the log when you have like 40-50 instruments in the test setup.

By the way, result filtering is not available for XML reports.

Message Edited by ebalci on 08-20-2007 10:31 AM

[James_Grey]

I'm not sure how convenient this would be for your use case, but as a workaround you can delete elements from the result list after they are added. One method to do this is to call PropertyObject.DeleteElements. Another is to use the RemoveElements expression function. Note that you can find the number of elements currently in the result list with PropertyObject.GetNumElements or the GetNumElements expression function.

[OmarGator]

We handle errors like failure to connect to UUT or failure to power up UUT through the ERROR cluster. Steps that are needed, but are not exactly a "test". No report entry unless there is a problem.

Jim D.

[ebalci]

Hi Jim,

I am not quite sure about the "ERROR cluster"? Is it the one used in TestStand ActiveX API calls?

Can you elaborate on the usage of it for avoiding pass results for not-exactly-a-test steps?

Thanks.

[OmarGator]

Sorry "Cluster" is a LabVIEW term.

In TestStand it is the Step.Result.Error

Step.Result.Error.Code

Step.Result.Error.Msg

Step.Result.Error.Occurred

Our dlls, CVI or LabVIEW code modules return any errors via these return parameters.

Normally if  you have a GPIB error or communication error this is where they are passed back to TestStand.

I also use this to pass back error or failures for problems that are not true tests. Now this will cause the test to abort and jump to your CleanUp.

I create Error states and provide detail messages about the error and how to fix it.

Pass back a TRUE to 'Step.Result.Error.Occurred'. Include any message about the error an a string to 'Step.Result.Error.Msg'  I don't do much with the Error.Code

For an example, we test for the correct fixture ID as a test step before powering up the UUT. At first it was a normal PASS/FAIL test, producing a line item in the report file. But I switched it to an Action step with NO reporting and pass any problems via the error parameter. Now if everything is OK, nothing is reported in the report file. But if it is the wrong fixture to operator get a nice big ERROR popup and an entery in the report file. The ERROR pop up display the message that I sent back that you do not get with the default FAIL pop up.