LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Unbundle nodes different when loaded on different machines (LV 2018 SP1)

Solved!
Go to solution

I'm dealing with what may be a LabVIEW bug.   I'm migrating to a new work machine and some of my VI's are broken because Unbundle nodes on a class wire have mysteriously relinked to different values (subcluster items with the same label name).  These are identical copies of code, synced from SCC and loaded without modification.

 

Below is an example of one of two vis which have broken.    Both of the broken vis are related to unbundle nodes on this one rather complicated class.  I can fix this easily, but, I'm concerned about why it happened and do I need to be concerned that it may have happened silently in other parts of my code.   In particular I can see these two problems due to type mismatches, but, what if there wasn't a type conflict?  How can I be sure the rest of my code has integrity?

 

 

Labview Version: 18.0.1f4 (64 bit)

Original Code:

Thomas_robertson_0-1600712259318.png

Code after loading on new machine:

Thomas_robertson_1-1600713211261.png

 

 

0 Kudos
Message 1 of 6
(1,423 Views)
Solution
Accepted by topic author Thomas_robertson

Do you have a simple reproducing case?  It looks like LabVIEW is mixing up some reference and just pulling the reference by name.  

 

Have you tried a "Clear Compile Cache" and then "Mass Compile" on the new machine?  

 

Also, HOW complicated is the class?  It looks very large from the second image you shared.

Regards,

Ben Johnson
ʕง•ᴥ•ʔง
0 Kudos
Message 2 of 6
(1,330 Views)

I've observed cases of LV pulling data from compiled cache even when it's outdated.

 

I've updated code in a really old repository (9 months old), opened the code and bam - a typedef which hasn't been used in months appears in the code. The only place this can possibly come from is the compiled cache. The source code contains the correct typedef, opening it on a machine WITHOUT cache works fine.

 

Really worrying is that if I then save the VI with the wrong typedef in memory, it gets committed to source code. This is backwards dependencies. The source code possibly inheriting from the compile cache.  This had us scratching our heads for a few days and of course any attampt to reproduce the issue in a smaller code set failed.

 

So yes, try clearing your compile cache and see if the problem still persists. Or if your code suits and you can re-create the problem, please report it to NI.

0 Kudos
Message 3 of 6
(1,325 Views)

What would happen if the compile cache was copied to the new PC? Not the right thing to do but perhaps that would work.

Certified LabVIEW Architect
0 Kudos
Message 4 of 6
(1,318 Views)

I don't have a simple reproduction case.  I haven't cleared compiled cache, but, I did sync an entirely fresh copy from SCC, which I think is equivalent (it has to recompile everything in that case I believe).   The class is entirely too complicated which comes down to it being very early in our understanding of objects and actors, but, at this point it is what it is.

0 Kudos
Message 5 of 6
(1,274 Views)

Actually, between syncing to the latest code (probably not what fixed it) and clearing compiled cache, the problem has gone away!   Something about that darn compiled cache.   I'm thinking maybe an objects member data was misaligned in the code and the compiled cache or something and labview just went spelunking for a name match.   Anyway, thanks for the suggestion!

0 Kudos
Message 6 of 6
(1,265 Views)