LabVIEW + Virtual MachineBenefit 1: Isolated OS environments for each project, thus reduced deployment issues.

In my last blog post, I said about a few key benefits of developing LabVIEW in Virtual Machines (VMs) like VirtualBox. Here is some details about first key benefit I realized. VMs provides a workflow for developers to separate the various projects in individual environments which eventually reduce the deployment issues.

Some of the deployment issues which are faced while delivering LabVIEW application to a customer are

Missing or unsupported software tools in the customer(deployment) PCIncompatible or mismatching software installed in deployment PC

Scenario Example: As depicted in above figure, let’s consider that we have three project X,Y,Z which goes to three different customers and consider that each customer has different licenses from NI. Hence their LabVIEW version (2017,2016,2014) gets differed for each different project. All three different relies on a specific version of device driver versions or VIPM packages.

In such scenarios of handling different projects dealing with different version of the software/device-drivers/packages, switching between project developments becomes hectic due to version conflicts between the project. Sometimes we tend to uninstall & reinstall device drivers or packages while developing the respective project. Or, on other hand, we keep developing in the latest version of software and then we try to upgrade or downgrade the software versions in the customer PC during deployment to meet the latest specification of our developed application.

For instance, if we develop LabVIEW with device driver from May-2017, it may not be supported with the Project Z which needs drivers from Aug-2014 and we try to upgrade the Project Z PC with latest May-2017 device drivers..

Issues like these are drastically reduced if we develop in VMs for each different project. With VMs, we start developing in a separate dedicated VM which has the same software environment supported by deployment PC. If the customer PC has only LabVIEW-2014 and Device Drivers from Aug-2014, then developing on a VM with only those customer supported installs helps reducing such risks at deployment.

If we switch to other project Y, we can work on the VM2 with LabVIEW-2016 + Device Drivers from Aug-2016. This change of different software for Project Y in VM2 will not affect the project Z which used device driver from August 2014 on VM3.

Microsoft Excel Scenario Example: Sometimes, we might have started reports generation using Microsoft Excel, but the deployment PC may not have MS-Excel. In such cases, we can intimate customer at the early stage of development to get MS-Excel installed. If customer doesn’t have MS-Excel, we can start generating reports in simple formats like CSV/HTML. Thus LabVIEW development in VM gives us this careful process which makes us to sync with customer.