Updating enum defined in called sequence in a caller

[Michałek]

in SequenceFile "A.seq" I have defined an enum "enumA" and one subsequence with a parameter using that enum type.

in SequenceFile "B.seq" I am calling this subsequence. writing in the value "Enums.enumA.firstenumerator" - so far everything perfect.

Now close B.seq, add new enumerator "secondnumerator" in A.seq. close A.seq, unload modules, open B.seq, run it - it throws an error that the definition is different. and it seems that B.seq has a copy of that enum.
Is there any way that caller will update the definition based on called sequence? i.e. should the definition of that enum be kept only where it have been created.

I know that I can solve it using "ini" file and make it more global. and that this approach (i.e. defining enum in seq file) can make a problem that I can have C.seq with enum type with the same name as in A.seq and then have some conflict.

[~jiggawax~]

Not sure what is going with your specific scenario but maybe I can give you some insight that will help:

Whenever the TestStand engine loads, and specifically the application manager starts, it brings all of the type palettes into memory.  There is a single place in the engine where all types exist regardless of which file they are defined in.  Whenever 2 types try to enter into that place that have the same name then the engine tries to resolve them.  By default it is set to load the latest version of the 2 types and then pushes that version out to everything that is loaded in memory and marks it as changed.  You can change the setting by going to Configure>>Station Options and then clicking on the File Tab.  There is a dropdown called: Allow Automatic Type Conflict Resolution.  I like to set it to Never because then I can ALWAYS see when TestStand is trying to push my types around to different files and I can choose what I want to happen.

Whenever you use an instance of a type in a sequence file the type gets copied down to the sequence file.  This is so that the sequence files can stand independently without having the type palettes loaded.

Personally I never define types in palettes.  I haven't found a good reason to do so yet.  I especially don't do it on deployment machines.  It screws everything up if you have multiple automations on that bench.

If I were you I would just put an instance of your enum in all 3 of your sequence files.

Hope this helps,

[Michałek]

Thanks for the answer. I will try to put it in another words.

Also I think it is not only enums related but basically how TestStand handles types.

Let's try again 🙂

The trick is: for now I don't want to use Type Pallets. I know that maybe I should, I know also benefits from that (https://www.ni.com/en/support/documentation/supplemental/08/teststand-type-management-best-practices...).

I would like to define a new custom data type inside sequence file.

e.g John has created Vehicles_lib.seq, sequence called "Activate Engine" with parameter "Kind" type enum with enumerators: "car", "locomotive". so the enum has 0.0.0.1 version.

(names means - separate instances of the teststands and separate machines, so nothing is loaded in the memory).

Mark has just created "Driving.seq", Enums.Kind is not visible there - this is clear. In MainSequence Driving.seq Mark uses sequence call to "Activate Engine". Enum is visible, I can use it, and it has been automatically copied down to the sequence file (as you wrote) with version 0.0.0.1.

John updates "Kind" in Vehicles_lib.seq - it is version 0.0.0.2 now.

Mark runs Driving.seq and gets error (not type conflict messege!): "type 'Kind' is invalid.... you should open the files with conflicting types". Deleting this sequence call and adding new nothing changes, still in Driving.seq there is version 0.0.0.1.

so at the first time trick works: Driving.seq has used custom data type from Vehicles_lib.seq. but it does not work afterwards and it cannot be resolved automatically. The only way seems to open both sequence files on the same machine.

this is quite strange. either it should not be possible for the first time (since data type is not in "common" type pallets) or it should be possible to update it in the same way as it is with type pallets so using settings from "station options -> file".

what is also interesting that even if there is no instance of type "Kind" left, then still it is visible as type in Sequence file even after "unload all modules" until teststand is switched off and on again.