Data Acquisition Idea Exchange

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

Ability to have multiple and distant Labview development versions installed

Status: New

 

I would like to be able to have multiple and distant Labview development environments installed (e.g. Labview 7, 8.0.1,8.2 and 2010). As I understand it, this is mainly limited by the DAQmx drivers.

 

The problem I run into is that I need to support many applications beyond 5 years. We have some test equipment on our production line that has been running software since the 6.0 days. Management will come along and ask me to add one little feature to the software.

 

As it is now, I have to drag out my old computer with Labview 6.0 installed on it, develop on that, and then go back to my new development in LV 2010. I cannot just upgrade the application to 2010, for several reasons.

  1) I can't have all the versions co-exist on one computer, so It needs to move from one machine to the next, upgrading along the way.

  2) Different versions can change things in dramatic ways and break other pieces of code (e.g. Traditional DAQ vs DAQmx)

  3) Because of #2, I need to do a full revalidation of the code, for what should be a minor change.

 

One thing that the NI architects do not seem to understand is that revalidation is not a trivial activity. This can interrupt the production schedule since I often cannot test on anything but the production equipment. This interruption can take days to weeks, even if no problems are uncovered, and much longer if we find that upgrading caused an issue. If I keep my old development environment, all I need to test is the changes to the code. If I change the compiler, I need to test ALL the code to be sure that the compiler change did not introduce any more bugs.

 

This is especially challenging in tightly controlled environments such as medical device manufacturing, where any change to the process requires a great deal of scrutiny.

 

Please make an effort to consider this in the future. Until then, I will be stuck with 4 computers under my desk all running different versions of Labview.

--

Brian Rose
9 Comments
PaulRijk
Member

Yes !!

Yes !!

I fully agree !!

Please NI, instead of a new version, at first solve this problem !

New versions can wait; this problem can't.

Meanwhile I'm now busy removing all old versions of LV and re-install them to be able to continue my work.....

Regards,

Paul Rijkers

 

NIquist
Trusted Enthusiast

I feel your pain as Im sure many LV coders do.

 

...But at least your feet stay warm!

LabVIEW Pro Dev & Measurement Studio Pro (VS Pro) 2019 - Unfortunately now moving back to C#, .NET, Python due to forced change to subscription model by NI. 8^{
Ray.R
Knight of NI

Yes.

 

Totally agree!!!

 

I rencently felt your pain!  There's nothing worse than not being able to support older DAQmx because there is a newer version of LabVIEW installed on the same PC. 

 

At least, let us be able to install older DAQmx versions so that we can support older VI's.

gsussman
Active Participant

I "did" feel your pain at one time, however due to this very issue we have started using virtual machines for our development and the issue has all but disappeared.

 

Each LV version and set of drivers gets it's own virtual machine and we have been able to keep our development environments relatively pure and trouble free for several years.

My personal preference is VMWare workstation on the PC or VMWare Fusion on the Mac. When installed on a suitably powerful PC I have no issues with either speed or memory.

SnowMule
Active Participant

Yep, virtual machines is the answer to this problem.

 

A little more overhead/disk space required, but in the end it's worth the troubles.

Mister_Rose
Member

I have converted to Vitrual Machines. I'm using a nice MacBook Pro with VMWare to run the older environments, and I have my bootcamp partition with the latest and greatest. The only real problem I have is when I am talking to instruments, I will get errors if I am trying to do too much. Most are USB instruments (or GPIB, which goes through a USB adapter), and I think all the hops from the host to the VM are causing latency problems and the drivers on the Guest machine are timing out.

 

Other than that, it seems to work pretty well.

 

--

Brian Rose
Randall_Dannemann
Member

Virtual machines still don't let old and new executables work on the same machine at the same time unless I'm missing something.

Chris_Garratt_NIUK
NI Employee (retired)

If you run the executables within a virtual machine then you can install the drivers specific to the version of LabVIEW it was built in on that particular VM. Different VM software handle interactions with hardware better than others. It's worth reading a few reviews of VM software before you decide which to go ahead with.

 

I agree that not being able to install multiple versions of the driver on the same machine can be frustrating but I can imagine the effects of having multiple versions of LabVIEW and hardware drivers on one machine could get very messy.

 

Regards,

 

Chris

National Instruments - Tech Support
John_P1
Trusted Enthusiast

*Bump*

 

Could NI just make an installer available that provides DAQmx ADE support for legacy LabVIEW versions?  As far as I know, this is the reason that we can't run legacy versions of LabVIEW with newer DAQmx versions.

 

For example...

 

DAQmx 9.1.1 is the last version that supported LabVIEW 8.2.  Could NI make available an installer that included the DAQmx 9.1.1 LabVIEW VIs and examples compiled for LabVIEW 8.2?

John Passiak