LabVIEW changes enumeration constant values randomly

[gi_virtualspot]

Hi, I sure the same frustration with the enum constant in LV2011 as well.

Currently we are developing an application that uses both lvlibp and LV classes. We build the lvlibp in a sequential hierarchy depending on its dependency with each other.  For example, if lvlibp-2 depends on lvlibp-1, then a project file is created for lvlibp-1 to build the lvlibp-1 first.  Then, another project file is created for lvlibp-2 to build the lvlibp-2.  We build the exe and the lvlibp files successfully.

However, these issues have repeatedly been seen in executable but not in the LabVIEW development environment:

- We use a enum typedef in our queue state machine, but the enum sometimes generate invalid value (ie. if the enum typedef has value 0 to 3, but the returned value is 65535 or larger value which is not seen in the development IDE).

- We have seen that when using the "Build path" VI from the default LabVIEW palette, receiving the path input from a packed library VI and a fixed file name, the VI returned a wrong path (The same problem is not observed in the development IDE).

- We also observe that in one of the VI where we perform array operation, the array returned the wrong result (The same problem is not seen in the development IDE and somehow, it is fixed itself when we just put a "One Button Dialog" VI to examine the array output.

- We also found out that sometimes when those above issues got resolved itself when we put "One Button Dialog" VI on the block diagram without other code change.  However, it is not ideal to have the dialog window.  Sometimes we can solve the problem by having a disable diagram enclosed a dialog VI.

Anyone else experience the same issue?  Anyone found a workaround?

Thanks  

[Roy_F]

---

dlanger wrote:

...
PS: maybe I should mention that I have selected the option "Separate compiled code from source file". Given that the compiled code now sits at some other place than inside my subversion-guarded directories, this might explain why the corrupted code is not reflected in any change of the source files.

---

And very glad that you did!

We think the problem has to do with that feature and can be avoided by not using that option. We have more investigation to do, but our understanding the problem and being able to characterize it well looks promising.

Roy

[Fred_V]

We're still investigating this issue, but even with code, it has proven difficult to reproduce.

If someone has code that can reliably reproduce this issue, please let us know.

We will continue to investigate, and report on that investigation here.

Thanks,

[gi_virtualspot]

Hi, I forgot to mention that the LabVIEW environment we tested on is LV2011-f2.  We are currently using string combo box typedef instead of enum typedef.  It is less ideal but it managed to bypass the enum constant typedef issue.

Cheers,

Steve

[D*]

I've seen this a few times using LV 2010 SP1. At first I thought I was going crazy. One thing I noticed, is that it is related to "Separate compiled code from source file" feature. 

Also, it might be a coincidence but I just recently used the "mark project items" option in the project properties to mark various .vi's instead of going to the properties page of each .vi:

When I marked a bunch of .vi's, I don't remember if I had .vi's open at the time or not.

[D*]

I just saw this happen again!! Scary stuff. I found that clearing the object cache and reloading the .vi's restored the proper enum values.

[Ben]

---

@D* wrote:

I just saw this happen again!! Scary stuff. I found that clearing the object cache and reloading the .vi's restored the proper enum values.

---

Do you have before and after backups?

Ditto the scarry part!

"Once burned, twice werry (sp?)"

THe first time I got hit with a type def not updating correctly it was in LV 7.0 where Bundle by names would choose the wrong itme if the data type was the same(that bug has been fixed).

My customer at the time upgraded the LV 6.1 code (logged data 24 X 7 forrever) noticed app started loading slower and slower as time went on. Turns out the "Start" and "End" times in a clsuter controlling how much history to load on boot-up got scrambled and the "End" Time was writen twice and the "Start" was left at the default. This reslted in all history for all time being loaded at start-up. I took it on the chin as a typo on my part. Only latter to learn that LV had "helped out" with that screw-up.

Second time i made a small change to code and after the customer tried running the code he sent me an e-mail reading me the riot act "WHat, dont you even check your work? Why is my torque showing up in my RPM indicator?" Again, LV had done me in.

To this day I  avoid rearanging type defs, and back-up before and after and will resist the temptation to remove un-used stuff.

Type-defs are one of the greatest features of LV when they work correctly. WHen the fail they can do you in big time.

Ben

[euTeam]

I have the same problem posted (in Italian) here.

I use subversion and in my project I marked all vi to "separate compiled code from vi".

Sometimes (rarely) enum typedefs change in first value (I think default). I confirm that no change occur in my vi (where enum is used), depends on compiled code, clean compiled object cache and open vi with typedef constant become correct, but open main (first node of hierarchy) and here I thing all is recompiled, enum constant in "my vi" become again incorrect.

I observed also that main vi (first node of hierarchy) sometimes loose option "Mark vi to separate compiled code from vi".

Other similar problems here:

http://lavag.org/topic/15877-to-remove-compiled-code-or-not-that-is-the-question/

http://forums.ni.com/t5/LabVIEW/Separate-Complied-Code-bug/td-p/1991219

[D*]

Backups didn't matter, since the .vi was unchanged. In other words, loading the .vi with a "corrupted" object cache, would display and use the wrong enum values. Loading that identical .vi with a cleared object cache, would display and use the correct enum values.

In either case, the .vi is not marked as changed (i.e. no "*" in the title bar). (gulp)

[Fred_V]

Thanks to both of you for bringing this issue up again. As mentioned before, this has proven difficult to reproduce in-house.

Could I ask, that if someone encounters this issue, they make a copy of the VIObjCache database (often found in C:\Program Files (x86)\National Instruments\LabVIEW 2011\VIObjCache) before clearing it, and then to forward the corrupt database and the associated source code to support? Mentioning this thread, should get it brought our attention immediately, and I'm hopeful that the nature of the database corruption will give some indication of the root cause.

Thanks again,