Make it possible to support different IVI versions without uninstall/re-install

[JKneale]

We use the our development and target installation PC's to support both new and legacy projects that were developed under earlier versions of IVI Compliance.  As the only current way to change IVI versions is to uninstall and re-install, we are stuck using the earliest one as a common denominator.   With hundreds of old projects to re-compile, frequent across-the-board updates are not possible.  Newer versions of instrument drivers such as HSDIO are only compatible with later versions of IVI. 

I would like to have a reasonably easy way to switch IVI versions, so we can support both old and new code from our development PCs.  Even a batch file and some registry edit instructions would be better than the way it is now.  However, that would limit its use in a secure environment where the users don't have general admin privileges.

From an NI business perspective, this may be blocking customers from purchasing upgrades or new NI products.

[Lars_L]

Hey JKneale,

When we release a new version of IVI Compliance Package, one of our top concerns is ensuring that the new version is completely backwards-compatible with all previous versions. In development of ICP we never remove any existing functions and thus any built applications using the IVI class drivers should work with new ICP releases. We want customers to have a smooth upgrade process which is why we also have multiple alpha and beta tests that focus specifically on backwards compatibility.

Could you give me some more background on the specific issues that you experience when you install a more recent version of ICP on a machine with old projects? If you could give me an example with the versions of ICP you are using, which IVI class drivers, and which IVI specific drivers, and then I can try and replicate the issue here on my end. Feel free to send any code that would help demonstrate the problem.

Lars L

NI R&D

[JKneale]

We support a number of target platforms that are located in secure areas or overseas.  These cannot easily be updated with each new ICP revision.  We install the latest versions when the target PCs are deployed, and they often remain at this configuration for 5 or more years until the need arises to alter them.  They are used for production testing 24/7, so any changes must be thoroughly tested.  For targets that reside in a secure area, the SW installed on the PCs must first receive approval from security before they can be installed.  Our present environment uses LabWindows/CVI V 8.1.1 and IVI Compliance V 2.5

We have had issues in the past where the version of IVI Compliance on the development PC is a higher version than the target PC.   Specifically this was when deploying software developed on ICP 2.1 on a target that was running 2.0.  The three  instruments for which we had IVI based instrument specific drivers would no longer initialize  – an Agilent 34401 DMM, Tektronix AWG 510/5102, and Agilent 6623 power supply.  No IVI class drivers were used.

One solution recommended by our NI rep was to use a virtual desktop for development in older versions.  Our developers are provided either a PC/laptop configured with an IT department standard load set.  Most do not have admin permissions on their PCs and use of virtual desktops is very restricted.

The specific instance that I’m up against is that I need to talk to a NI PXI-6551 board using HSDIO for a new product.  The latest driver version compatible with ICP 2.5 is HSDIO 1.4.3.  I had to configure another development PC for that version of HSDIO, so I could continue to use my PC with LabView 2011 FPGA

[Lars_L]

Hey JKneale,

Thanks for the background on your applications. Since you are maintaining older deployments with earlier ICP versions that cannot be easily upgraded without dealing with some "red tape", it is quite necessary for you to be aware of both development and deployment ICP versions. Although ICP is very backwards-compatible, it is not forwards-compatble which is why I would expect problems like those you experienced when developing an application with ICP 2.1 and deploying to a machine that only has ICP 2.0 DLLs and supporting files.

The main issue with creating an application that allows switching of IVI versions is that installations are detailed operations where all of the various components are copied and verified. These operations cannot really be simplified without compromising error checking and potentially the stability of your system. If you take a look at other drivers both from NI and other companies, I think you'll be hard-pressed to find similar version changing functionality.

As for a solution to your issue, I have to agree with your NI rep in recommending a virtual machine environment for supporting these older deployment scenarios. This is really the fastest and most dependable method for ensuring that you are developing and deploying with the correct versions of all your drivers and applications. From my experience I recommend VMWare Workstation but if money is an issue (as it often is) then VirtualBox (https://www.virtualbox.org/) is a similar free application that I've used in the past. If your developers are not currently given admin permissions then the installation of virtual machine software will have to be resolved by working with your IT group. Versioning can be very tricky but issues can be avoided if you take sufficient precautions on the front end by saving deployment and development images for future use. Let me know if you have any questions on this that I can help with.

Lars

NI R&D