Recommendations When Using Multiple Versions of LabVIEW and LabVIEW Toolkits

First it is important to consider why a user should update a LabVIEW version. The primary reason is the new features that are constantly being introduced to allow users more flexibility, power, and stability. Since that is the case, why keep an old version of LabVIEW and other software installed if newer versions are an improvement? The answer lies in backwards compatibility with applications already written and distributed to a factory floor or to customers. Often LabVIEW will lose compatibility with versions of various drivers, hardware, toolkits, and modules. For example, LabVIEW 8.20 doesn’t support NI-DAQ 8.1, however LabVIEW 8.0.1 does. Therefore if an application was written and distributed that revolved around an older piece of hardware which isn’t supported after NI-DAQ 8.1, access to LabVIEW 8.0.1 would be required.

A developer faces various challenges when maintaining multiple versions of any development environment and associated driver set because of shared components and resource conflicts. LabVIEW as a programming language and platform faces similar challenges that can be summarized in the following list:

• Cross-linking of VIs
• Loss of code due to saving an older piece of code in a newer version of LabVIEW
• Inability to install toolkits to multiple versions of LabVIEW
• Inability to install multiple versions of drivers on the same computer

Cross-Linking

Cross-linking can be a significant problem for LabVIEW developers. A good definition of a link is required to understand the problems cross-linking can cause. A VI referring to another VI is called a link. For example, a top level VI links to a subVI. Cross-linking really means that a VI other than the one intended by a developer is loaded into memory and being used or edited. Therefore, a developer may think he is editing the desired code when in reality the edits are being made to a completely different VI of the same name in a different location on disk. Cross-linking usually occurs under three different circumstances.

• Cloning (copying) VIs on disk
• Linking to VIs in memory that have the same name as the intended subVI
• An incorrect use of “Save As”

The first item is most pertinent to this discussion. To understand how cloning can be a problem, it is important to understand how LabVIEW searches for subVIs. When loading a top-level VI into memory, LabVIEW will attempt to load all of the called subVIs into memory as well. LabVIEW first looks in memory to see if there are any VIs that have the correct name since only one VI of a given name can be loaded into memory at a time.  If no VI by the desired name is found in memory then LabVIEW will begin scanning the hard drive. LabVIEW first looks in the last known location of the VI relative to the location of the calling VI. Failing there LabVIEW begins looking at the VI Search Path locations specified in the Paths category of the Tools>>Options page. If the correctly named VI is found, but was loaded from an unexpected location on disk, then a dialog box like the following will alert the developer (note this dialog box is used in LabVIEW 8.2.1 and earlier).

Note that the correctly named VI, “Sub.VI”, is being linked to, but it is coming from a different location on disk than expected. These VIs could be totally different or even slightly different versions of code. In either event, the developer is not loading the expected VI.

As an example, consider what happens when a VI named "Sub.VI" is “cloned” or copied. A VI of the same name now resides in multiple places on disk. When Top2.vi is opened it will look for sub.vi in C:\My Project 2 because LabVIEW knows the path of this subVI relative to the calling vi. That is, LabVIEW expects the subVI to be in the same directory as the calling VI. If C:\My Project 2\sub.vi were not in this location, then LabVIEW would look in the last known location. Failing there, LabVIEW would then look in the VI Search Path (which can be set from Tools>>Options>>Paths>>VI Search Path). If the VI isn’t located in any of the search paths, then the user is prompted for its location. LabVIEW will cross-link to any VI it finds or the user specifies.

In LabVIEW 8.5, new dialog boxes provide information about cross-linking and the various options to resolve the conflicts. Information on these features can be found in the LabVIEW Help Documentation (Help>>Search the LabVIEW Help) in the article named Using LabVIEW Projects>>Resolving Project Conflicts.

With this understanding of what linking is and how cross-linking can happen, how does this affect the topic of having multiple versions of LabVIEW installed on the same computer? Often a developer will create a directory for her LabVIEW version X VIs and then copy that directory for her LabVIEW version Y VIs. In this scenario there are now two VIs of the same name on disk that could cause cross-linking. This scenario can also happen if a directory is structure is used to “backup” a project at various points during development.

Code Loss

Another common pitfall when upgrading a version of LabVIEW is loss of code. When older code is opened in a newer version of LabVIEW, it is recompiled. If the programmer accidentally saves this recompiled VI in the new version, that VI is no longer accessible to the original version without using the “Save for Previous” option. For LabVIEW 8.2.1 and older, VIs can only be saved back one version at a time. For example, if a VI was created in LabVIEW 7.1 and then opened in LabVIEW 8.20, upon closing the VI the user would be notified that the VI has unsaved changes. Selecting the “List unsaved changes…” would show the following dialogue box:

Note in the “Change details” section, a notification shows that the VI was converted from LabVIEW 7.1 to 8.2, and that in order to open the VI in an older version you have to use the “Save for Previous Version” option. Using the “Save for Previous Version” option in LabVIEW 8.20 allows a user to save as far back as LabVIEW 8.0. The user would then open the VI in LabVIEW 8.0 and repeat this process. When selecting “Save for Previous Version” option in LabVIEW 8.0, the option to save for LabVIEW 7.1 is available. This process can be tedious and care should be taken to read the “List unsaved changes” dialogue box in order to prevent loss of code.

When using multiple versions of LabVIEW, accidentally saving older code in a newer version can cause significant problems. For example, developers will often create a “library” of VIs that is commonly used throughout many applications. If the developer opens up one of these library VIs and accidentally saves it in a later version of LabVIEW than the version used for development, the VIs are no longer accessible in that older version. As a result, any VI that calls this upgraded library VI from the older version will be broken.

Toolkits

Another challenge to consider is installing a toolkit to multiple versions of LabVIEW. As of LabVIEW 8.2.1, toolkits are designed to function in only one version of LabVIEW at a time. That is, if the Report Generation Toolkit is first installed to LabVIEW 7.1 and then the installer is rerun in an attempt to add this toolkit to LabVIEW 8.2, the following message will appear:

This dialogue box indicates that the toolkit is already installed on the computer, therefore it won’t be reinstalled, even if different location for installation is specified. 

This principle holds for the following toolkits and versions and older:

• Digital Filter Design 8.2
• DSP Test Integration Toolkit for TI DSPs 2.0
• Enterprise Connectivity 3.1
• Execution Trace 1.0
• Express VI Development 1.0f2
• IVI Driver 2.0
• Math Interface 1.0.2
• Modulation 3.0
• Order Analysis 2.1
• PID Control 8.2
• Report Generation for Microsoft Office 1.1.1
• Simulation Interface 3.0.2
• Sound and Vibration 4.0
• Spectral Measurements 2.1
• State Diagram 1.0
• System Identification 3.0
• Test Executive 5.1.1
• LabVIEW VI Analyzer 1.1

Drivers

The last challenge faced when installing multiple versions of LabVIEW revolves around hardware drivers. When a driver is being installed, a user can choose which versions of LabVIEW will use that driver. For example, a user can install DAQmx 8.5 to LabVIEW 8.2, 8.0 and 7.1. The same driver will be used across these three versions of LabVIEW. However, a different version of drivers cannot be used in multiple versions of LabVIEW. That is, it is only possible to have one version of a driver installed on a given computer. For example, it wouldn’t be possible to install DAQmx 8.5 in LabVIEW 8.2 while also having DAQmx 7.4.1 in LabVIEW 7.1.

This challenge most often shows up for developers who have deployed applications spanning multiple versions of LabVIEW and multiple versions of drivers. This begs the question,“why not always use the latest version of the driver?” The answer is found in the growing pains of any software package and associated driver set. With the release of each version of the driver, hardware support may be lost. Always check the readme of a driver to see a list of supported hardware. For example, in the DAQmx 8.5 readme, there is a section titled “Devices No Longer Supported in NI-DAQ 7.x and Later” as well as a section titled “Devices Supported Only in NI-DAQmx” and “Devices Supported in NI-DAQmx and Traditional NI-DAQ (Legacy)”. The readme files can usually be found in the driver directory (such as C:\Program Files\National Instruments\NI-DAQ). They can also be found on the driver download page.

In addition to loss of hardware support, known issues may be introduced in more recent versions of a driver that would prevent upgrade. Known issues can also be found in the readme file. For example, in the DAQmx readme, there is a section called “NI-DAQmx Known Issues”. But one of the main reasons a developer may choose to continue a project in an older version of LabVIEW and older driver version is because the application already works in those versions. Upgrading may introduce an unforeseen consequence. In some cases, the risk outweighs the benefits of the new features introduced in future versions.

So far, we’ve discussed some of the issues a developer can face when using multiple versions of LabVIEW on the same computer. In this section, we’ll explore the solutions to the four issues mentioned above. We’ll look into the strengths and weaknesses of using:

• Source Code Control
• Hard drive replication software
• Virtual Machines
• A different hard drive for each version of LabVIEW
• A different computer for each version of LabVIEW

Source Code Control

Source code control (SCC) offers help with cross-linking and code loss by providing the ability to recover code in a known state. It’s a common practice (although ill advised) for a developer to create a directory for each version of her LabVIEW projects or create a directory for a “stable” version of the developing code. For example, the developer could create directories called “Version1”, “Version2”, and so on where each version represents milestones in development. These kinds of directory structures could easily lead to cross-linking since there is a likely probability that VIs of the same name would exist in different places on disk. The consequences of this circumstance were discussed earlier.

SCC is designed to create backup points of code during development in order to prevent code loss and allow developers to revert to pervious states of the code. With SCC there is no need to have version directories containing VIs of the same name on the same computer. Not having VIs of the same name in different locations prevents cross-linking. As of LabVIEW 8.0, SCC can be directly integrated into the LabVIEW development environment. For more information, see the article Using Source Code Control with LabVIEW and Perforce.

As of LabVIEW 8.2.1, there are three ways to diagnose cross-linking (LabVIEW 8.5 introduces new dialog boxes that provide information about cross-linking and the various options to resolve the conflicts; information on these features can be found in the LabVIEW Help Documentation (Help>>Search the LabVIEW Help) in the article named Using LabVIEW Projects>>Resolving Project Conflicts). The first way to diagnose cross-linking is to open up each individual VI and look at the VI properties (File>>VI Properties or Ctrl + I). Then select the “General” category and note the location of the VI. The second way is to use the project explorer. Right click on the project item within the project explorer and select View>>Full Paths. Note that the path of every VI in the project is displayed in parenthesis next to the VI. The third method of diagnosis is to load the top level VI into memory and then to use VI Server to programmatically return the path of each VI loaded into memory in an array of paths. Each path could then be examined to verify it is loaded from the correct location on disk. A program to look at the paths of all VIs loaded into memory might look like the following:

If cross-linking does happen it can be fixed by opening the subVI of interest and then loading the calling VI. Since cross-linking can occur as the result of having incorrect VIs loaded into memory, the solution is to open the correct subVI before loading the calling VI. Again, a warning dialog box will appear indicating that the expected VI (which was cross-linked) was loaded from a different location on disk (the correct location specified when you opened the desired VI manually).

SCC also will prevent loss of code due to saving an older piece of code in a newer version of LabVIEW by keeping the original code. If a VI needs to be accessible in different versions of LabVIEW, consider making copy of that VI with the Save As option. When using the Save As function in 8.0 and later be sure to use the Create Unopened Disk Copy. Using this option will create a copy of the VI at the location you specify without loading the copy in memory. Since the copy won’t be loaded in memory, no cross-linking can occur. Then open the new copy in the newer version of LabVIEW and save it. Alternately, use the Save for Previous option to revert code developed in a newer version of LabVIEW to an older version. Be aware that features available in newer versions of LabVIEW won’t transfer to older versions using the Save for Previous method.

A good programming practice when developing VIs for use across multiple versions of LabVIEW is to always develop in the earliest version of LabVIEW installed and then migrate the VIs to more recent versions. This practice helps to ensure cross version compatibility.  Developing in a newer version of LabVIEW and then trying to migrate to an older version may cause conflicts as new functionality exists in younger versions that my not be available in older versions.

If multiple VIs need to be copied and saved for use in a newer version of LabVIEW, consider using the LabVIEW Libraries (.lvlib). Using the Save As function on a library will copy the contents of the library to a new location without linking the newly copied contents to any other VIs. Open the newly copied library in the newer version of LabVIEW and save it.

There are many advantages to using LabVIEW libraries and more information can be found in the article titled Sharing Code with the LabVIEW Project Library.

Although SCC has benefits in addition to what’s already been discussed, it doesn’t allow a toolkit to be installed to multiple versions of LabVIEW nor does it facilitate using multiple versions of a driver on the same computer.

Hard Drive Replication \ Backup Software

A class of software exists that allows a user to create a “snap shot” of a hard drive or partition and copy that snap shot to other hard drives or even the original hard drive itself. The purpose of this class of software is to create backups or restore points of entire systems or partitions including the operating system, programs and user files. The snap shot is referred to as an “image.”

This class of software can be used to help solve various challenges when installing multiple versions of LabVIEW by creating an image for each version of LabVIEW to be used. By creating a separate image for each version of LabVIEW, a developer can also install a toolkit for each image, effectively installing the same toolkit for multiple versions of LabVIEW. The same principle holds true for drivers. A different driver can be installed for each version of LabVIEW and in fact a separate image could be made keeping the version of LabVIEW constant and varying the driver versions.

A limitation of imaging software is that only one image containing an operating system can be deployed to a hard dive at a time. For example, if a computer had three partitions C, D, and E, it would not be possible to deploy an image that contained an operating system to both the C and D drives. Doing so would, in effect, install two operating systems.

The recommended implementation of this solution is to use an SCC server to store all development files and then synchronize the imaged computer with the files in the SCC server. For example, a SCC computer might have a LabVIEW 7.1, 8.0, and 8.2.1 branch set up. A computer would then be “imaged” with the LabVIEW 8.0 image, and synchronized with the LabVIEW 8.0 branch of code stored on the SCC computer. In effect, the SCC computer acts as a server for the source files under development.

A very popular software package for creating images of a hard drive is Norton Ghost and is widely used by National Instruments for various tasks.

It should be noted that although creating multiple images for various pieces of software solves the problem of installing multiple versions of drivers and toolkits to the same computer, it does not necessarily aid in preventing cross-linking issues or loss of code due to upgrading a version of LabVIEW. Using both SCC and imaging software constitute a powerful solution to the four problems addressed by this paper.

There are, however, two distinct disadvantages to using imaging software with SCC. First, the time to switch from image to image can be lengthy. The process will vary depending on how large the images are, but a 3 GB image can take approximately 20 minutes to deploy. Also, all personalized settings for all software (such as preferences and options) will have to be stored in the image, else each time the image is deployed the preferences will have to be reset. Second, creating an image can also be somewhat time consuming. A 3GB image can take approximately 30 minutes to create.

Please see the National Instruments Software License Agreement  for details relating to licensing. This information can be found in Section 2, Paragraph A of the license.

Given the advantages and disadvantages, imaging software and SCC is a good solution for those whose programs are both hardware and software intensive.

Virtualization

Another class of software exists that allows one computer to run multiple instances of operating systems on the same computer at the same time. That is, its possible using virtual machine software to have two instances of Windows XP or two instances Windows XP and one instance Windows 98 open simultaneously. The number of simultaneously running operating systems is limited by the specifications of the computer such as hard drive space and RAM. Each virtual machine operates independently from the others and, in fact, is unaware that others are running at the same time.

Products such as VMWare and Microsoft’s VirtualPC are currently available. National Instruments has used VMWare to accomplish various tasks.

Different versions of National Instruments products can be installed in each virtual machine allowing simultaneous development of software in different versions of LabVIEW. Each version of LabVIEW can have its own toolkit, effectively solving one of the problems of interest. Please see the National Instruments Software License Agreement for details relating to licensing. This information can be found in Section 2, Paragraph A of the license.

A significant advantage to virtual machine software is a virtual machine can be created in a short period of time. Also switching from virtual machine to virtual machine is as easy as selecting opened windows from a desktop. Each virtual machine exists in a window, as though it were another program running on a computer. The ease with which a developer can switch from virtual machine to virtual machine is a distinct advantage over the imaging software.

Virtual machines can only interface with a very limited set of hardware such as network interface cards, hard drives, and video adapters. Other hardware attached to the computer won’t be recognized by the virtual machines. This limitation poses a significant problem for developers who want to program a hardware application such as DAQ since DAQ applications require that the operating system recognize and allow access to PCI or PCIe boards. USB hardware devices such as cDAQ also aren’t supported by virtual machine software. As operating systems and computer components continue to advance, this hardware limitation will be addressed. Currently there is an effort to implement I\O Virtualization which may solve the problems faced by virtual machine software, but the current limitation makes virtual machines a good solution for developers who concentrate on software applications.

The suggested implementation of this solution is an SCC server with an instance of the SCC client installed to each virtual machine. Using SCC will help prevent cross-linking and loss of code due to upgrading versions of LabVIEW. Virtual machine software will allow the same toolkit to be installed to multiple versions of LabVIEW, where each version of LabVIEW exists in a separate virtual machine. I\O Virtualization promises the ability to control PCI, PCIe and USB hardware in the future, but currently no NI hardware is compatible with virtual machines.

Multiple Hard Drives

So far all of the solutions mentioned have been purely at the software level, meaning that no additional hardware was necessary to implement solutions. The main advantage to using a software-only system is monetary cost. Typically software packages such as imaging software and virtual machine software are relatively inexpensive by comparison to hardware costs. The final two solutions will involve using hardware as the means to install multiple versions of LabVIEW. Hardware provides a more robust solution but is usually more costly in terms of time and effort.

The first of the two solutions is to use a separate, bootable hard drive for each version of LabVIEW. A bootable hard drive is one that has an operating system installed on it and acts as the primary hard drive of a computer. To switch from LabVIEW version to LabVIEW version involves physically disassembling part of the computer to remove the primary hard drive and replace it with another. This method is the hardware equivalent of the imaging software solution where a program such as Norton Ghost is used to create a “snap shot” of a hard dive for backup and restore purposes.

In this solution, an operating system and a version of NI software are installed to a hard drive. A SCC server should be used to access source files under development, thus preventing significant data loss. Using separate hard drives also would aid in preventing cross-linking. As mentioned in the SCC section, cross-linking can occur if a separate directory of sources files is maintained for each version of LabVIEW. With separate hard drives, commonly named VIs would be less likely cross-linked since there would only be one VI of a given name on the hard drive.

Using one hard drive per version of LabVIEW also facilitates installing toolkits to multiple versions of LabVIEW. The toolkit would be installed on each hard drive and therefore make it accessible to every version of LabVIEW. The same holds true for drivers. With multiple hard drives it becomes possible to develop code with different versions of drivers under the same version of LabVIEW. This solution also doesn’t suffer from the inherent driver problem of virtual machines because the hardware is accessible by the operating system on each hard drive.

The time and effort to create and exchange hard drives can be high, potentially making this an unattractive solution. Also, only one version of LabVIEW is accessible at any give time by contrast to using virtual machines where many versions of LabVIEW are accessible simultaneously. Although cost for hard drives is a factor, it is minimized by the price per GB. When this paper was being authored, a 320 GB SATA hard drive could be purchased for $90, making the price of memory $0.28/GB.

Multiple Computers

The most robust and most costly solution of all those presented is to have a complete computer for each version of LabVIEW. At first this option seems to be impractical because of cost, however, the cost of computers has significantly decreased. A good computer (no monitor or peripherals) can be purchased for $500-$700. Using technologies such as Window’s Remote Desktop or a KVM (Keyboard Video Mouse) switch allows one user to access many computers which have no peripherals attached, reducing the overall cost per computer.

In this solution, each computer would have a different version of LabVIEW, toolkit, or driver installed to it. An SCC server would be used to deploy and synchronize source files to the various computers which would help in preventing data loss. The risk of cross-linking is also greatly reduced since two VIs of the same name would probably not appear on the same hard drive. Having a computer per copy of LabVIEW would also allow the installation of the same toolkit to multiple versions of LabVIEW. Lastly, a different version of a driver can be used on each computer making this solution complete in overcoming the four challenges mentioned in this paper.

The advantages to using one computer per version of LabVIEW are instantaneous access to all versions of LabVIEW allowing simultaneous development, and it solves all of the challenges mentioned in this paper. The disadvantage of this solution is the additional cost per computer for hardware.

National Instruments recommends using imaging software with a SCC server. This option solves each of the challenges mentioned at a low cost in time and money. As mentioned above, the primary disadvantages are the time to create and deploy the images as well as an inability to simultaneously develop code in multiple versions of LabVIEW. The solutions are compared in the following chart.