Problem with conversion of LV 8.2 classes to LV 8.5

[hfettig]

I just switched to LabView 8.5 to take advantage of the new features in the Project Explorer.

Unfortunately the conversion of my project from 8.2 to 8.5 seems to have completely destroyed all of my LVOOP classes in the project.

Everthing was working fine right after I opened the project, however, after saving all the VIs in the project, the next time I opened the project all class files showed up as "(not loaded)".

When I right clicked on them and selected "load" some of them would load, some of them would do nothing, and some of them would crash LabView (The last time you ran LabVIEW, an internal error or crash occurred at TDUtility.cpp, line 1524.).

When I double clicked on the class datat type control in the "not loaded" classes, some of them would search on disk for a file with the name of the control (although I thought the control is embedded in the lvclass file) and others would crash LabView (The last time you ran LabVIEW, an internal error or crash occurred at ctrledit.cpp, line 614.)

And when I try to save my project into a different folder (duplicating everything) I get a requester saying that xxx.lvclass is not a valid LabView file.

Did anyone else run into these problems? Any idea how to fix them?

Any help would be appreciated.

Cheers,

Heiko Fettig

[Aristos Queue]

This is a problem that can affect any library type in LabVIEW, not just .lvclass files.

At a guess, I'd say that you've got cross-linking problems. Suppose the project stores the paths for VI A and VI B. Well, VI A uses VI B as a subVI, so it stores a path to VI B. If the path that VI A stores for VI B is different from the path that the project stores for VI B, there's a potential cross-link problem.

With LV 8.5, we massively improved the ability to detect, untangle and avoid cross-linking. The tools work really really great.... for VIs. When libraries get involved (which means .lvlib, .lvclass, .xctl, and .lvsc) the detection works well, but not so much the untangling. Normally a project loads all the libraries listed (not all the VIs in that library necessarily -- it does for some library types, but not others -- but the library file itself is always loaded). When cross-linking is detected, the project tries not to load the libraries so that the user can manually open the libraries from disk (by using File>>Open) to select the ones that he/she really wants the project to use.

I'll bet that you made a copy of your project to protect your 8.2 source code when you loaded it into 8.5. And I'll bet that one of the VIs (or libraries or the project itself) in the 8.5 source code *somehow* remembers a path over to the 8.2 source code. And that is leading to the cross-link detection. This problem could also be caused if you saved *some* of the VIs in your project but not all of the VIs in your project when you opened in 8.5 -- did you remember to have all the VIs in your project in memory at the same time when you did Save As? If not, some of them may remember the old path.

Back in 8.2, try building a source distribution of your project to create the copy and then open the new source distribution in 8.5.

PS: I presume that the team that made everything work so well for VIs in 8.5 will be returning to further work on libraries in a future LV version, but I have no information about this.

[hfettig]

Thanks for the suggestion but I am happy (?) to report that it is not a cross linking problem.

I did have a few of those in the 8.2 project but after carefully removing all of them I still run into the same problem.

I tried your suggestion of creating a source distribution with the same result.

I also managed to replicate the problem with a project that only contains one of my driver class, which does not make any external calls, i.e. the dependency list is empty. I attached the project to this post.

This is how you can re-create the problem:

• Unzip the file
  
• Open the project file in LabView 8.2.1 -> no problems
  
• Close LV 8.2.1
  
• Open the project file in LabView 8.5 -> no problems
  
• Do a 'Save All (this Project)' -> no problems
  
• Note that you can still see the symbols noting private VIs in the class
  
• Close the project
  
• Re-open the project
  
• Now the class shows up as '(not loaded)'
  

I tried the same thing with 'Mass Compile...' from the project explorer (instead of the 'Save All' step) and once it worked. All other times I ran into the same problem.

However, there is definitely a difference in the 'Mass Compile...' vs. 'Save All' behaviour. 'Mass compile' actually updates the lvclass file to version 8.5 whereas 'save all' leaves the lvclass file identical to version 8.2.1.

I will keep investigating this.

Heiko

[Tomi Maila]

I can confirm that we had also similar problem where a class in a project complained to be "not loaded". When we tried to open the class directly from Windows Explorer, the LabVIEW told the class file to be corrupted. We dealt with the problem by reverting this particular class back to LV 8.2.1 version from our source code control repository and reopened it again in LV 8.5. This seemed to work. We have not yet tested if it actually stayed that way after closing and reopening LabVIEW 8.5.

Tomi

[Jim Kring]

QUOTE(Tomi Maila @ Aug 16 2007, 01:17 PM)

I can confirm that we had also similar problem where a class in a project complained to be "not loaded". When we tried to open the class directly from Windows Explorer, the LabVIEW told the class file to be corrupted. We dealt with the problem by reverting this particular class back to LV 8.2.1 version from our source code control repository and reopened it again in LV 8.5. This seemed to work. We have not yet tested if it actually stayed that way after closing and reopening LabVIEW 8.5.

Tomi

It's a good thing that we all use source code control. SVN>>Revert is just a right-click away

[Clicker]

This could be because you have a VISA control within your class data. I found this to be a problem when converting from 8.2 to 8.5. Please refer to: http://forums.lavag.org/85-LVOOP-Upgrade-Problem-t8795.html

[Aristos Queue]

ARGH! It's the "VISA" datatype in private data control bug!!!

Here's what you have to do... go back to the 8.2 version of your class. Load the class into memory. Open the private data control and resize the VISA control. (You can actually make any edit to the private data control; that one happens to be safe to do without changing your data type at all.) Then you can save the class into 8.5 and it will load correctly.

This is the same bug earlier encountered by another LAVA user.

[hfettig]

Thanks everybody. That trick with the VISA controls took care of all my driver classes.

I had another class in the same project with the same problem. It did have VISA controls in its data type although within typedefed clusters. I tried playing with the VISA controls inside the typedefs but that did not fix the problem. However, when I simply made a size change to the instance of the typedef that contained all the typedefs with VISA controls it worked.

I then investigated whether any typedef within the class datatype would have the same effect but it looks like the fact that it is a typedef has nothing to do with it.

However, it looks like whenever you have any kind of resource control in the data type (whether in a typedef or not), e.g. VISA control, DAQ channel control, DAQmx task control, IVI control, Shared Variable control, you will run into this conversion problem between 8.2.1 and 8.5

Luckily the workaround seems to work in all cases: Change the physical dimensions of the resource control or of the instance of the typedef containing the resource control right after opening the project in 8.5. Then mass compile the project.

Cheers,

Heiko

[Aristos Queue]

This issue has been reported to R&D (4CG9B3J1) for further investigation.