LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW changes enumeration constant values randomly

Thanks Ben..

 

I am currently writing LVOOP programs and use type defs all the time.  I did notice that it slows down saving, but I have never seen an enumerator reset to its default or first value.  It would be a pain to update all those controls if they were not type defs.. 😄

 

Diagram disables... you mean the structure?  I use those also.  Which means so far, I do things similar to them, but did not see that issue.

And yes, for something external to affect that part of the code would seem very unlikely...

 

Hence this silly question:

 

Other than that enum, do you modify that vi?  If not, can you add a new comment or something inside the block diagram to make sure that what you see is the actual last version.

 

(I did say "silly")

0 Kudos
Message 11 of 45
(1,522 Views)

Here are two videos demonstrating the cycle of the weird behaviour:

 

  1. http://screencast.com/t/JkUqIPmbclC
  2. http://screencast.com/t/V06ibqc3

What the videos show:

  1. We open the project containing the class with the method containing the enum constant. When we begin, the enum constant is already corrupted.
  2. When we try to perform an SVN commit, we see that the source files are not changed relative to the repository.
  3. We delete the whole project folder and perform an SVN update to refetch the files from the repository (which are identical to those just deleted!!!).
  4. We re-open the project and the class method VI. Now, the enum constant has the correct value!
  5. We close the project and open the main project, where we start the main VI that dynamically loads the class we just looked at.
  6. In the "Items in memory", we open the problematic method VI. The value has fallen back to NULL (which is the enum default/item 0)!
  7. We close the main project and re-open the class project as in step 1. The enum value is still NULL as in step 6.
  8. Trying to perform an SVN commit as in step 2 demonstrates that the source files have not changed.

 

Given that for all our VIs we use the "Separate compiled code from source file", we conclude that the corruption is actually in the compiled code and not in the source file.

 

0 Kudos
Message 12 of 45
(1,498 Views)

Could you possibly share that code with NI to allow them to investigate further?

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 13 of 45
(1,492 Views)

As our licence number is in the movie file, I cannot show any more the movie.

 

If someone from NI is interested, I can send the movies. Nevertheless, the story remains the same.

0 Kudos
Message 14 of 45
(1,480 Views)

I just reported the problem to NI. We can provide a guest login to our SVN repository to interested parties by email.

Message 15 of 45
(1,467 Views)

No response to my support request to NI so far.

 

As a consequence, we decided to replace all relevant enumeration constants (a few hundred in our project) by string constants and convert them to the appropriate enumeration type-defs on-the-fly. An example is shown below.

 

work-around for screwed enum constants

Message 16 of 45
(1,413 Views)

@dlanger wrote:

No response to my support request to NI so far.

 

As a consequence, we decided to replace all relevant enumeration constants (a few hundred in our project) by string constants and convert them to the appropriate enumeration type-defs on-the-fly. An example is shown below.

 

work-around for screwed enum constants



Ouch and double ouch!

 

Please post the SR number and I will see if I can get this escalated.

 

Ben

 

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 17 of 45
(1,409 Views)

I remember that an ex-colleague has been facing the same issue in 2005 (?) when working on a set of VIs that were originally created in LV7.0 and then taken to LV7.1: He also claimed that when opening the top-level VI it was a good idea to look at the BD. In case any type-def'd enum constant was defaulted, he closed LabVIEW and re-opened this VI. This usually solved the issue.

The affected BD constants were also strictly type-def'd.  I do not believe that he posted this observation to this forum or to NI.

AFAIK, noone of my colleages has confirmed this bad behaviour when working with LabVIEW since then. However, in 2005, LabVIEW did not have any projects, conditional disables, and much more...  I expected this "feature" to be identified and fixed in between.

0 Kudos
Message 18 of 45
(1,380 Views)

"Harlequinade wrote:

Given that for all our VIs we use the "Separate compiled code from source file", we conclude that the corruption is actually in the compiled code and not in the source file."

 

Oh yes and I'll add LV2010 SP1 is the all new optimized compiler. Don't know if you already tried "Clear compiled Object cache" already. Or another long shot is extraneous code thats in you Project i.e. unfinished or unused methods of a class.

0 Kudos
Message 19 of 45
(1,370 Views)

@richjoh wrote:

@"Harlequinade wrote:

Given that for all our VIs we use the "Separate compiled code from source file", we conclude that the corruption is actually in the compiled code and not in the source file."

 

Oh yes and I'll add LV2010 SP1 is the all new optimized compiler. Don't know if you already tried "Clear compiled Object cache" already. Or another long shot is extraneous code thats in you Project i.e. unfinished or unused methods of a class.


Thanks for this input. We tried that method this morning. After clearing the compiled object cache, we went through steps 1-6 the procedure described in one of the posts above. No different behaviour was observed (i.e., the enum constants still got screwed up). Before re-opening the class project (according to step 7), we cleared again the compiled object cache. Indeed, now the enum constants were fine.

 

This makes complete sense assuming that the on-the-fly compiling during dynamic class loading when running the main project (step 5) is creating corrupted compiled code that somehow affects the displayed source code. If we clear the compiled object cache afterwards, it forces re-compiling when opening the class project just like when we freshly obtain the source code from the SVN repository. Compiling when opening a class in its LV project directly (i.e., "static" instead of dynamic loading) leads to correct compiling.

0 Kudos
Message 20 of 45
(1,351 Views)