LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW 8.2 classes do not work in LV 8.5?

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
0 Kudos
Message 1 of 5
(3,446 Views)
I have experienced the same issues.  I have also tried the same tactics as you have.  Short of recreating the entire class....I'm not sure what to do.

 
0 Kudos
Message 2 of 5
(3,399 Views)
Well, with some help of the guys at LAVA I found the root cause of the problem and a work around.

It looks like the problem only appears when converting from 8.2.1 to 8.5 and only if there is a 'resource control' in the data type of the class, e.g. VISA control, DAQ channel control, DAQmx task control, etc.

For some reason in this case it seems that the class is updated to 8.5 but the containing data type is not or something along those lines causing the class file to become corrupted.

The workaround is this:
  • Open the project in 8.5
  • Before saving or mass compiling do the following:
    • Open every class data type that contains a resource control and slightly change the physical dimensions of the resource control. You can change it right back as well (although not by using undo 😉
    • If the resource control is contained in a cluster or typedef, you need to only change the dimensions of the cluster or instance of the cluster.
    • This seems to flag the class for proper update.
  • Mass compile the project
  • Close the project
Here are the links to the two LAVA threads I found on this topic:
  • http://forums.lavag.org/85-LVOOP-Upgrade-Problem-t8795.html
  • http://forums.lavag.org/Problem-with-conversion-of-LV-82-classes-to-LV-85-t8847.html
I hope this will be fixed since I don't think I am the only one using resource controls in class data types.

Cheers,
                    Heiko
Message 3 of 5
(3,355 Views)

Hello,

I have an application I wrote in 8.2 (some components saved in 8.2.1), and when I load the project in 8.5, then close it, and select "Save - All", it seems to re-load and run just fine.

Were your original VIs saved in 8.2 or 8.2.1?  Do either of you still have a copy of the VIs / classes / project saved in that version (before saving in 8.5)?  If so, is there any chance you could post them here, along with what exact steps you're taking to get into this situation?  This definitely sounds like a pretty bad problem, any additional information or VIs you can provide would help us determine what might be causing this in your use cases.

Thanks!

Edit: I guess I was too slow, glad you found some information on this.  Given the information you found on LAVA I expect the LVOOP developers already know about the issue, but I'll be sure to pass this thread along just in case.

Message Edited by Jeff B on 08-17-2007 08:33 AM

0 Kudos
Message 4 of 5
(3,352 Views)
Heiko Fettig mentioned the workaround above from the LAVA forum, and just for the records, this was reported to R&D (4CG9B3J1) for further investigation.
0 Kudos
Message 5 of 5
(3,316 Views)