NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Keeping Certain Records out of the PROP_RESULT table

Solved!
Go to solution

Hi all,

 

This is going to be one of those situations that's hard to describe succinctly... but here it goes.

 

I'm using TestStand 2017 and I have a custom model plugin that handles our model customizations. (This avoids having to modify the NI process models)

 

In the model customization plugin, I'm using the "Model Plugin - OnTheFly Step Results" entry point to iterate over step results and process certain tasks. One of these tasks is to look for the presence of certain additional results, which we use to populate columns in our STEP_RESULT table.  For example, if we have a numeric additional result named "temperature", the plugin OTF entry point is getting the numeric value and attaching it in a special container to each result.

 

The operation of attaching the container looks like:

Parameters.Result.AsPropertyObject.NewSubProperty("Custom",PropValType_Container,False,"",PropOption_DoNothingIfExists),
Parameters.Result->Custom.NewSubProperty("Temperature",PropValType_Number,False,"",PropOption_DoNothingIfExists),
Parameters.Result->Custom.Temperature = Locals.ThisAdditionalResult.AsPropertyObject.GetValNumber("",0),

Then from our modified database logging schema, I can reference the variable.

STEP_RESULT.STEP_TEMPERATURE = Logging.StepResult.Custom.Temperature

This works great. It populates the additional columns we have so that we can efficiently query off of them later on.

The problem is that this also inserts two records in the PROP_RESULT table:

  1. Custom, which is of type container
  2. Temperature, which is of type numeric.

We don't want these additional records in PROP_RESULT and we have myriad such records now. (Temperature is only one such value of a handful.)

I tried setting PropFlags_DontCopyToResults on the variables I created above, but unfortunately since I'm doing this from the model plugin, it's already too late and this setting does nothing.

 

Is there any way to be able to reference the variables from the schema but not include them in PROP_RESULT?

 

Thanks for reading all of this.

 

Mr. Jim

0 Kudos
Message 1 of 2
(2,778 Views)
Solution
Accepted by topic author Mr._Jim

I believe I have arrived at a solution. If I attach my "Custom" container to Result->Common, the container and all its subproperties get conveyed as before to the database plugin. However, by using the "Common" container as the parent property, the database plugin does not add superfluous PROP_RESULT records.

 

I figured this out from experimentation - it's kind of a hack, but the TestStand engine doesn't complain if I add subproperties to the Common container at runtime, even though "Common" is of type CommonResults.

 

(See also this help article about "Error" and "CommonResults")

 

For any poor soul who finds themselves in another one of my obscure conundrums, this seems to work.

 

Mr. Jim

Message 2 of 2
(2,757 Views)