Jump to content

Loading a class on a different machine


Recommended Posts

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

Link to comment

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?

Link to comment

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?

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.