LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Enum constant changing value at runtime LV 2011

Solved!
Go to solution

To Zach-H:

 

I recreated only this simple state machine with this typedef in a new VI and it worked, yes (without any other logic). However typedef + case structure don't work together in the old VI where I have all the code I need for the project - not only this typedef, but any new typedef created after bug appeared for the first time. I'll post this VI and typedef tomorrow when I get back to work.

 

Igor Titov

Software Engineer

CERN, Geneva

CLD 

=========================
Igor Titov, ex-CLA
ex-Labicom.net, ex-CERN, etc.
0 Kudos
Message 41 of 43
(554 Views)

So, update for today on crazy typedefs. There are bad news and good news.

1) Today I can't reproduce this bug every run. Sometimes it shows up, sometimes not. (bad news)

2) I placed all the logic in a new VI in this project but it didn't help - typedefs are still jumping. (bad news)

3) But there was a clear pattern (after second wasted working day) - it's closely related to the structure of this VI. In troublesome version of this VI I had three loops (one for digitizers, one for radiometer and one for steppers). The only communication between them is a shared variable "Stop" that stops all loops. So, no typedefs intersect anywhere. After some hours of pure desperation I found out that commenting out radiometer loop doesn't make any difference. Commenting out digitizers loop makes all the difference though. When it's commented out, in most cases typedefs obey the law. Otherwise, in most cases they are outlaws. Anyway, I need all the devices for this project and even more will add up in a few days.

Note: radiometer is accessed by pure LabView instrument driver written by me. Digitizers (troublemakers) are accessed by Agilent drivers with calls to dll's. Who knows what exactly they do with a memory... But it's just my supposition - I have no idea about a real reason. 

 

4) So, the solution that seems to work for now (I do hope that it will be true on Monday Smiley Very Happy ) is to place every loop in different subVIs

5) The bug is visible only in the project scope. So, if you or any other NI employee would give me an e-mail, I would rather send the whole project (it's impossible to post it here) - you'll see nothing strange in just this VI and typedef.

=========================
Igor Titov, ex-CLA
ex-Labicom.net, ex-CERN, etc.
0 Kudos
Message 42 of 43
(515 Views)

Hmm...the implication of dll's interests me.  The project that I'm having this issue with uses packed project libraries, which are similar to dll's (in my limited understanding of them).

CLAD
0 Kudos
Message 43 of 43
(508 Views)