LabVIEW changes enumeration constant values randomly

[dlanger]

I am currently bothered by an extremely annoying LabVIEW bug: constants of enumerations (strict type definitions) often fall back to the first list entry (i.e., the 0 value). Specifically, I use "strict-type-def" enumerations to represent messages that are sent via queues between different VIs.

Example:

I have the following enumeration: NULL, initialise, terminate, start, stop. In a specific VI, a constant of this enumeration type with value start is enqueued. That's how I coded it, that's how it should be. Now I open the block diagram of this very VI (maybe I have to mention that the VI is a method of a LVOOP class that gets dynamically loaded at run-time, so I open it from the "Items in Memory" in the LV project browser). And guess what? The enumeration constant now has the value NULL instead of start:

I don't have to mention that my LabVIEW application doesn't work anymore under these circumstances... So I close it and open another LV project that contains the class harbouring this method VI directly (i.e., no dynamical loading). The constant is still corrupted (same as above).

Luckily, I use Subversion. However, Subversion doesn't show any changes to the file! How can it be corrupted then?

So we might figure that it was already corrupted at the time of the last commit to the Subversion repository... However, I have some doubts. So I delete the whole folder and fetch it again from the repository and open again the project with the class. And now the constant is fine!!!! How can that be???????

Also in the main application, which loads the class dynamically, everything is fine now:

As weird as this is, the really annoying thing is that I encounter this problem over and over again, with the same and also with other VIs. I feel like running in a circle fixing bugs that LabVIEW introduces while running in front of me...

So, the big question: how can this weird behaviour be explained and what can I do to get rid of it so I can go back to productive work?

Thanks a lot for any hints.

PS: maybe I should mention that I have selected the option "Separate compiled code from source file". Given that the compiled code now sits at some other place than inside my subversion-guarded directories, this might explain why the corrupted code is not reflected in any change of the source files.

[Ben]

Is that LV 2010 or 2011  (which) ?

Ben

[dlanger]

It's LV2010 SP1 32bit on Windows 7 32bit.

[Ben]

I can not speak to the conditional disable possibly having an effect but I type-def'd enum all of the time and the only time I see anything like that is if I delete an entry from the enum.

Re:Strict

Strict only applies to the FP only and has no effect on the diagram constants.

If you can reproduce this efect I urge you to share it with NI so they can fix it.

Ben

[AustinManinTown]

Try changing the custom control to just typedef. I haven't tried this, but I am wondering if the strict typedef is causing the constant to revert back to the default value? I'll try and recreate this when I am front of a computer.

[dan_u]

---

@Ben wrote:

I can not speak to the conditional disable possibly having an effect but I type-def'd enum all of the time ...

---

I havent seen the problem with the enum changing values either (except when changing the enum). I would also try to put the constant outside the conditional disable structure. Probably it "forgets" the value when a different case is active. Still if this happens I would consider it a bug but at least putting the constant outside the structure would be a simple workaround.

[Harlequinade]

I work on the same project. It also happens independent of (conditional) disable structures.

It isn't reproducible on purpose on the same VIs, but it happens randomly on different VIs. The annoying thing is that such a fallback on the default value doens't generate errors and makes bugtracking really really difficult. Furthermore fixing the enums to the desired value doesn't help much, as later another one falls back to the default value.

[Ben]

Getting a backup before and after the bug hits you would be a start in trying to narrow down the possibilities. If you can document what you did between Good and Bad would also help.

SInce we don't have any others seeing this issue, I have to suspect that there is something that your team is doing that is invoking this bug and until we find a way of reproducing it, I can't sceam at NI to fix it.

Take care,

Ben

[Ray.R]

I read through the thread and must say that I have never experienced that behavior with LV 2010 SP1 (or without SP1).

Even on projects with multiple developers, with code repository using SVN.

I agree with Ben that it appears to be something outside LabVIEW.  It is definitely a strange behavior which is not obvious.  I do hope you find what caused this behavior and post it.  It may help us in the future..

[Ben]

I don't suspect something outside of LV yet. I suspect the team is doing something novel that the rest of us are not doing so they see it and we do not.

Example:

I somehow got the idea that mixing type defs with LVOOP was dangerous so I am seldom mixing the two. From what I see above, the team is mixing LVOOP type defs and diagram disables (another thing I do rarely being and old-school case structure with boolean to comment out guy).

Ben