Enum constant changing value at runtime LV 2011

[Jeff.St]

Is the engineer you mentioned still assisting you with your SR?  I want to make sure this problem is fully looked at.

Thanks!

[testingHotAir]

Yes, he is.  Right now he's having trouble reproducing it on his side so we're going back and forth.

[testingHotAir]

I've been trying to reproduce the problem as well and have been unable to, however I did manage to get a boolean constant to return the wrong value at runtime!  See attached screenshots.  This has got to be a problem on my end...

More strange happenings that may be useful to know: All the VIs and libraries are stored on a network drive.  When I go to build the packed libraries, I have to close the project, open it back up, then - WITHOUT TOUCHING ANYTHING ELSE - open the build specs and right-click build the library.  If I don't, I get one of the attached warnings for each VI in the library, after which the build fails.

[Igor_Titov]

I ran into quite a similar problem. In runtime on PXI (LabView 2011, LabView RT 2011) enum from strict typedef is connected to case selector, thus implementing simple state machine. It worked properly before but things went wrong only today. To illustrate the issue I made a simplified version of this loop in the same VI, but without any actual logic. I tried to reproduce this bug in the blank VI (in the same project, with the same typedef) but there it works as expected. So, 

In the debug mode one can see that strict typedefs constants went crazy in runtime. This is a printscreen of the very first iteration (believe me, subsequent iteration don't get any sanity either - it switches randomly between 0th and any other state). Instead of entering "Init Steppers" state QSM goes to "Idle Steppers" and on the Probe Watch it says "Shutdown Steppers". Then it has a choice of "Idle Steppers" or "Shutdown Steppers" and it chooses "Init Steppers". Probe Watch nodes show "Shutdown" and "Sent Position Y" states. Moreover, nodes [4] and [5] show old values and aren't willing to update. Then it jumps all over states quite unpredictably... 

After reading previous posts I disconnected constants from typedef and it indeed helped but only for one run. Even if it would help for good, this is not a solution because it undermines the meaning and the usage of strict typedefs.

So, definitely it's a bug in LabView 2011.

Looking forward to some fix of this bug.

Igor Titov, CLD.

CERN.

[testingHotAir]

The engineer helping me with this issue was able to reproduce my boolean constant bug.  CAR 354325 has been filed to look into it.

[testingHotAir]

Igor,

In your VI, do you have any event or case structures where you have an error wire exiting with "use default if unwired" checked?  On my boolean constant problem, changing the "use default..." setting to a linked tunnel turned the problem on and off.

[Igor_Titov]

No, I don't have any events here (because it's on Real-time target) and I don't use "use default if uwired".

The problem doesn't go away even if I create a new case structure and a new typedef. The problem reappears anew in this VI. 

[testingHotAir]

That does sound exactly like the problem I am having.  Have you contacted NI support about it yet?

[Igor_Titov]

Nope, it's a holiday today at Switzerland and I stumbled upon this bug yesterday . So, tomorrow I'll try to add a new VI into the project and recreate the algorithm. If it still doesn't work, then I'll contact NI. But NI should pay (THE) closest attention to this bug - it's fundamental, not just "color of the plot 2 on the waveform changes back to red after I ...". If we don't have this functionality working properly, then LV2011 is not usable. In fact, it's very hard to find such bug because when it works for some time, you add some code and everything stops working, you blame this last chunk of code and spend hours trying to understand what's wrong in it. Bug in LabView is the last thing I can think of during this process.

[Zach-H]

@ Igor - Could you post up that VI and the type def? I'd like to see if I can verify the behavior on a target on my end. 

You said you recreated the VI and no longer saw the issue, correct? I'm wondering if the VI or reference to the type def in the VI somehow became corrupt.