Enum constant changing value at runtime LV 2011

[testingHotAir]

Hi all,

I have a program with a simple state machine which runs off a typedef enum constant.  When I run the VI, the actual value passed out of the CONSTANT seems to revert to "0" randomly.  Please see the two attached screenshots.

The only thing that definitely turns the bug on is connecting the enum wire to a selector (which I like to do to detect and handle errors).  Nothing definitely turns the bug off 😞

This bug is almost identical to the one discussed in this thread here, which claims the bug was fixed in LV 8.0.1.  I'm running 32-bit LV 11.0 on windows 7.  Any idea how to kill this bug?

[Darin.K · Accepted solution]

Whenever I see things like this my first instinct is to drop an 'Always Copy' node following the constant.

[elset191]

---

@testingHotAir wrote:

This bug is almost identical to the one discussed in this thread here, which claims the bug was fixed in LV 8.0.1.  I'm running 32-bit LV 11.0 on windows 7.  Any idea how to kill this bug?

---

In the lava thread referenced in the link you gave, it says disconnecting it from the typedef makes the bug go away.  Is that true?  

[testingHotAir]

Disconnecting it from the typedef did not work for me, though I didn't disconnect all the instances on the diagram so that might be why.  I really don't want to abandon typdef'd enums in my VIs....that would be a major nightmare.

I've never tried the Always Copy node....

I may have other problems though as the VI is now crashing labview every time I run it.

[testingHotAir]

Fixed the crashing issue; I was opening a reference to a VI in a packed library inside an in place element structure that was operating on a DVR of the class that owned the VI I was trying to reference. 

Now my only bug is the enum one!

Putting Always Copy nodes after EVERY CONSTANT instance of my typedef does seem to solve the problem, but is extremely annoying.

[Ben]

Enums changing is a show-stopper for me.

If this bug is for real it is devistating.

Sanity check questions.

Q1:

Are you sure the value of the enum is changing (it goes to the wrong state) and not just the probe being bogus?

Q2:

Did you try to search on all instances of that enum and verify there are as many instances as are used in the code? I ask to rule the possiblity you have two type-defs that have the same number of entries but different definitions. It would be very hard to spot this issue if you are not looking for it.

Q3:

Does it act the same in an older version of LV?

Q4:

Do we have a CAR for this yet?

If this bug is real, I will be advising people NOT to use LV 2011. It sounds like it manifest itself as the LV equivilent of a "Goto Random" statement which would be bad.

Curious,

Ben

[falkpl]

"Goto Random" didnt see this on the ideas forum. 

Has this bug been confirmed, I have some pressure to move to 2011 from 2010 and could use a reason to pospone this change.

[Ben]

---

@falkpl wrote:

"Goto Random" didnt see this on the ideas forum. 

Has this bug been confirmed, I have some pressure to move to 2011 from 2010 and could use a reason to pospone this change.

---

I logged SR 1840861 to get some attention on this issue.

I am hoping this is something simple.

Ben

[Darin.K]

I have lobbied to get the icon of the Always Copy node changed to a Band Aid as I only use it to fix these crazy, that should not happen bugs. There are two types of problem I have seen which are fixed by this: improper buffer reuse for constants (what this appears to be), and cases where there is a bug in folded code that does not appear in normal code. Does changing to strict TD help? It shouldn't, but what kind of guarantee is that? 🙂

[testingHotAir]

Ben,

A1:  Yes, the VI goes to the wrong state when the probe shows the constant changing.  Happens with no probe too.

A2:  I searched all instances and verified that are only as many instances in the list as appear in the VI.

A3:  I don't have access to an older version so I can't be sure.

A4:  No CAR yet.

I agree on this being a show stopper.  Hope it's just something I did! 🙂