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
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.
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.
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.