12-16-2011 08:22 AM
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")
12-20-2011 10:42 AM
Here are two videos demonstrating the cycle of the weird behaviour:
What the videos show:
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.
12-20-2011 10:48 AM
Could you possibly share that code with NI to allow them to investigate further?
Ben
12-20-2011 11:23 AM
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.
12-20-2011 12:23 PM - edited 12-20-2011 12:29 PM
I just reported the problem to NI. We can provide a guest login to our SVN repository to interested parties by email.
01-10-2012 07:40 AM
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.
01-10-2012 07:44 AM
@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.
Ouch and double ouch!
Please post the SR number and I will see if I can get this escalated.
Ben
01-10-2012 03:57 PM
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.
01-10-2012 07:07 PM
"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.
01-11-2012 04:11 AM
@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.