LabVIEW and side libraries (NI-XNET, NI-VISA, etc.)

[eberaud]

Dear all,

 

My team and I are in the process of migrating our application from LV2011 to LV2015. While in this process, we need to be able to make 2015 builds for testing purposes while continuing to build 2011 releases for our current customers. We have a dedicated build PC and I initially wanted to use to build both versions.

 

The issue is: the version 15.0 of many drivers such as NI-CAN, NI-XNET, NI-VISA doesn't support LV2011. When I installed the version 15.0, the libraries were actually removed from the vi.lib folder of LV2011.

 

The thing is for the LV2015 version, I do want to use the latest libraries (15.0)

 

Before trying to reach a solution, I would like to understand one thing about those libraries: when I install them, they do 2 things:

 

(A) Install the libraries in the vi.lib folder to be used by the development environment (Development PC)

(B) Install some resource files to be used by the run-time engine (Deployment PC, aka customer PC)

 

Here is the question: Can I use a version 14.0 for (A) and 15.0 for (B)? I'd guess not but I like dare asking naive questions, you never know...

 

If I want to be able to keep my ideal scheme (14.0 for LV2011 and 15.0 for LV2015), the 2 solutions I see would be:

 

1) I copy the folder from the vi.lib of another computer which has the 15.0 installed to the LV2015 folder of the build PC which has the 14.0 installed (so I don't install 15.0 per say)

2) OBVIOUSLY I get a second build PC

 

Have you ever had to deal with those issues?

 

Thanks!

 

 

[LogMAN]

We just moved from LV2011 to LV2015 and basically had the same issues even though we don't have a separate build PC. We solved this by using a virtual machine for LV2011 and working with LV2015 on the host. So no need for a second hardware. Maybe that works for you too.

[Rolf Kalbermatter]

Dear all,

 

My team and I are in the process of migrating our application from LV2011 to LV2015. While in this process, we need to be able to make 2015 builds for testing purposes while continuing to build 2011 releases for our current customers. We have a dedicated build PC and I initially wanted to use to build both versions.

 

The issue is: the version 15.0 of many drivers such as NI-CAN, NI-XNET, NI-VISA doesn't support LV2011. When I installed the version 15.0, the libraries were actually removed from the vi.lib folder of LV2011.

 

The thing is for the LV2015 version, I do want to use the latest libraries (15.0)

 

Before trying to reach a solution, I would like to understand one thing about those libraries: when I install them, they do 2 things:

 

(A) Install the libraries in the vi.lib folder to be used by the development environment (Development PC)

(B) Install some resource files to be used by the run-time engine (Deployment PC, aka customer PC)

 

Here is the question: Can I use a version 14.0 for (A) and 15.0 for (B)? I'd guess not but I like dare asking naive questions, you never know...

 

If I want to be able to keep my ideal scheme (14.0 for LV2011 and 15.0 for LV2015), the 2 solutions I see would be:

 

1) I copy the folder from the vi.lib of another computer which has the 15.0 installed to the LV2015 folder of the build PC which has the 14.0 installed (so I don't install 15.0 per say)

2) OBVIOUSLY I get a second build PC

 

Have you ever had to deal with those issues?

 

Thanks!

 

Theoretically, the shared resources would be upwards compatible such that the 2011 VIs "should" be able to work with the 2015 binary resources (shared system libraries and device drivers). Practically anyone who has written such drivers knows that this is VERY difficult to do and absolutely impossible to guarantee without explicitedly testing it all in every detail.

 

Now take into account that many of the NI drivers are for multiple platforms (Windows 32-bit and 64-bit, Mac OS X 32-bit and 64-bit, Linux 32-bit and 64-bit, Pharlap ETS, VxWorks, NI Realtime Linux) and NI does provide usually backwards compatibility for the last 3 LabVIEW versions and you see quickly that adding even one more version to this is definitely going to have a huge extra impact in testing. And everytime there is an incompatibility on any of those combinations someone has to go in and make a fix and then testing again all around. If you don't limit the scope there somehow you end up testing, fixing and testing again for unlimited amount of times and no product is released anymore.

 

I have tried such installations in the past but not for production type development. It was mostly to be able to look at older source code without having to load it into a newer LabVIEW version. Never really executed anything substantial on real hardware. The recommendation about using Virtual Machines is actually the most sensible in this case, aside from having dedicated hardware for each version.

[eberaud]

Thanks, I think you understood my question, but I thought I would post a picture to be a bit more explicit about what I intend to do:

 

 

[Tim_S]

We do the same thing as LogMAN: virtual machines for the older version. Initially the VMs get heavy use, but that tapers off as the older version installations become stable (few, if any, changes or warranty calls) or systems reach end of life. We have systems currently in the field that were built with LabVIEW 7.0, 7.1, 8.0, 8.6, and 2012 (there was much rejoicing when the LabVIEW 4.1 system reached end of life). We are looking to migrate to 2015 after SP1 comes out and will be creating a VM of 2012 when we do so.

[Rolf Kalbermatter]

Thanks, I think you understood my question, but I thought I would post a picture to be a bit more explicit about what I intend to do:

 

I think copying a higher version vi.lib to a lower version device driver installation is almost certainly asking for trouble. While the newer version may use new APIs for enhanced operations, the lower version system driver would not support that. That can cause immediate trouble when loading the VIs as they might attempt to link to non-existing APIs in the old driver, or it may be only later at runtime apparent when certain low level device driver methods are invoked with new extended parameters that it does not support.

 

So personally if you want to do such an installation chances are bigger that it will work if you install the highest level driver package with support for as many LabVIEW versions as possible and leave the vi.lib on the older LabVIEW versions with the highest supported driver version.

 

In your example this would most likely mean to install DAQmx 14.0 etc. on the computer to get it install the daqmx and other drivers into the LabVIEW 2011 installation, then rename the LabVIEW 2011 folder temporarily to something else, so that the DAQmx 15.0 installer won't see it anymore and won't remove the DAQmx support from it. This leaves a pretty big change that it will still work after renaming the LabVIEW 2011 folder back after the new drivers have been installed. But as explained earlier I would not recommend that solution for a production quality build system at all as you may end up with obscure errors that are very hard to debug and a bug report to NI won't help much as you work with an unsupported installation.

[eberaud]

Thank you Rolfk! Seems like our best move is to use either 2 PCs (be it through virtual machines or not). We do have to guarantee the quality as those builds go to customers.