Enum in a Typedef Reverts to Default (LabVIEW 2009)

[JackDunaway]

When I add additional items to a typedef'd enum, constants of that enum on some BD's revert back to the default zero index enum value. In the past (8.6.1 and previous), adding items to an enum in no way would ever change constants that were already dropped on a BD. Now, in LabVIEW 2009, when I add items, about 60-70% of the constants dropped on different block diagrams will be changed to default value.

This happens in a "large" enum (~400 elements) that spans about 3 dozen VI's between RT and HMI block diagrams (a total of about 300 instances). This is a mature project that has never had this problem with 8.2, 8.5, 8.6, or 8.6.1...

I cannot post an example, because in the process of stripping down the VI, the problem goes away. It is extremely repeatable in the context of the project, but I cannot repeat it on an individual VI basis.

The current workaround is to edit the typedef'd enum while all referencing VI's are in memory. If the VI's that use the typedef are in memory, they will always properly recompile and maintain the correct constant value. However, if the VI is not in memory, and the typedef is changed, the next time the VI is opened, when it recompiles it will change the constants back to the zero index default value of the enum in only about 60-70% of VI's. Unfortunately, we cannot yet find a common thread in the VI's that recompile wrong, and the ones that recompile correctly. 

Has anyone ever seen this problem? Suggestions?

Best regards,

Jack

[Jarrod_S.]

I have seen this behavior before as well. It has been reported to R&D for further investigation (CAR# 178614). I do not know of a workaround at this time, other than the steps you listed.

[JackDunaway]

Jarrod:

Thanks for the quick reply. We first became aware of this bug yesterday, and found the workaround fairly quickly. Although the workaround is relatively simple, it presents a huge technical hurdle: SCC between half a dozen developers. Like I mentioned, this large enum is referenced in several dozen VI's between both the HMI and RT projects. When changes are made to this enum, every single referencing VI must also be checked in to the repo to ensure it has properly recompiled with the right constants.

There's also the problem of dynamically called VI's in the HMI. These are not loaded into memory just by opening the top level, so they must be opened individually.

Since this is an enum we will update often, we will need a long term fix that does not require all referencing VI's to be updated and checked in whenever the enum is changed. 

Jack

[Ben]

Hi Jarod,

Could youplease research and report back in this bug and the associated bug of type clusters bundling teh wrong values (not usre if fixed in 2009).

From what Jack reported and you confirmed we have to edit enums with all VIs open and for the cluster we should edit the cluster THEN open all.

THis starting to sound like "if the moon is full and the entrails are ...."

You have not lived until you have to deal with one of these situations and four developers have managed to uncover these conditions in an app with over 1K VI to check. It took me half a day and had to unwind all of the updates to get back toa good state.

Ben 

Jack,

We use a Tree VI that holds a top level copy of all dynamic VIs to avoid this issue.

Message Edited by Ben on 09-16-2009 08:48 AM

[Jarrod_S.]

Jack,

I noticed when reproducing this issue on my side that the behavior is very finnicky. You noticed that too when trying to reproduce it on a smaller scale.

One thing I noticed - and I am very far from sure that this is any type of workaround - is that if I force-recompile (Ctrl-Run Button) the VI that gets affected by the enum change and save it before editing the enum, the enum constants on that block diagram do not get affected, even when the enum is edited with the VI not in memory. Even though the affected VI did not claim to need to be saved, force-recompiling it in advance of the enum edits seemed to avoid the problem on a small-scale.

Is there any way to test if you see this same change of behavior on your side? It might only be testable if you do indeed get this reproducing on a smaller scale.

I have seen this behavior appear on different-sized enums, not just those with 100+ elements. The harmful enum changes can involve adding new elements or just renaming existing elements. And the common thread appears to be that certain VIs are more vulnerable than others, and these only get affected when the enum edits occur with the VI not in memory.

[JackDunaway]

We just realized a flaw in our "workaround", as partially pointed out by Ben (he was probably typing his response as we were confirming it here). If the constant is inside of a cluster on the BD, even if it is in memory, it will null out the enum inside of the constant. Therefore, the "workaround" is to rewrite the clustered enum constants from scratch (in other words, there's no workaround). Two of us spent a decent portion of the morning finally nailing this as the source of what we thought was an unrelated bug... and that's after spending a long day yesterday trying to find a fix. Yes, we feel Ben's angst of reverting back to previous SCC editions and manually editing dozens of VIs.

The severity of this bug is a showstopper for us. We cannot risk adding elements to an enum and consequently have referencing VIs changing their constants.

Force compiling a VI one at a time is not an option for us. I know this bug manifests itself even after a mass compile. So, is there a way to "mass force re-compile" that we could test?

[Jarrod_S.]

You can force-recompile an entire hierarchy of VIs at once by opening the top-level VI and clicking Ctrl-Shift-Run instead of just Ctrl-Run. Then Save All. This of course supposes that there is some top-level VI for your application, which could be problematic with your dynamic plug-in architecture.

Note again, that I'm not claiming this will fix the problem, just that so far it has had some success in limited situations.

Message Edited by Jarrod S. on 09-16-2009 01:02 PM

[JackDunaway]

If we force recompile the entire project and save all, we would have to check in to SCC a total of 1k+ VI's and controls for RT and HMI just to add an item to an enum. This cannot be a solution.

To circumvent the constant enum-in-a-cluster-in-an-array problem, we have dropped discrete constants of the enum on the BD, then used bundle then build array. (Thank goodness for constant folding!) This is much less than ideal, but hopefully will at least keep the bugs at bay with the original workaround of keeping the VI's in memory.

[Jarrod_S.]

---

JackDunaway (mechelecengr) wrote:

If we force recompile the entire project and save all, we would have to check in to SCC a total of 1k+ VI's and controls for RT and HMI just to add an item to an enum. This cannot be a solution.

To circumvent the constant enum-in-a-cluster-in-an-array problem, we have dropped discrete constants of the enum on the BD, then used bundle then build array. (Thank goodness for constant folding!) This is much less than ideal, but hopefully will at least keep the bugs at bay with the original workaround of keeping the VI's in memory.

---

Yes, I do realize this is not a practical step for development.

Regarding manually bundling in the enum into the cluster, this is something I've been doing religiously for years. Someone told me a long time ago to always do this, because changes to the cluster could affect the constant values of their child controls. I was never sure what exact situations could cause that, but it was just a matter of precaution. So it might be good practice regardless.

That said, this is a different and new situation we're seeing here with the enums losing their values because of edits to the enums themselves.

One thing you'll have to guard against when dealing with multiple developers and SCC is that even though you have your 1000+ VIs open when editing your enum, you won't check in all those VIs. This means that although the bug might not present itself on your machine, your coworker could sync to your changes and have it pop upon their machine. This was the problem we were having. When we would check in our code, it would be in a good state on our machine. But then a coworker would sync and open the project and be in a bad state.

[Neil.Pate]

Wow, this bug really scares me, as it seems its easy to not notice the affects and have crazy behaviour!

I am assuming this is a 2009 bug as I have not heard of anything similar to this in 8.6.1 and lower?