Labview Project management, libraries and vi's

[eximo]

The issue is that when attempting to manage multiple projects on one machine, the vi's are not calling vi's and libraries from the correct location. I.e. two copies of the library or VI on the same machine, results in undesired crosslinking between the projects.

How do you force Labview to use relative references instead of absolute references?  How do you force labview to ignore vi's with the same name that are in other folders. 

I have read references for the .net issues of using .config files to control the version to use, but how do you use the .config to control the location.

HELP!

[GerdW]

Hi,

Why do you need copies at all?

Code you want to reuse in several projects belong in the user.lib (or in instead.lib). Project-related code belongs in the project folder. No copies, no duplicates, no cross-.dependencies...

[eximo]

We use SVN, and our project management requirements are such that all our files for a project must exist in a single directory tree.  No dice on spreading source code and development libraries all over the filesysystem.  

Our requirements are such that we need to be able to specify exactly which files to use and not allow labview to search willy nilly all over of the file system for whatever file matches the name that it is looking for.

This can be done at the very least for our .net files using a .config, but I don't know the syntax for describing a location in the .config file.  I was hoping somebody could provide an example of how to set up the file.

[billko]

It is not willy-nilly to have all your libraries in the user.lib where they belong.  And if dependencies aren't allowed, then how can you justify using anything from vi.lib?

The whole idea behind having a project is so that LabVIEW won't be looking will-nilly for files, but will know exactly where they are all the time.  The project folder itself should cover the requirement that your project needs to specify exactly which files to use.

It's interesting to note that the very presence of all those copies is what is causing all your cross-linking issues.

[GerdW]

Hi eximo,

I also use SVN - with all my projects and the whole user.lib!

our project management requirements are such that all our files for a project must exist in a single directory tree.

Either adapt your requirements or don't copy VIs from one directory to the next!

[tst]

---

@eximo wrote:

How do you force Labview to use relative references instead of absolute references?

---

LabVIEW already uses relative paths for most VIs. The exceptions are VIs which are saved in logical folders like vi.lib and VIs which are saved on another volume from their caller. If LV is searching for files and having conflicts, the problem is not with that part.

Based on your description I'm guessing that you're not actually creating full copies of your libraries. For example, if you have VI A1 in library A and it calls VI B and then you copy VI A1 somewhere, but you fail to copy VI B as well, then the new copy won't find VI B, because it's not where it's supposed to be. That's the point where LV starts searching for files.

Another problem you might have is exactly that you open VIs which reference mutliple copies and then you get conflicts. For instance, in the previous example, if you open A1 in a project which already has B loaded, then A will now link to that B rather than the original B. If you have multiple such files loaded together, you'll get multiple conflicts.

The main issue people usually have with this sort of thing is that this is meant for reuse code and for that people want to have one canonical copy that you can update and then all the projects get it. It might be possible to do what you want with something like svn:externals, but I don't know the details and I seem to remember people not liking it for something like this.

If you really want all the files to be the project hierarchy, then make sure that each component uses only its own files and doesn't make calls into other random components, so that when you copy it, everything comes along with it. Also, make sure to have proper namespacing (either by using unique names or by using lvlibs).

The other alternative is to use something like VIPM to manage the code that goes into vi.lib or user.lib. If you use the pro version, you can create a VIPC file, which is a file which contains all the packages that go with the project, and save that file near the project. You will still need to apply the file using VIPM.

If you still want to have the code in the project folder, I would suggest you contact Jack Dunaway at Wirebird Labs. I know that he has experience with this type of setup and he might be able to consult you on how to do it properly.

[crossrulz]

---

@GerdW wrote:

Hi eximo,

I also use SVN - with all my projects and the whole user.lib!

our project management requirements are such that all our files for a project must exist in a single directory tree.

Either adapt your requirements or don't copy VIs from one directory to the next!

---

We just put the VIPM packages we use for a project in a special folder in the SVN repository.  That way you still know which version you are using.

And if you do go with the VIPM Pro version and make package configuration files, those would go into your repository instead.