How did your 8.5 upgrade go?

[Jim Kring]

I haven't upgraded any existing projects to 8.5, yet, and I'm wondering how it went for everyone else?

Please post your experiences here and let us all know how it went.

Thanks,

[LAVA 1.0 Content]

I haven't moved any projects specifically, but I tried to enable scripting and now 8.5 won't start and on the splash screen in the lower right, the section that says what's loading states that 'You should never see this message state'

Damn rusty nails

[Jim Kring]

I guess it didn't go so well for Heiko:

http://forums.lavag.org/Problem-with-conve...V-85-t8847.html

[orko]

I'm not using any classes yet (waiting for the next project to delve into that learning curve), but I did have some problems converting my main project over from LV8.2.1 to LV8.5.

After builting a duplicate source distribution in LV8.2 and opening it up in LV8.5, LabVIEW would crash when opening a central VI I had for storing all of my typedef'ed cluster constants (mass compile would also crash LabVIEW). It turned out after isolating the problem (basically taking out typedefs until I could open the VI without crashing) to be two references to waveform charts I had that were also in another typedef cluster. Replacing them with references built inside LV8.5 fixed the issue. The odd thing is that two other typedef'ed waveform chart references that were also in the same cluster constant didn't have this problem.

I'm half tempted to say the bug was in the way that LV8.2.1 created the references, but there's no way to be sure.

[eatherto]

Jim,

We've moved a project from LabVIEW 7.1 Embedded to LabVIEW 8.5 with the Beta version of the Blackfin Toolkit. Everything went fine, there was a lot of array math, along with standard math. The new Embedded toolkit is much more stable than any other version they have released to date.

Thanks,

Eric

[Val Brown]

QUOTE(eatherto @ Aug 16 2007, 10:42 AM)

Jim,

We've moved a project from LabVIEW 7.1 Embedded to LabVIEW 8.5 with the Beta version of the Blackfin Toolkit. Everything went fine, there was a lot of array math, along with standard math. The new Embedded toolkit is much more stable than any other version they have released to date.

Thanks,

Eric

It actually went very well for me and I've already deployed my latest release using 8.5 for the build, including the installer. I had some challenges with the migration but those were semi-intentional as I wanted to see just how robust the Project Explorer's Conflict resolution process was. Migrating toolkits was interesting -- esp DCT -- but that was also because of how I did it (viz brute force copying of the relvant \vi.lib\addons\... folders. This is NOT recommended procedure so the problems that arose were of my own creation. Even the legacy serial i/o functions are working in connection with serpdrv (for those of you who remember that!).

I'm really loving 8.5, esp the extensions to Project Explorer.

[MikaelH]

I can really recommend it.

With one large project with plenty of classes I hade one problems at all.

But with another project I had to do some changes due to Invoke node interface changes. The Invoke node was "App:LVClass.Create" and the Invoke node ProjectItem:AddItem don’t allow an unnamed LVClass type.

//Mikael

[Tomi Maila]

We had some problems although they upgrade process was generally easy. Our projects are all using LVOOP. With one of the classes we had a 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. Another problem we had was that with one particular mail level VI in our project, after running it four times, LabVIEW vanished i.e. crashed adn all windows disappeared immediately without any error messages. First we thought this is purely LV 8.5 related issue as we hadn't encountered it in LV 8.2.1. We tested the VI in 8.2.1 version of the project again and it appears that there occurs and exception in external code we are using. LV 8.2.1 catches the exception and gives an error message. LV 8.5 vanishes.

One bug I've also encountered but I've not yet reported it to NI as I had not had time to test how to reproduce it. When I changed the name of a class type control in a private data cluster of another class, the name change didn't penetrate to member VIs. All bundle and unbundle nodes still appeared as if the name had not been changed. Compiling the project with ctrl + shift + run didn't help (if I recall correctly). So there seems to be some book keeping issues related to class wire item naming in LV 8.5 but this doesn't affect runtime properties.

[Aristos Queue]

QUOTE(Tomi Maila @ Aug 17 2007, 02:48 AM)

One bug I've also encountered but I've not yet reported it to NI as I had not had time to test how to reproduce it. When I changed the name of a class type control in a private data cluster of another class, the name change didn't penetrate to member VIs. All bundle and unbundle nodes still appeared as if the name had not been changed. Compiling the project with ctrl + shift + run didn't help (if I recall correctly). So there seems to be some book keeping issues related to class wire item naming in LV 8.5 but this doesn't affect runtime properties.

Known issue. If you just change the name of an element, the type isn't updated. You need to make a change that changes the type itself. Workaround: Add an element to your cluster, do File>>Apply Changes, then delete the element. This will get the other elements to update to their new names.