Installing third party drivers not in instr.lib

[aSquared]

Hi, 

(LabVIEW 2013 SP1)

We are using LabVIEW to develop on multiple stations and we use source code control application to control the version and compatibility of the VI's.

We are using many third party (not NI) instruments and we "install" their drivers at - 

C:\Program Files (x86)\National Instruments\LabVIEW 2013\instr.lib

This creates some difficulties since this folder is external with respect to the SCC application so this resource is not version controlled, whether someone downloads a different version or one add/changes another feature.

It will be easier also to copy the development folder from one computer to the other.

1. Is it possible to change the default behavior of LabVIEW Environment to load drivers to the Intrument Drivers palette? 

2. What do you recommend ?

Amitai.

[crossrulz]

There are a few options here for you.

1. Just put the drivers in your project folder and edit them to look at their new location instead of instr.lib.  That should be just a matter of loading them and resolving the conflicts.

2. Use VIPM to make packages of the drivers and then everybody can install the packages.  This way they know what version is getting installed.

[aSquared]

Hi crossrulz

Thank you for your answer.

However, I don't see how any of these options can give me the same functioning as I have now using instr.lib .

For your first suggestion - 

In order to NOT use the Select VI option whenever I want to add one of the driver's VI's to the block diagram, I would still have to create the palettes using the dir.mnu files, I believe this is fairly easy (Tools>>Advanced>>Edit Palette Set), but I will have to do it in every development PC, and for every currenct and future driver. I think there should be something easier.

For your second suggestion - this only helps the version maintenance...

What if one developer would like to add another VI to the driver or to edit one ?

I am using Teststand, so for development I am not using the Project structure. The only project I have is just to compile the UI. I don't have a main VI, and the files (VI's and drivers) are loaded according to the user choice of sequence file.

[Dennis_Knutson]

Or you can add instr.lib to your scc. It's just a folder like any other.

[aSquared]

this I will have to ask the IT department 🙂

[Dennis_Knutson]

You actually have to ask IT for permission? I'm sorry.

[aSquared]

I know I am asking the same question... but I still think there should be an easy solution - 

Is there a way to create an external folder (external from the LabVIEW 20XX folder) that if I put a driver inside (downloaded from NI.com/idnet) , there will be a palette in LabVIEW that will be populated automatically ?

(just like the we use - C:\Program Files (x86)\National Instruments\LabVIEW 2013\instr.lib,

What makes this folder so unique? I can't find it in the LabVIEW.ini file... is it coded into LabVIEW ?)

[Dennis_Knutson]

You can place them anywhere you want and you've already been told what you need to do. If you've spent any time with LabVIEW, you should know that the driver project has the specific paths stored in it as do the mnu files. You have to resolve these conflicts when you open the driver project in a new location. It has nothing to do with the ini file. It has everything to do with how the driver project itself was created.

[aSquared]

Hi Dennis,

I am sorry if I made you angry,

I don't have much experience with the .mnu files and while playing a bit with linking a subpalette to an instrument driver folder outside of the instr.lib (lets say the default -  Agilent 34401) I ran into some unexpected issues, So I thought about asking the forum.

I am trying to learn more about this instr.lib linkage via the Project, the lvlib properties and url's, the search paths, and about the .mnu structure.

Thanks.

[Dennis_Knutson]

I'm not angry at all. There is no easy way to resolve the paths except by resolving the conflicts to point to the new locations because both the project file and the mnu files have stored the path to instr.lib and the subfolders. It's not that difficult, just tedious. The only easy to avoid the tedium is to leave the drivers in the default location.