LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Intaris

Driver Versioning and multiple parallel driver isntalaltions

Status: New

THIS IS A REPOST FROM THE MAX IDEA EXCHANGE BECAUSE WE DON'T ACTUALLY HAVE A DRIVER IDEA EXCHANGE AND I DONT KNOW IF THE MAX IDEA EXCHANGE IS CORRECT

 

Before I start, I want to make clear that I am fully aware that my suggestion is probably linked to some crazy amount of work....  That being out of the way:

 

I often have to switch between LV Versions and have on more than one occasion run into the rpoblem that different versions of LV work with MUTUALLY EXCLUSIVE sets of drivers.  This means that I cannot (_for example) have LabVIEW 7.1 and 2011 on the same machine if I need to be coding GPIB functionality over VISA because there is no single VISA version which supports both 7.1 and 2011 (image below).

 

 

Of course these days we just fire up a VM with the appropriate drivers but for much hardware (Like PCI or Serial or GPIB) this doesn't work out too well.

 

Why can't we have some version selection ability for hardware drivers.  Why can't I have VISA 4.0 and 5.1.1 installed in parallel and then make a selection of which version to use in my project definition?  I know that ehse drivers probably share some files on the OS level so it clearly won't work for existing driver packages but for future developmend it would be utterly magnificent to be able to define which version of a hardware driver (Or even LV Toolkit like Vision) should be used ina  project.

 

Shane.

9 Comments
SteenSchmidt
Trusted Enthusiast

This would be awesome. But as you say, probably a huge amount of work. Not many hardware drivers work with multiple versions installed in parallel.

 

/Steen

CLA, CTA, CLED & LabVIEW Champion
gsussman
Active Participant

The use of virtual machines have solved this issue for us in all but a couple of cases.

RobStone
Member

It's only another example of use/cost considerations why this hasn't been implemented yet (yes, our "much beloved" Controlling Department should be to blame in this case). With serious planning this should be no problem for newer driver versions (from a true software developers (not LabVIEW) point of view)...

AristosQueue (NI)
NI Employee (retired)

Honestly, given what I suspect would be the cost of implementing this feature, it might be cheaper for NI to buy a second machine for the few developers that have to maintain multiple LV versions.

Intaris
Proven Zealot

It's clearly not a cheap idea to implement but I think it is an architectural choice which is only going to get more imporatnt the more legacy code there is out there.

 

By the way, who do I need to send the specs for my second machine?  Nah, joking aside, even that wouldn't solve the problem.

 

What if a user has LV X running on his lab PC and wants a consultant (me) to implement a new program to take over something but I only have my reuse libraries written in LV X+6.  I now CANNOT run my software on his machine because LV X+6 has NO Common drivers with LV X.  A second PC does not remedy this problem.

 

My main gripe is VISA.  Why is it not possible to have multiple VISA access points into the system?  What is preventing this?  The GPIB Cards or Serial Cards are the same.

Brian_Powell
Active Participant

VISA is a bit of a special case, in that it has a driver API and DLL structure that is defined by a consortium (the IVI Foundation).  Theoretically, the VISA you install for 2011 would work with 7.1, because the underlying C-based VISA API hasn't changed in those intervening years.  (It may have some additions, but is backwards compatible.)  Have you tried this?

 

 

Intaris
Proven Zealot

Yes I have tried.  It's exactly what DIDN'T work.  The comment is also somewhat incompatible with the VISA graphic I posted int he idea which suggests that this won't work.

 

I also thought it should work but for the life of me I could not get it to work.  Moving back to the "old" GPIB functionality worked a charm.

Intaris
Proven Zealot

This situation gets even more crazy when the NI System Configuration is involved.  As we see HERE, this can essentially make the installation of pre-build LabVIEW applications a real nightmare.

Greil
Member

Feature is absolute needed here!

 

The actual Driver 2016 will do an invisible uninstall the LabVIEW 2012 Measurement I/O function pallets -> e.g. all the DAQmx subvis are removed.

 

Easy interface like the Teststand Version Selector:

Device Driver Version Selector.png