proper type palette use scenarios

[chilidog]

This thread is to continue the discussion started in another thread I created about SCM and type files

[chilidog]

---

@~~jiggawax~ wrote:

Dug,

First of all we don't ever load 2 automations at the same time. (our definition of an automation is the MainSequence file and any dependencies).  If you think about an automation as a stand alone application then it makes sense not to rely on some type in a different file.  That is how it is done in most software applications.

The only time we would ever have conflicts is if our baseline package (i.e. the process model and its dependencies) ever changed a type.  Well, to solve that we develop against the baseline package that is on the deployment machines.  We can roll our SCC back to the timestamp in which the baseline was rolled out.

I think you missed my point about code modules.  Especially the LabVIEW code modules.  If a type in the palette changes, now your container that was being passed to the VI no longer matches up with the cluster connected to the connector pane.  This causes run time errors.  It is bad. If we were to centralize our type palettes this would happen all the time.

In summary:

On the development envrionments we absolutely have it centralized.  In the deployment environment we like to think of each automation as a stand alone package.

Sorry chilidog... you have spurred a great conversation about type usage...

---

Jig,

I actually do load 2 different sequence files during an execution.  I have a master sequence that is written for the handler that the devices are tested on and I dynamically load a slave sequence file which contains sequences that are called in the mastersequence.  I need to pass information between the 2 using types I have saved in the types file.  This is why I don't want all my sequences to contain copies of the common types, I want them to get type information from a deployed type palette and this is why I want to manage the type palette using SCM tools

Dug,

any comments on this?

Chilidog

[~jiggawax~]

We do something similar where we are dynamically calling helper sequence files.  However, because they were developed together the types exist in both sequences as the same version and they are deployed as a package.  So therefore we don't rely on type palettes at all on deployed machines other than the native types.  Which we don't ever touch.

We also have standards for naming types.  We always prefix our types with the name of the project or scope of the type.  That way we technically can have multiple automations open if we needed and wouldn't see the conflicts.

[dug9000]

I think in cases in which you do want to enforce that all files loaded on a machine are using the same version of a type, you should use a type palette file for that type.

Relying on the fact that files were developed together isn't entirely foolproof because if the files weren't saved together then they could still have different versions of the type saved in them because they could have last been saved at different times when different versions of the type existed. If you have a process for loading and resaving all of those files before deploying though that might be a good way to handle it.

That said, I can see how it might be inconvenient to use type palettes in the case of data structure types used with cluster/struct passing, especially if you have multiple sequences with different clusters/structs with the same name, or different versions of those clusters/structs. However, if you want to strictly require that all sequence files on the machine use the same definition for a particular cluster/struct then it probably would still be best to put the type for that cluster/struct in a type palette.

-Doug