LV2019 removing files from LV2014 instr.lib directory?

[mwatkins]

Anybody seen this: 

 - Installed LabVIEW 2019 alongside existing installations of LV2014 & LV2016

 - Used LV 2019 for a couple days 

 - Went to work on some LV2014 tasks and find that niDMM & niDCPOWER (plus others?) are missing from LV2014 instr.lib??? 

Seems crazy but has anybody else seen that bad behaviour? 

Additional info: Used the Automated Test Suite web installer to get LV2019/TS2019/Instrument Drivers. 

thanks

[Kyle97330]

Well, this is a little bit by design?

The current practice for NI software includes the following:

* Only one version of a given support software can be on the PC at once.

* Installing a newer version uninstalls the old version.

* The version of support software for a given year only supports its own LabVIEW year plus the 3 previous ones.

As such, installing 2019 support software uninstalls your old 2016 support software, including the instr.lib that it installed in 2014, then the 2019 software reinstalled it in the 2016 directory since 2016 support is present in the 2019 software.

Previously I was able to get some software that was out of support to still work (needed DAQmx 2015 and LabVIEW 2015 and 2011 at once) by copying all of the library files from a 2011 installation on a different PC that still had DAQmx from an earlier edition installed over to the directories they should have been in on the PC in question.  However, this was very much not a supported thing and if you do it there's a very good chance it won't work or will cause new and interesting bugs to pop up.

[billko]

I think it's by design.  Since there can only be one version of a particular (low level) NI driver on one machine at a time, and given NI only guarantees driver backwards compatibility for three versions, it's not unreasonable that it would uninstall support for LV 2014.

EDIT: Oops, late to the party as usual...

[Yamaeda]

As mentioned (although not clearly), you can have multiple LV installations, but only 1 NI-DAQ. That support 4 versions, the latest and 3 older ones. 

If you need support for NI-DAQ over more versions it's time to install Virtual computers unless you have spare computers (I guess some would argue that since you update every 3 years this isn't a problem, though most have to support old projects ... Some would also argue you should have 1 VM per LV version anyhow)

/Y

[rolfk]

---

@Yamaeda wrote:

Some would also argue you should have 1 VM per LV version anyhow)

---

Some would argue that you should have one VM per project you are working on, irrespective of LabVIEW versions used. 😀

[mwatkins · Accepted solution]

workaround: 

I copied instr.lib from another machine installation of LV2014. works fine. 

heres the bad behaviour part from NI: 

The automated test suite installer REMOVES installed drivers without warning, rendering my dev machine broken until I fixed it. That to me is bad behaviour. 

for what its worth, I dont use DAQmx. 

so to anybody who is supporting legacy systems, there is hope! backup that instr.lib before you "upgrade" labview. 

[rolfk]

My workaround in the past was to rename any non supported LabVIEW version directory in the Program Files to something like LabVIEW 20xx.hide before starting the installer. That made the directory unfindable for the installer and it left the whole version alone. Afterwards rename it back to its normal name.

This does have the potential that some of the driver software in older LabVIEW versions won't work properly anymore since the updated system drivers may introduce binary incompatible changes that the software in the older versions then won't be compatible with. So beware about that.

In the view of this it is very understandable that NI simply only supports 3 previous versions of LabVIEW and doesn't go and test with earlier versions. And as it is not tested it is safer to attempt to remove earlier software installations than just leaving them on the HD and risk crashing.