Jump to content

Problems with VIPM and multiple versions of LabVIEW


Recommended Posts

I'm developing in LabVIEW 2010, but need to support some legacy apps in LabVIEW 7.0 (working as fast as I can to "retire" these apps!). I just built a "LabVIEW DownGrade" Virtual Machine running Windows XP with the following versions of LabVIEW installed -- 2010 (which can downgrade to 8.0), 8.0 (which can downgrade to 7.1), 7.1 (which can downgrade to 7.0) and 7.0. [sigh -- I'd hoped to get away with only three versions ...].

 

All versions have VI Server's TCP/IP enabled, all use the default Port 3363.

 

I'm only using VIPM to install the OpenG packages -- I'm not trying to "build my own".

 

I installed the minimum 9.01 RunTime Engine and VIPM 2010.0.1. I then started installing OpenG into LabVIEW 7.0. When I tried to do it "all at once", it wouldn't connect with LabVIEW 7.0, but timed out. If I installed a few packages at a time, it worked, and I eventually got everything installed.

 

I then started with LabVIEW 7.1. I gave it a single package (I think it may have been the Goop Wizard). It ran the "Test" to see if it could connect with LabVIEW 7.1 using TCP/IP (it tried to use Port 3364, but I "corrected" it to 3363). The connection was successful, but when it went to install, VIPM again tried to connect, and this time it timed out!

 

I tried again to install, and it eventually worked. I then gave it 4-5 more packages. It would install some right away, and time-out on others. For example, I just tried to do the block rectangle, html_help, buttons, birds_eye_view, opengoop, and appcontrol -- it did several "timeout" countdowns, and ended with errors on all of these. Just a sec, I'm going to try just nilib_rectangle ... Hmm, first I had to uninstall it (it showed as "missing dependencies"), and when I reinstalled, it wanted ogrsc_dynamicpalette v0.19-1, which caused VIPM to go into "Timeout" mode again. Let me try just installing dynamicpalette ... It seems to open LabVIEW 7.1, extracts a bunch of things, then shows "Connecting to LabVIEW 7.1. Timeout ..." and starts its 2-minute countdown. It ended with "VIPM could not install the package ogrsc_dynamicpalette-0.19-1".

 

I'm going to stop and wait to hear from JKI before proceeding. it appears that (for LabVIEW 7.1) the problem is that at least the package "dynamicpalette" cannot be installed. I just looked back at the installation picture for LabVIEW 7.0, and this package shows as installed.

 

I'm happy to perform any tests that you suggest. Note that the installation sequence on this machine was LabVIEW 7.0, LabVIEW 7.1, LabVIEW 8.0, LabVIEW 2010, LVRTE901min, VIPM-2010.0.1.

 

Bob Schor

Link to comment
Share on other sites

Very strange! I remembered the old Universal Fix for All PC Problems (namely, Reboot the Machine). I didn't even do that -- I reinstalled VIPM 2010 (I chose the "Repair" option, which did an "Uninstall/Reinstall" sequence), and tried again to load DynamicPalette. It worked! I then tried a few more packages -- had some start the "Timeout" clock, but they eventually connected.

 

So I've now managed to install all of the OpenG packages for LabVIEW 7.1. Time to try LabVIEW 8.0. Again, I need to "correct" the TCP/IP port (this time it wants to use 3365 instead of 3363). VIPM successfully connected, now let's see if it loads Goop_Wizard ... Well, with the LabVIEW 8 screen still up, it goes into "Connecting to LabVIEW 8.0. Timeout ..." and starts the Fatal Countdown, ending with "VIPM could not connect to LabVIEW 8.0" (which isn't true -- it had just connected!). I'm going to try the "Reboot" trick ... I didn't actually need to do that -- a simple "Restart" of VIPM and asking it to install Goop Wizard worked this time! Try a few more packages (Rectangle to Error) -- continues to work, even bringing in Dynamic Palettes.

 

Maybe the problem is "Don't try to install packages in more than one LabVIEW version during the same VIPM session". I don't recall having this problem earlier, and if this is a real "restriction", it would be helpful if VIPM itself would guard against it and pop up a dialog box that says "To install packages in a different LabVIEW version, please stop and restart VIPM" to warn the user. [On the other hand, if this is a bug, it would be nice to fix it ...]

 

Bob Schor

Link to comment
Share on other sites

Is there a reason for trying to force port 3363? If you let VIPM pick the ports automatically, do you get better connection results?

 

You should not have to restart the PC or VIPM to install on multiple labview versions. That's defeats the whole point of VIPM really.

 

I'm speculating here, but wondering if there may be a problem when you override the port number in the test window.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

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