Locals.UUT customizations deleted upon install of 2014 diskset

[david_jenkinson]

Hi,

We have customized the UUT data type used in our customized process model to include details such as Manufacturer, hardware rev etc.  We also have the process model seqeuence source controlled under a different directory than the default location.

It seems that when loading the process model after installation, teststand has taken the liberty of deleting all of these customizations, including the sub-container "config", another data type we've customized, which contains numerous properties that we change at run time to suit the current UUT under test.  I can go and manually fix this, but I've had no problems in past update disks.  IMO this should not happen, I should get a type conflict error and a prompt to resolve. 

I did get an error upon first running prompting me to open modelsupport.seq, which I did, but it did not indicate anything had changed. 

Why did this happen, and can this behavior be avoided in future diskette installs? 

I have attached images of the data type before and after.

[dug9000]

One way to workaround this issue is to put all of the types you modified into a type palette file. If you do that then you will get a conflict at startup like you are requesting. The downside though is that you will still need to merge your changes in with the ones made to teststand (choosing just yours or just the teststand version is likely not sufficient).

In the future, for TestStand 2013 and higher, I'd recommend that you no longer modify the shipped process model types and instead add any custom data to the unstructured "AdditionalData" subproperty that the UUT type now contains.

Let me know if you have any questions regarding this. Hope this helps,

-Doug

[david_jenkinson]

Yes we do have several custom type palettes we utilize for several purposes, but in this case we chose to modify this existing type  because the data stored fit there. 

If I move the custom properties from the top level of Locals.UUT to the "additionaldata" sub property/cluster, I can assume that future installs will not modify this?

Thanks

[dug9000]

---

@david_jenkinson wrote:

Yes we do have several custom type palettes we utilize for several purposes, but in this case we chose to modify this existing type  because the data stored fit there. 

If I move the custom properties from the top level of Locals.UUT to the "additionaldata" sub property/cluster, I can assume that future installs will not modify this?

Thanks

---

Yes, but you need to add the properties you want to the instance, not the type definition (i.e. do not modify the UUT type, instead just add properties directly to the Locals.UUT.AdditionalData container. You can even add them programmatically at runtime). AdditionalData was added in TestStand 2013. It's an unstructured property, which means its structure is not defined by the type definition so instances can have anything under that property and it does not get modified by the type, nor does it modify the type when you add properties to an instance under that property.

Hope this helps,

-Doug

[david_jenkinson]

Ya I understand that, data type instances can differ, and not affect the definition, which should always be the behavior. Also it seems the definition of this locals.uut type is defined in the process model itself, not a type palette  "ini" file, as you mentioned previously. However there are many instances I am using, all within the process model (pre/post uut, setup and cleanup sequences) where an instance of this type is inserted in the parameters of these process model sequences so that changes to them can be passed on within the process model.  I am also using programatic references to runstate.locals.uut.<property> speckled throughout my sequence code.  The overwriting of the type definition broke all of this. Changes to the definition in the type palette (when the process model sequences is seleced) has always changed the contents of the instances, which has been the desired behaviour in my application. 

A large reason and advantage to use a data type is the fact you can change the definition in one place, and have the instances reflect that definition everywhere it is used, so that you do not have to comb through every instance to make identical changes.  That is in fact how I was using this type. So the "unstructured" portion of this type introduced in 2013 which is "not defined by the type definition so instances can have anything under that property and it does not get modified by the type" is completely contrary to what I think a type definition is useful for, in the case anyway.  Of course no changes to any instance should ever modify the type definition, as that would be contrary to the point of having a "definition" at all.

Due to the apparent unstructured nature of this "additionalData" container, and the fact I cannot modify the Locals.UUT type and be sure it doesn't get changed and over-written by NI, I've started the work of defining a "DUT" data type and placing this in the process model locals, the contents of this type is identical to my previous modifications to Locals.UUT.  I am about half way through combing through all of my test case sequences, of which there are many, replacing references.  Not too happy about it but a learning lesson for sure. 

[dug9000]

What you can do is define your own type that you own (so it won't be overwritten by future versions of teststand) and put an instance of that under Locals.UUT.AdditionalData. That way you will get the best of both worlds:

1) Changes to the teststand type won't affect your code.

2) You can change your type that you own to automatically update all of the locations in which it's used.

Or

3) if you want the most minimal change to what you were doing originally, then create a version of the UUT type based on the current teststand type and just readd your changes to that and put it in a type palette with a type version higher than the one used by the current version of TestStand. This should only take a short amount of time and should require very few changes. You don't have to switch to using AdditionaData, that is just a suggestion for future use.

-Doug

[david_jenkinson]

That is in fact what I did at first, tried to move the changes under additionaldata.  But my changes did not seem to propogate to the other instances I had in the process model (located in the parameters of the processsetup,preuut, etc).  And when thinking about it, they probably shouldn't, because the definition is in fact elsewhere, not the process model, which was the root of this issue.  This is why it was changed without notice.  I'm not sure where this master definition is though, but it is somewhere other than the process model.

So I created a completely separate one to avoid any strange issues and added this type to one of our pertinent type palette ini files. It's going well, I actually have some of my sequences running ok as of about an hour ago.  Find/Replace on a directory structure made it much easier.

David J.