I have a simple .vi that uses a queued state machine using typedef enum constants. A very common technique in a state machine.

What I didn't expect was the typedef enum constant (yes, a constant!) to change during execution. Quite a serious bug.

This was originally LV7.0 code, converted it to LV7.1 but the problem exists. I have not tried LV8.0 (haven't even taken it out of shrink wrap yet).

NI is looking into this, issue #7105073.

Todd

I can see this too (7.1) and try few things - the only thing that help was to disconnect the constant from the typedef
so its look like the problem is in the typedef.

I tried that before and it didn't work. I even re-created the type-def completely, and it didn't work.

What did work was to replace the 'enqueue element' at the problem location in the code.

Watch how tnhe constant changes during execution...then changes back when the program stops!

It didn't take long to track down this problem since the code from this was taken is quite simple.

Confirmed on LabVIEW 8.0 as well - as suggested, disconnecting it from the typedef fixes it...

A big question is why is this happening in the first place? Can we ever trust queued state machines again using typedef enums?

NI is looking into it; I will provide and update here when I get an answer.

I suspect is a casting problem, something usual with enums. In fact, if you explicitly typecast the constant to U16 the problem dissapears... So in some step LabVIEW doesn't know what representation is that control.

Unfortunately I have no more time today, tomorrow I'll check it more deeply.

Saludos,
Aitor

I took a quick peek at this the other day and it reminds me of a similar "form" of bug that involved a cluster. It looks like the optimization and buffer re-use logic is out of whack. The original buffer holding the constant is being updated instead of copied. Code changes that force execution order can help. Looks like constant folding is out of control.

Just my quick guess,

Ben

Off topic, but Ben- just one more post to go. Sorry, no stars

Yes, that's true. And I think the problem is located in the queue creation. If you just rewire it or wire another copy of the enum constant, the problem solves. So I suspect that first constant set to "key id" is corrupt and, from that point, LabVIEW loses a valid reference to the object and what the heck it is.

In fact, if we knew how to reproduce this, it would be really interesting to change constants in run time

Saludos,
Aitor

Paraphrasing a posting by Rolf years ago....

"Self- modifying code is a very bad idea."

OT > AK2DM

I am finding it hard to navigate without the stars.

Ben

I know that I said that there are no stars here, but it was slightly changed since then. If you really want to give stars, each thread has a Rating button hiding on top, which rates the entire thread.
Personally, I find the NI forums much easier to use than the LAVA forums (even though LAVA has a significantly larger number of features). This is mostly because the NI forums have a much cleaner design (simple colors, mostly text) and because there it is easier to follow when things get posted (since LAVA is influenced by your logins and not by whether you actually read the posts). As long as LAVA doesn't have too much activity, though, it's not too much to handle. Thanks, Michael and team.

Not necessarily the same VI, but between them. Here the .ctl is in fact working as a external variable, in a very simple manner. Maybe this works between different runtimes too, all accessing the same type definition. Well, OK, probably not .

Saludos,
Aitor

...but then it's not a constant

Here is NI's response:

-------

R&D have identified your issue as a bug and it will be fixed in the next release/patch for LabVIEW. Please let me know if you have any other questions about this issue.

-------

I have added this thread to the official NI BUg List that can be found here.

http://forums.ni.com/ni/board/message?boar...message.id=1882

For those of you that do not frequent the NI Developer Exchange I want to make sure you are aware that the NI Bug List is now Official as I mention here. (See reply #20).

http://forums.ni.com/ni/board/message?boar...message.id=1698

The Official NI Bug list should NOT be viewed as competition for the LAVA Bug List. It should be viewed as a compliment of same.

"Keep them bug and letters coming!"

Ben