Loading a class on a different machine

[John Lokanis]

I am running into a very strange issue.  I have a second dev machine that I want to use.  I took all my code and zipped it up, then copied it to the new machine and unzipped it.

Both machines have the same version of LabVIEW (2013) installed from the same DVDs.

Both machines have the same VI packages installed.

All files are in the same position on the drive on both machines.  (EXACTLY the same).

I *should* be able to open the project on the new machine and get no dirty dots.  I assume it will want to compile all the code once since I have separated source from BD.

Instead, one of the projects opens but want to save 108 VIs because it claims a typedef moved on disk  (it did not).

The other project opens and then as soon as the project window finally appears, LabVIEW crashes.  Every time.

So, I started opening individual classes one by one to see if I could find the issue.  On just the second class I opened, I found that some of the accessor VIs were missing.  They were on the disk and the .lvclass file was identical to the one on my main machine (I double checked) but when it was opened, LabVIEW claimed it had no knowledge of the accessors.  The control was in the class, just not the accessors.  And since that was missing, everywhere this class was used in a property node, it claimed that I had no element by that name to access.

 

I have never seen this before.  I assumed that all the information about what was in a class was in the lvclass file.  And if the files were the same, and the required VIs where still there at the exact same paths, then everything would work.  But it does not.

 

Has anyone run across this before?  Is there a fix?  I am guessing this might be due to class mutation data (a feature I could really do without) but I am not sure.

 

thanks for any tips that lead to a solution...

 

-John

[JackDunaway]

I've run into unexplainable CTD's when using Property Node Accessors and LV2012 and LV2013 -- clearing the Compiled Object Cache usually resolves the issues. Does this help for you?

[John Lokanis]

Nope.  Tried that.  And this is the first time opening the code on the new machine so I started with an empty cache.  But thanks for the suggestion.

Something is amiss.  I wish there was some tool to reset a class and clear away the mutation history so it does not have all that baggage.  I suspect many bugs lurk in there.

 

I have been over the steps I took to move the code to the new machine and I cannot figure out why it should be different.

Same OS

Same version of LabVIEW

Same versions of VI Packages

Same file layout on disk

It seems to me that LabVIEW code is becoming non-transportable as they add more features.  Especially LVOOP features.  I have done this type of move in the past with non-LVOOP code and had no issues.

 

Any other ideas to try?

[John Lokanis]

Ok, I managed to fix this one.  I edited the class icon on the source machine, applied the change to all members of the class, then saved changes.  I then copied the code to the new machine, cleared the object cache again (just to be sure).  Restarted LabVIEW and opened the class.  It now looks correct.  Still no idea why.

But, when I try to close the class or the project, I get a save request for 100's of VIs.  The change description seems to be one of these two reasons:

"The master copy of a Type Definition (or Strict Type Definition) used by this VI was modified."

"The VI's name was changed outside of LabVIEW, or one of its subVIs was found in a different directory."

 

Since the disk layout has not changed, what else could be causing this?  Is this a known bug?