Update of container variables

[pwaszkewitz]

Hello,

in TestStand 4.1.0, I noticed that, when I change a container type by adding new elements that variables of that type automatically receive the new elements, but without their default values (I am using this as a replacement for constant values which TestStand does not have). Instead, the new elements receive the value 0 (they are all numbers).

Following questions:

• Are variables inside sequence files automatically updated on load of the sequence file? or only for sequence files currently in memory when the type is changed?
• Is that behavior of using 0 as the default value instead of the default value in the type definition by design or a bug?

and a request: I think it would be good to have Constants to TestStand, i.e., type-like definitions in a TypePalette-INI-file which can be used without an instance of a variable.

Regards

Peter

[RuedigerE]

Hi Peter,

I noticed the same behaviour of TestStand and will look for a workaround.

Regards

Rüdiger

[RuedigerE · Accepted solution]

Hi,

I talked to a colleague and I think his aswer is very good (please see the attachement).

Regards

Rüdiger

[pwaszkewitz]

Hi,

yes that is a consistent explanation. I overlooked the "Apply values..." button. By the way: with automatic resolution of type conflicts (as long as no INI files are changed) the values are automatically used by sequences which are not in memory during editing of the type; as described.

Thanks

Peter

[dug9000]

I'd like to clear up some potential misunderstandings:

1) The values of variables in a type are default values, once the variables exists in an instance then changing the default value of the type's version of the variable does NOT automatically change the instance's values.

2) However if you edit a custom type and add new variables to it and give them new values BEFORE opening a file which contains instances of that type. Then when you open a file containing instances it will get its initial values as specified in the type because the variables did not yet exist in the instances saved in the file.

3) If instead you had the file with the instances opened while making the edits to the type then what happened is as soon as you inserted the variables into the type, the instances were immediately updated and given the default value at the time (which was 0). Then the subsequent edits to the values did not effect those instances because they already had the variables in them.

4) You can update all opened instances of a type when setting a value using the Apply change to all instaces checkbox of the properties dialog, but that does not effect instance that aren't already opened.

5) For constants I'd recommend you use Station Globals or FileGlobals rather than type definitons, but if you do use type definitions you can set a special flag on its containers or variables marking them as shared. This means that when instances are created these shared properties are actually from the original type definition rather than being copies. This means if they are changed anywhere, even at runtime, the change effects all instances, because they are all effectively sharing the same properties.

Hope this helps clarify things,

-Doug

[pwaszkewitz]

Hi Doug,

thank you for the clarification, that helps a lot.

The way we use these type definitions as "constants" is to define StationGlobal or FileGlobal instances that then have these values. Of course, anyone can change these values in the sequence file.

If I understand correctly, the sharing flag has the effect that the values are identical everywhere (inside one process, I assume), regardless whether the change is done in the type definition or from within a running sequence. This is very useful, so I will add this property.Nevertheless, I would appreciate it if TestStand had actual constants, in the sense of values that are always read from the type definition (like the shared properties), and can only be changed in the type definition (unlike the shared properties) .

Best regards,

Peter

[dug9000]

The sequence editor does disallow editing shared properties from anywhere other than the type definition (Technically it allows editing from the original location which in your case will be the type definition. The shared flag is not specific to type definitions), however this is not enforced at the API level so they can still be modified programmatically (and I think from expressions too).

Also, some clarification on how shared properties work:

If you set a container as shared in a type definition that effectively makes everything underneath it shared too because the version of that container in the instances is really just a pointer back to the original property. Therefore you might want to make a container under which all of your constants exist, then you will only need to mark that container as shared.

Hope this helps,

-Doug