From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW Development Best Practices Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Managing Multiple LabVIEW Versions (copied from neohio group - jaredforshey)

Someone from the NE Ohio LabVIEW User Group posted a great discussion on managing multiple LabVIEW versions and I thought it was well suited for this group.  Looking forward to the responses and best practices used.

From -jaredforshey on NEOhio UG

I have several versions of LabVIEW installed - from 7.1 through 2009.  Occasionally I run into issues where I discover I'm missing a toolkit for a customer project in 7.1 and the installer doesn't always play nicely with my newer installs.  The most recent involved needing to install Traditional NI-DAQ.  If a customer calls and needs work completed on a 6.0 project (which has happened) I either need to encourage them to upgrade (preferred but not always practical if they happen to own their own dev licenses) or find an old computer or virtual machine to install 6.0.

I'm considering moving to a scenario where I maintain virtual machine images for each old version of LabVIEW that corresponds to customer projects in the field.  Other than Windows licensing - which isn't a huge deal with the appropriate MSDN subscription - I don't see too many drawbacks to this approach.  The biggest tradeoff is probably the overhead from running the virtual machine.

How does everyone else manage multiple versions of LabVIEW?  Anything I've overlooked, especially with LV licensing?

I have several versions of LabVIEW installed - from 7.1 through 2009.  Occasionally I run into issues where I discover I'm missing a toolkit for a customer project in 7.1 and the installer doesn't always play nicely with my newer installs.  The most recent involved needing to install Traditional NI-DAQ.  If a customer calls and needs work completed on a 6.0 project (which has happened) I either need to encourage them to upgrade (preferred but not always practical if they happen to own their own dev licenses) or find an old computer or virtual machine to install 6.0.

I'm considering moving to a scenario where I maintain virtual machine images for each old version of LabVIEW that corresponds to customer projects in the field.  Other than Windows licensing - which isn't a huge deal with the appropriate MSDN subscription - I don't see too many drawbacks to this approach.  The biggest tradeoff is probably the overhead from running the virtual machine.

How does everyone else manage multiple versions of LabVIEW?  Anything I've overlooked, especially with LV licensing?

0 Kudos
Message 1 of 22
(15,605 Views)

I use VirtualBox (http://virtualbox.org). I have a virtual box for LV 7.1, 8.0, 8.2, 8.5, 8.6, and 2009. I keep them all seperate since I have clients that use 3 of these different versions, and I use the rest internally for various projects. Not only does it keep your LabVIEW installs discrete and clean, you can totally trash a virtual box and rebuild it quite easily, or at least more easily than building a real box. Also, when you do get to resintalling LabVIEW, you'll only need to install the version for that virtual box, and not all the versions.

0 Kudos
Message 2 of 22
(4,271 Views)

John,

I'm curious, how well does Virtual Box deal with DAQ hardware; USB or otherwise?

---------------------
Patrick Allen: FunctionalityUnlimited.ca
0 Kudos
Message 3 of 22
(4,271 Views)

It works pretty good with all the USB devices I've tried except one wich was a Kespan USB/RS-232 conveter. It did however work OK on a different USB/RS-232 converter. PCI cards are not supported in VirtualBox, so you'll need to use a USB DAQ. I've also used an RS-232 stepper motor with no problem, so the serial ports seem to work ok too.

I do use a lot of DAQ boards with my clients, but I primarily use VirtualBox to develop on, then when I need to use actual hardware, I'll switch over to a real box. You can use simulated DAQ devices to get you by.

0 Kudos
Message 4 of 22
(4,271 Views)

Virtualization is probably one of the best options unless you need to test hardware on the dev machine that you won't be able to communicate with (ie: PCI DAQ).

Keep in mind that after 8.5, our software ships as a platform.  In other words, the appropriate version of a toolkit is required for the same version of LabVIEW (ie: Report Generation Toolkit 8.6 installs to LabVIEW 8.6, and RepGen Toolkit 2009 installs to LabVIEW 2009).  This makes it easier to have multiple Dev systems coexist on the same machine. but it doesn't solve your problems with drivers.

Other options to consider: multi-boot machines (multiple versions of Windows available to boot into for the most common Dev environment options), or even primary HDD switching. 

Anyone else have thoughts?

Elijah Kerry
NI Director, Software Community
0 Kudos
Message 5 of 22
(4,271 Views)

Hi all,

we use an approach for SW testing that is probably also well suited for develloping and managing multiple LV versions. We have a box with a large data HD and a set of exchangeable boot HDs. This machine can also boot from a CF card into a DOS-based imager (a la Norton Ghost). So we can maintain fully separated Windows versions on different update stages, all of them kept as an image on the data HD. The exchangable HDs are used to rebuild one of those Win versions onto from the apropriate image.

It takes only a few minutes to exchange one HD with the other or two reboots to switch to a different Win version (either between Win versions or between update states). Some of those images have also SW installed, which _could_ be LabVIEW as well.

This keeps the different versions fully separated, makes switching easy and fast and, probalbly most important, keeps the full and direct access to any HW build into your machine.

Greetigs from Germany!

--

LuI

Message 6 of 22
(4,271 Views)

Has anyone experienced XP Mode with Win 7 by any chance, as a virtualization approach to manage several LV versions?

THx

L.

0 Kudos
Message 7 of 22
(4,271 Views)

We use VirtualBox for this purpose (and more) and it's been a great solution in general.  However, we've seen some quirks.

Windows Host - Windows Guest

We have had buffer overflow issues using USB-DAQ devices above about 2k Sa/s.  Typically this isn't a big deal since the VM is not the intended, eventual target.

Mac Host - Windows Guest

We're able to get the USB device detected in the Windows VM, but I think there's a sort of jockying of ownership for the USB port somewhere in the mix of Mac OS on the host, DAQmx as the driver in the Windows VM, and possibly VirtualBox as the resource "pass-through" inbetween.

You'll find more on these topics in the discussion forums - try searching "virtual machine" and/or similar terms:

http://forums.ni.com/t5/forums/searchpage/tab/message?q=virtual+machine

Best,

Jassem

Sixclear

Best,
JLSx
Sixclear
VI High - LabVIEW Programming Video Blog
0 Kudos
Message 8 of 22
(4,271 Views)

I've been using VMware Workstation for 2 years now to maintain separate versions of LabVIEW and other engineering software. I wouldn't personally use XP Mode, VirtualBox or VirtualPC. Virtualization is the whole purpose of VMware, Inc., and I believe they are the industry leader. I also use VMware for virtualization of server processes and it's never let me down.

VMware Workstation does cost $150-$200, but easily pays for itself and is a fundamental tool for my business. If you have a need for multiple versions of LabVIEW, then justifying $200 should be pretty easy. You can try it free for 30 days, or use VMware player which is free for non-commercial use.  I haven't experienced any problems with USB devices, but mostly do cRIO work. I also seamlessly move virtual machines between host OS's and haven't had any issues. I use Windows 7, OS X, Vista and XP as host OS's and haven't had any quirks to deal with.

VirtualBox is probably fine, but I've heard (anecdotally) of too many issues with it to use it for my business. It's probably worth exploring though.

Matt

0 Kudos
Message 9 of 22
(4,271 Views)

Ok Thx Jassem & Matt.

I am assuming that for Virtual Box you need a guest OS disk. While XP Mode has it all built-in (I think). I will  do a little more browsing before picking one for trial.

I used to run LV with VMWare on XP, but it was really getting slugish... (2GB Ram), I have a more powerul machine now, and will give one of these VM a try.

Matt: for your use , is VMWare not too slugish ?

Cheers,

L.

0 Kudos
Message 10 of 22
(4,271 Views)