News

Perforce is a Configuration Management tool for software development. Although it can be used to manage large multi-developer projects, the context of this article is to use it as a Source Control system with LabVIEW as a single developer. The Perforce Server also has a web based version. This article describes only the windows server and client installed on the same machine. Please refer to the perforce website at http://www.perforce.com/ for more information on other Perforce installation scenarios.

Licensing and Compatibility
The free version of Perforce provides a 2 user, 5 client workspace license. For additional users and/or workspaces, you must purchase Perforce. The alternatives to Perforce (for LabVIEW 8.2) are: Microsoft Visual SourceSafe, Rational ClearCase, PVCS (Serena) Version Manager, MKS Source Integrity, and CVS with the Push Ok Windows client software.

To get Perforce running on your Windows system, download and install both the "Perforce Server Windows Installer" and the "P4V Installer" (in that order). Install the server with the "Administrator - Typical" radio button checked.

P4V is essentially the client and developer user interface, and although the LabVIEW Project Explorer can virtualize this, it is often necessary to have Perforce open as well since LabVIEW doesn't have all of the features (i.e revert if unchanged). The server runs in the background, and as mentioned above, can be run web based with remote client connections.

Installation and Repository considerations

Although the download will guide you through an installation, Perforce (as of 04/06/07) does NOT provide a standard uninstaller via the Start->Control Panel->Add/Remove Programs panel. A subsequent download and reinstallation of the program will be necessary, and will provide an uninstall radio button option (reminiscent of an old LabVIEW Application Builder "feature" where the user had to re-run the installer to uninstall). My experiences with uninstalling various versions of Perforce is that it has been challenging, nicely put.

A "Repository" is where all checked-in source code modifications will reside. In Perforce parlance, the repository is referred to as the "Depot". In Microsoft Windows, the default location for this file is:

C:\Program Files\Perforce\depot.

*NOTE*: I do meticulous backups, some people do not. Even those who do may miss backing up the repository if they are only backing up their "My Documents" folder ( a common practice). Also, creating a shortcut to the depot in your "My Documents" folder (another common practice) will not achieve a good backup, and will only backup the shortcut file. If you are backup conscious, make SURE you add the entire installed Perorce path to your backups!{mospagebreak}

Configuring LabVIEW to use Perforce

• Start Perforce, it will prompt you to open a connection
• Type in your computer name for "Server"
• Click the "New..." button next to workspace to create a new workspace
• Click "No" when prompted to populate the workspace

Initial Workspace Creation

This step is required each time you want to create a new LabVIEW project under Source Control. LabVIEW needs to open a connection to a LabVIEW project file from the Perforce depot. SInce the depot doesn't contain your new project data yet, you'll need to do an initial checkin of your current code (including a LabVIEW .proj project file).

If you don't have any source code, and are starting a new project, create a new empty LabVIEW project file and save it where you'd like to keep it in your documents for checkin and checkout. I typically use "My Documents\LabVIEW\Customer\Project". Remember, you can have lots of projects and workspaces, so this should be a directory containing a single project or application somewhere in your My Documents, or whatever data directory you choose.

In Perforce switch to the "Workspace" view rather than the "Depot" view. Navigate to your LabVIEW source code files that you want to checkin to this workspace. Select all of the files with Shift+LeftClick, then Right click and choose "Mark for Add". Right click again and choose "Submit".

LabVIEW Source Control Configuration

You now have a Perforce workspace with revision #0 of each file checked in. The convention from here on out, is to add files to the LabVIEW project file. Each time you do this, LabVIEW will automatically prompt you to add the file to Source Code Control. Before you can do this, however, you still need to configure LabVIEW's Source Control. In the LabVIEW "Tools" menu, select Source Control -> Configure Source Control.

Select "Perforce SCM" for the Source Control Provider Name. Click the "Change" button next to Source Control Project to configure the project. Navigate to the LabVIEW .lvproj project file that you wish to bind to.

*NOTE* - you will need to change this for each unique customer or project that you are binding to. Since you can have multiple workspaces and multiple projects, you must make sure this is configured properly for the Perforce workspace that you are bound to.

If you want to use the "Diff" functionality, you will also need to configure the Advanced settings. Click the Advanced button, and select the "Diff" tab. Select "Other Application", and navigate to the LabVIEW executable. This will use LabVIEW to show the differences between different VI revisions, rather than a text based editor.

LabVIEW Project Explorer

The LabVIEW Project Explorer virtualizes some (but not all) of the functionality of Perforce. There are simple Checkin and Checkout icons on the toolbar that are also accessible via the right mouse click. Notice the checkbox next to each file in the project. Also notice that the project itself can be checked out at the very top of the tree.

So what are Versions, Source Control, and Configuration Management?

Let's say you had some LabVIEW code that runs on Pocket PC, but not on PalmOS. Most of the sub VIs run, but some key elements, typically user interface customizations, or in the case of a customer, product configuration tweaks cause defects at many levels in the system.

Many LabVIEW programmers will simply take a shortcut and start saving different names of VIs. Eventually, this becomes a mess. LabVIEW is pretty good about prompting for issues like finding same-named VIs in memory, or even finding things where they weren't expected. Nonetheless, typical users just click through prompts and eventually shoot themselves in the foot by saving things they wish they hadn't, or by not being able to find a specific piece of code.

Versioning, Source Control and Configuration Management aim to resolve these common types of development issues. In larger projects with multiple developers this can become quite complex. Add issues like forking and branching, and re-assigning developers to multiple projects and the scope widens.

The example for this article is to do a simple Revision for one developer. Although Perforce is capable of far more complex operations (like those mentioned above), this example wil use the "Label" feature of Perforce. No forking, No branching, No multiple developers. Simply labeling a collection of source code revisions to create a "Version" (i.e. Product_1.12.34)

• Checkin Your Code

1. In the LabVIEW Project Explorer, right click and checkin your checked-out code
2. You can also chech it in directly in Perforce, but you will need to close and reopen your LabVIEW project

• Label the revision(s) you wish to associate

1. Usually, you'll want to label the latest revision of the files in the collection, but you can specify other revisions.
2. In Perforce, select all of the checked in Files with a Shift+Left Mouse Click
3. Right click all of the selected files and choose "Label"
4. A good Label would be "Customer_Product_MajorVersion.Minor.Micro" (i.e. Tradewerx_Clairvoyance_2.0.15)

You now have the ability to get the revision (In Perforce, not LabVIEW) of all of the files associated with a particular Version (or "Label" in Perforce parlance). Simply right click a file or group of files, and get the revision based on "Label" rather than revision. You shoud probably exit LabVIEW when doing this operation, and you should make sure all code is checked in prior to checking out older revisions.

John Giannangeli is a Founder
and Principal Engineer at Giawerx

As a LabVIEW Systems Integrator, we have clients using versions of LabVIEW from 7.1 through 2009, and everything in between. We often need to replicate our clients scenarios for development purposes, without incurring the expense and complication of extra hardware and licensing. We've come to rely on a Product from Oracle (formerly Sun Microsystems) know as VIrtualBox.

What is VirtualBox?

Quoted from the website at http://virtualbox.org:

VirtualBox is a powerful x86 and AMD64/Intel64 virtualization product for enterprise as well as home use. Not only is VirtualBox an extremely feature rich, high performance product for enterprise customers, it is also the only professional solution that is freely available as Open Source Software under the terms of the GNU General Public License (GPL). See "About VirtualBox" for an introduction.

Essentially, like other virtualization products such as VMWare or Parallels, the user can create multiple virtual machines, and configure the environment of each of those machines uniquely. I generally create a virtual machine for each customer scenario that I need to replicate. For instance, one client had the same basic LabVIEW code that they were selling to end users, and each installation was custom, with slightly different hardware and software implementations.

Why would I want to use VirtualBox?

In this article, we'll discuss the problem of installing multiple versions of LabVIEW on a single physical machine, and how VirtualBox can help you maintain discrete installations of each version of LabVIEW on separate cloned virtual machines. One of the problems we face as a Systems Integrator is maintaining installations with quarterly updates. When National Instruments ships a new quarterly update, those bug fixes and patches need to get installed on your development system. You could just update the current version and leave the others alone, but we got in the habit of completely uninstalling ALL NI software, including TestStand and any add-on tool kits, and reinstalling all of the versions. If you were installing on a laptop and a desktop (which is an acceptable practice according to NI's EULA), this could take an entire day or two. During busy times, this is an unacceptable amount of downtime.

The solution then is to create a virtual machine for each version, and potentially unique variants of that version. In this article, we'll discuss how to:

• Create our 1st virtual machine
• Create an "appliance" out of that machine
• Create additional cloned machines from the appliance

We'll also discuss some of the typical settings, installing Guest Additions, licensing and activation topics, and the benefits and limitations of using virtual machines.

Our 1st Virtual Machine

After you've downloaded and installed VirtualBox from http://virtualbox.org, Locate your Microsoft operating system installation CD or restoration CD.

*NOTE* The scope of this article is limited to Windows operating systems. VirtualBox runs on various platforms, and accommodates various operating systems. Also note that Windows Product Keys come in the flavors of OEM and Retail. A new variant known as ULCPC (Ultra Low Cost PC) has been introduced for netbooks, and we were unable to get that to activate after we swapped the spinning hard drive with a solid state drive. This netbook did not come with a Windows installation CD (since it had no optical drive). It came with a Support DVD which had a ghost image and script to restore the original shipped configuration via an external optical drive. When we attempted to restore that ghost image, the procedure did not work. We opted for retiring another copy of XP and using for this machine, but the implication here is that restore CDs/DVDs provided by an OEM may or may not be a reliable mechanism for installing a version of Windows, and you may just have to purchase a copy. If you do attempt to use the restore CD, you should only attempt to install it on the original, unmodified hardware that it shipped with, unless you want to spend hours of experimentation and troubleshooting.

So let's assume you have a platform running Windows. locate that Windows installation CD and insert it into the drive. Don't install it, and exit any dialogs that prompt you to run it. Now Launch VirtualBox. Click "New" to launch a New Virtual Machine Wizard. Give the Machine a name, and select it's OS and Version.

We won't show all the screenshots here, but the next several dialogs request memory and virtual hard disk sizes. Please note that you probably shouldn't allocate more than 50% of your system's actual RAM to the RAM on the VM. If you plan on running multiple VMs, you'll need to plan accordingly (i.e you are running Windows 7 with 8GB of RAM and want to run 4VMs with 1GB each). The good news is that you can adjust the RAM size later. The bad news is that the disk size is pretty much done during this dialog, and cannot later be changed without reinstallation.

The next several dialogs have to do with the hard disk. For the purpose of this article, please select:

• Create new hard disk
• Dynamically expanding storage
• 20 GB

We found, after some experimentation that the dynamically expanding disk feature takes up the smallest amount of space on your actual disk. An installation of Windows XP Pro SP3 with no other software added on takes up about 1.5GB. This is about as small as we could get it. From there we make appliance clones, and install LabVIEW. We chose 20GB after some experimentation. We found that LabVIEW 2009 and TestStand 4.2 and various other add-on tool kits took up about 10-12GB, so we opted to make our clone appliance size 20GB. If you are using other extensive tool kits such as Motion and Vision, Diadem, Robotics, etc. You will probably want an even larger disk size.

Finish the dialogs, and the VM and disk will be created. We typically like the bridged network adapter mode, so before starting your VM, click the "Network" hyperlink in the right pane, and select "Bridged Adapter" from the drop down menu. Bridged mode will essentially work transparently through the hosts network adapter without creating an additional (NAT) IP address. As you become more advanced with networking configurations, feel free to experiment, but for now this will make mapping drives to other resources on your network a lot easier.

Now, we're finally ready to install Windows. Select the VM you created, and click the start button. The dialog will ask where to boot from. You should already have your Windows installation disk in the optical drive at this point, so go ahead and click next. Complete the Windows installation as you normally would. When you are finished the machine will reboot and boot the VM with the newly installed Windows. At this point, I would recommended configuring several things so they propagate to your appliance that we'll create later:

• Users and Passwords, including login pictures
• Network mapped resources
• Task bar and Start menu customization
• and Most Importantly, Windows Activation!

We'll discuss Activation in a moment, but first let's consider some other important things. We chose not to enable Windows Updates at this time. The VM is essentially an appliance. If you want to turn on updates, feel free. One thing to consider is that the Windows Genuine Advantage software may "decide" at some point that your activation is not genuine. If you never install this or any other updates, you activation should be perpetual. We also chose not to install Antivirus software on the VM, since the host machine generally should protect it. Intrusions and infections are still possible, so you should consider your scenario and configure accordingly.

Now, Activation. You should Activate this installation prior to cloning it. Why? because then all of your clones will already be activated, and you won't have to deal with it. Activation issues can be very frustrating, and if you change enough parameters about the VM, your activation will be considered invalid at boot, and you will need to reactivate.

Creating our 1st appliance 

An appliance is simply a VM that is saved in an interchangeable format that we can the later clone other VMs from. What we want to do in this case is clone several VMs from an appliance, and uses them for various LabVIEW installations. We'll start with the VM we named "Windows XP Pro SP3" and create an appliance. To do this simply select the VM, and from the "File" menu, select "Export Appliance". Follow the dialogs, and select the path where you want to store your appliance. It will export 3 files, so you'll probably want to create a directory somewhere for you appliance(s). Notice that the original VM hard disk has an extension of .vdi, and the appliance has an extension of .vmdk. Additionally, an .ovf and an .mf file are created.

Importing our 1st appliance

Now you have created your 1st appliance. Notice that a new VM was not added to VirtualBox. To add new VMs from the aplliance, we'll select "Import Appliance" from the file menu. The dialog will prompt you to browse to the .ovf file you just created. After you've selected it, please pay close attention to the next dialog. Make sure to give a descriptive name (i.e XP-LabVIEW 7.1.1) and a good hard disk name (i.e. C:\Users\John\.VirtualBox\HardDisks\XP-LabVIEW 7.1.1.vmdk). The names it selects by default are the same names as the appliance, so you should definitely change them!

The  appliance import will take roughly as long as an appliance export. On my Windows 7 machine with a 10KRPM drive, it goes pretty quick, about 10 minutes. This is way faster than installing Windows, so once you have an appliance you can create a clone in about 10 minutes. The 1st clone is about 20 minutes since there are 2 operations, export and import, but subsequent clones are only imports.

You now have a VM named "XP-LabVIEW 7.1.1", and you can create several others named "XP-LabVIEW 8.6.1",  "XP-LabVIEW 2009" etc. You can also create VMs with names of specific configs for a customer like "XP-config01", etc.

Installing Guest Additions

Guest Additions consist of device drivers and system applications that optimize the guest operating system for better performance and usability. Although they could be installed on the appliance earlier in this procedure, and thus propagated to your clones, an upgrade of VirtualBox (say from 3.1.2 to 3.1.4) will prompt you to reinstall the Guest Additions anyway. The most immediately noticeable feature of the Guest Additions is that the VM Window "captures" your mouse cursor, and doesn't allow it to move outside the VM window without using the host escape key combination "Right Ctrl". This is annoying, and Guest Additions is well worth installing for this reason alone, although I'm sure there are plenty of performance and usability enhancements.

Guest Additions comes with the download by default and is easily installed. Once the VM is booted, simply click on the "Devices" menu at the top of the VM window, and select "Install Guest Additions". It will go through a series of dialogs, and install in a couple of minutes. It does require a reboot.

Licensing and Activation

This article by no means offers any advice of circumvention to any of the End User License Agreements you may have entered into. You should consult your EULA for any Microsoft, National Instruments, or VirtualBox software you may have agreed to using. As for Windows Activation. If you activate several VMs on the same hardware that your key belongs to, all should be fine. If, however, you attempt to install on another platform, you will likely face activation issues. This is also true if you attempt to move an already activated appliance from one hardware platform to another. If you do not fully understand how Windows Product Activation works, you should consult this article and this article.

Limitations

Although VirtualBox has worked fairly well in our test of USB and Serial devices, PCI cards such as National Instruments DAQ cards do not work. Apparently this feature has been discussed on the VirtualBox site generically for all PCI cards, not just NI. You can however create a simulated DAQ device in Measurement and Automation Explorer that will be recognized in LabVIEW on the VM. This is a potential work around.

For USB devices, you will likely want to experiment with the USB device filters in the right pane. In this screenshot, I've specifically filtered 3 devices to the XP-LabVIEW 2009 VM.

Finally, if you look in the Control Panel "Add/Remove Programs" area, you'll find that your VMs stay quite clean from all the normal clutter that goes along with constantly updating your development machine, and that each version of LabVIEW is a pristine installation, unencumbered from the other versions. Now, when you get your quarterly update, you can simply reinstall that VM's LabVIEW and add-ons, and leave the older versions as they are.

In summary, Virtualbox is a great tool for virtualizing your various LabVIEW environments. As consultants, we never know which version our client may need to use, so we arrive at their shop with all the versions installed on our laptop, and boot the one we need.

  

Giawerx is proud to announce the initial release of the Mobile Registry VI Library for LabVIEW™. This VI Library extends the already familiar functionality of the registry VIs provided in LabVIEW for the Windows desktop to the PDA platforms, namely Windows Mobile™ and PocketPC™.

Initially, we needed this functionality internally to develop various solutions. We examined several other solutions and implementations, but they all required 3rd party DLLs which also required creating stub DLLs. For a LabVIEW developer who is not proficient in C, this task can be quite daunting. For the LabVIEW developer that is proficient in C, the logistics involved in getting this functionality integrated into one's program could consume a fair amount of time.

For little more than the average cost of a billable hour for a typical LabVIEW Systems Integrator, Giawerx has developed a VI Library that is nearly identical to the form and function of the Registy VIs found in the standard LabVIEW package for the desktop. This means that you get the instant gratification of integrating registry key functionality without the headaches of stub DLLs and deploying 3rd party DLLs. We've written the code utilizing the new inline-C functionality found in LabVIEW 8.5, and make calls to native DLLs on the target, so you can get on with your coding and forget about the details of programming the registry. This product provides a pure LabVIEW abstraction that not only get's you up and running quickly, but also provides a near seamless interchangeability with code targeting the desktop utilizing the desktop registry VIs you're already familiar with.

You can find the downloadable installer in our Shopping cart. The installer places the VIs, documentation, and examples in the appropriate  locations so you can quickly begin using the functionality and refer to the documentation and examples within LabVIEW.

We hope you enjoythe functionality and simplicity the Mobile Registry VI Library provides!