LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Way of working with Git, submodules and VI Search Path

Solved!
Go to solution

Hello,

 

(([TL;DR]: LabVIEW fetches the dependencies from instr.lib instead of the project folder.))

 

Recently I have been trying to improve my way of working with versioning LabVIEW code with Git, and particularly using submodules (instruments drivers/libraries are a project of their own, and included in my main test/project as a submodule).

 

Because of this, I often have each driver in several places on my computer: in the instr.lib folder where I store all the drivers, for development mainly, or when I just want to run a quick debug/test and I'll create a VI that will call various drivers from the instr.lib path.

 

However when I create a bigger project that should be standalone (for example to transfer to colleagues), I will include these drivers/libraries as a submodule. Therefore the driver/library will also be stored in the project folder.

 

The issue now is that LabVIEW, by default, will use the driver stored in instr.lib instead of the one in the project folder. This is am issue, because one might want to have a specific version of the driver for this specific project (for example an older version for compatibility) and not the latest version of instr.lib.

 

I know it's possible to change the VI Search Path in the LV options, but this seems to be global settings, not project-related settings.

 

Is there a way to force LabVIEW to look first in the project folder (or in sub-folders of the project folder) instead of going straight to instr.lib?

0 Kudos
Message 1 of 3
(2,286 Views)
Solution
Accepted by topic author seb_bd

@seb_bd wrote:

Is there a way to force LabVIEW to look first in the project folder (or in sub-folders of the project folder) instead of going straight to instr.lib?


I don't think so.

 

It seems to be a bad idea to have libraries in vi.lib\instr.lib and your project. I'm not surprised it doesn't work, and I doubt there is a way to get it working properly.

 

You might be able to add your project path to the search path, but indeed, that is a global setting, and it's a setting that needs to be set for each project.

 

If you want a vi.lib\instr.lib in your project, I'm afraid you'd have to delete it from the lib.

 

Or rename the project copy and use the copy of course.

Message 2 of 3
(2,220 Views)

Thanks for your answer. I found this tutorial about using submodules with LabVIEW. The use of vi.lib/instr.lib is mentioned as an alternative (with drawbacks compared to submodules, according to the author), but it's not mentioned if he still uses vi.lib/instr.lib in conjunction with submodules integrated in standalone projects.

 

Maybe a good solution is to use another "development" folder (not in vi.lib/instr.lib) for development and maintenance of drivers/libraries. Then, if the library/driver is used as a submodule in a standalone project, LabVIEW should (not sure?) find the library in the project folder, and not in vi.lib / instr.lib. To be tested...

0 Kudos
Message 3 of 3
(2,204 Views)