Unable to update the existing type definition for a cluster containing an enum type definition from a LabVIEW code module

[bienieck]

Hi, I found some strange behavior in TestStand. It is as described in known issues https://www.ni.com/pl-pl/support/documentation/bugs/19/teststand-2019-known-issues.html#662205_by_Ca... but not for the array of clusters but just for clusters.

So, I have a problem to update the container type definition containing enum type definition in TestStand.

The example is as follows:

• Create a sequence file with a LabVIEW call.
• Called VI will have a cluster containing numeric, string and typedef enum.
• Create a type definition for this cluster in TestStand by clicking on Create/Update Custom Datat Type... button in the type column for the code module parameter.
• 
• Create a new parameter with the newly created type.

Now all is working as it is in attached EnumUpdateBug_1.seq. We have 2 new type definitions in TestStand: one for cluster and one for enum.

Next, try to update the enum definition in LabVIEW and later in TestStand.

• Change LabVIEW enum type definition - e.g. change one item text (see EnumUpdateBug_2.seq).
• Then, in TestStand you will see the red exclamation mark because you changed the VI. Click on it and let TestStand accept the fact.
• We don't see any issues at first glance, but then if we check enum in our parameters we can see that we don't have the same enum that we have in LabVIEW. If we click to check expression (red checkmark) where our parameter is used in the code module we see "no errors". But when we click Create/Update Custom Datat Type... button again. Then we see that we have a mismatch. It suggests using a new data type for our enum - it doesn't want to automatically link it with our enum typedef...
• 

We need to uncheck "Force Exact Match" and manually select types...

After we click Update we don't see any changes. Our updated type definition remains the same - enum looks like it was before, no update. Our LabVIEW call seems to be ok (no red marks of any sort) but if we look closer we can see the message...

To me, it looks like the bug described in know issues but just with clusters. The suggested workaround is not really helpful if you need to manually update the type everywhere...

[bienieck]

Could any NI employee respond to this topic? This problem makes my job very difficult.

[TRJ · Accepted solution]

Hi Michał,

This issue has been fixed in TestStand 2020, which will be the next version to be released later this year.

Since you are on an older version, you will have to use a workaround. You've mentioned that updating the type manually is difficult. Is this because you have the same type defined in multiple sequence/type palette files? Otherwise, you only need to manually update the type definition of the enum once and the changes should reflect in all instances of the type.

If you do have the same type definition saved in multiple sequence files, then consider moving it to a common type palette file and removing it from all other places. Then you'll only need to update the type definition in one place.

Regards,

Tinu

[TRJ]

I also wanted to add that you can use the Create/Update Custom Data Type From Enum dialog to automatically update the Enum type definition instead of doing it manually.

You can do this by expanding the cluster and hitting the button present in the Type column of the enum parameter (highlighted in the image above). In the dialog that comes up, choose the Update tab and the existing enum type definition to update in the combo-box.

Hope this helps.

Regards,

Tinu

[bienieck]

Thank you TRJ. I dealt with my issue this way: I have this cluster typedef with enum typdef. No mater what I tried Update Custom Data Type feature always wanted from me to create new enum typdef in TestStand. So, I let the updater to create one and later I just needed to do some manual work with removing the old enum typdef and renaming the new one (used in the cluster). It's not ideal but it works.