Reason for enumeration typedef constant reset to zero in an executable after Labview Upgrade?

[SBach]

Hi everybody,

I had a problem with a changed enumeration constant in an executable built from a LabVIEW VI. I got rid of it but now I hope somebody can tell me the background to make sure I did make things worse.

Background:

1. We run Win 10 as OS.
2. In our project we use the producer consumer  pattern to send commands with parameters to different sub-VIs over queues. These commands are defined as typedefs of enumerations to make sure they update everywhere simultaneously.
3. We upgraded from LabVIEW 2012, 32 Bit to LabVIEW 2016, 32 lately.
4. On LabVIEW 2012 both the execution of the main VI in LabVIEW and the compiled executable worked fine.
5. On Labview 2016 the execution in LabVIEW also works fine, but as soon as I compile everything into an executable (unchanged build rule)my program does no longer work.

Reason for the problem:

Some constants of the command enumeration change their value in the executable to "zero" ( -> first element of the enum)

See the attached picture as an example: "1" is the code in the VI , "2" is the same code in the executable as seen with the debug application tool.

It happens not at all positions, but only in the main VI. In a sub-VI, the constant in the Sub VI does not change and keeps the correct value.
The change effects multiple type defs and does not appear randomly: Any given constant in the code either does change or it does not.

Tried solutions:

I did some reading:
https://forums.ni.com/t5/LabVIEW/LabVIEW-changes-enumeration-constant-values-randomly/td-p/1764684
http://forums.ni.com/t5/LabVIEW/What-would-cause-a-enum-typedef-constant-changes-during/m-p/1102737#...

but none of these threads fit my problem exactly so I tried to:
1) Replace the enum constant  ->  did not help.
2) Resave the Typedefinition -> did not help.
3) Clear the compile cache and recompiled the whole project -> did not help.

I finally found one thing that seems to help:
Set the checkbox "Disconnect Type definitions" in the advances exclusions tab before compiling. This way the constant remains unchanged in the executable. But now I am unsure if this really fix the problem or if it just works at some points but not at others.

So (finally) my question is:
Does anybody know what is the real problem underneath and can explain to me why that workaround helps? Are there any obvious drawbacks in that approach? ( like possible problems with typecasts for example)

Regards,

Bachi

[Ben]

The issue you saw is NOT with the enum but rather with the cluster that contains the enum.

Near the end of my Nugget on Type definitions found here I pointed out that the type definition defines the data type not the value. Default values in cluster will change if you change the type definition of the cluster.

The correct way to handle this situation is first note that the nature of a type definition (i.e. data type not values) and code to account for this.

Again, in that nugget I suggested explicitly using a bundle by name to ensure the value you want to be a constant survives changes or upgrades.

Now as to why...

In a dark office far far away and a long time ago...

I was developing on a very old machine. While editing a type definition and applying the change, I was able to witness LV in slow motion, deleting the old cluster and replacing it with the new definition. In short the defaults are lost because the old version was deleted!

I hope that helps!

Ben

[SBach]

Hello Ben,

Thanks for the quick reply. I read your nugget and found it very interesting.

Your suggested way to use sub-VIs for setting the default value sounds like a good solution to the problem for clusters.

Nevertheless I am not sure if my problem is caused by the described replacement of typedefinitions after a change done to them.

I did not change the typedef now, but did it many times in the past. The project contains many typedefs of enumerations , which all were changed multiple times in the last 5 years. As long as I used LabVIEW 2012 I never encountered any problems.

Now I switch to LabVIEW 2016 without changing the typedefs and the problem appears.

Also my type definition is not on the cluster but on the enumeration inside the cluster.

That means I don't have "a [typedef of cluster with (an enum and a variant)]" but "a cluster with [a (typedef of enum) and a variant]".

I am not sure if your example with changing constants applies to that case or if it is just for clusters. Does it apply to enumerations, too?

If it applies to enumerations,  I am not sure how to fix that without rewriting all the code of the last 5 years.

Regards,

SBach