Getting Libraries in a Large Program Working

[rthorpe]

I've been given a large program by one of my colleagues, more than 600 VIs. I now have the problem of getting it working, that's always tricky in Labview.

The problem is the file paths that Labview searches. Each copy of Labview on a different machine looks in different places for VIs. It's very hard to predict how the process will work.

A person on one machine could successfully open a VI by clicking on it. On a different machine with different search paths it may be impossible to open that VI because the SubVIs can't be found. On another machine the VI may be broken because the search paths are different and find different things. A path could point to an old half finished copy of a piece of code. Or, there may be subtle bugs in functionality caused by loading different versions.

I've experimented with different ways to solve this problem. In this case I asked the person who sent me the software to save it using "Duplicate Hierarchy to Another Location". This mostly worked.

It doesn't completely work though. The problem is an instrument driver and it's associated lvlib file. I want this instrument driver to take it's VIs from the copy on my local hard drive. However, Labview keeps loading some VIs from other locations on remote drives. That happens even though the lvlib file is on my local hard drive.

I've tried the obvious solution. I can remove the remote files from the lvlib and add in the local versions. I can save the lvlib file when that's done. However, when I open it again Labview often ignores this and picks the files from the remote drive.

Does anyone know how to fix this?

Is it possible to prevent Labview from looking for VIs outside a particular directory?

[GerdW]

Hi rthorpe,

I've been given a large program by one of my colleagues, more than 600 VIs.

So you and your colleagues don't use the very same installation routines and folder structures?

You don't use any SCC tool with a consistent folder structure?

You don't use any VIPM packages to distribute code in-house?

I now have the problem of getting it working, that's always tricky in Labview.

Never has been an issue here…

save it using "Duplicate Hierarchy to Another Location". This mostly worked. It doesn't completely work though. The problem is an instrument driver and it's associated lvlib file.

You have the driver stored in a different location than your colleague? Why?

Does anyone know how to fix this?

- Open your program in a bottom-to-top fashion: open a (sub) subVI, fix its dependencies, save. Go one level up, repeat…

- You surely use project files: it will show you any dependencies and mismatches and will also help in resolving them…

[rthorpe]

    So you and your colleagues don't use the very same installation routines and folder structures?

That's right. We have local hard drives and remote drives. Some people use one and some people use the other, some use both. Sometimes a project has a specific installation routine or directory structure, but this one doesn't. The drive mappings aren't guaranteed to be the same either, so drive K: on one computer may be drive J: on another.

    You don't use any SCC tool with a consistent folder structure?

    You don't use any VIPM packages to distribute code in-house?

We haven't used source code control or VIPM on this project. I should add that have no control over decisions on this.

    You have the driver stored in a different location than your colleague? Why?

I didn't have the driver at all until I got the code for this project. It seems that my colleague has half of the driver on his own remote drive, and he's picking up some files from a third colleague's remote drive.

    - Open your program in a bottom-to-top fashion: open a (sub) subVI, fix its dependencies, save. Go one level up, repeat…

That makes sense and that's what I've been doing for regular VIs. The problem is lvlib files. I can go through the Lvlib fixing dependencies. The problem is when I hit a VI that's being picked up from a remote drive it resets all the work that I've done. For all of the sub VIs called by that VI it replaces them with the wrong paths again.

    - You surely use project files: it will show you any dependencies and mismatches and will also help in resolving them…

Nope, there are no project files. I sometimes use those myself but the author of this piece of software didn't do that.

[GerdW]

Hi rthorpe,

• Some people use one and some people use the other, some use both.
• Sometimes a project has a specific installation routine or directory structure, but this one doesn't.
• The drive mappings aren't guaranteed to be the same either, so drive K: on one computer may be drive J: on another.
• We haven't used source code control or VIPM on this project.
• It seems that my colleague has half of the driver on his own remote drive, and he's picking up some files from a third colleague's remote drive.
• Nope, there are no project files.

What kind of "engineering"/"software" company are you working for? 😞

From all those information I just conclude "you're lost"…

You have to go the hard way. Start by introducing project files…

(Well, I would start a discussion with the whole developer group about all those bullet points I took from your message. When all of you have agreed on just one (1) rule for all I would start to code…)

[rthorpe]

I see what you mean. However, it's not that bad. There isn't really a developer group on the project, there's just me.

The project I've inherited was envisaged as a one-person thing. The guy who wrote it originally didn't know that he'd have to pass on the software to anyone else. So, he wrote it with no thought to transferring it between computers.

Now, I'm the only person working on the project. I have to archive the software when I'm finished though, so I'll be more careful. I certainly will introduce project files.

On a more detailed question.... Is there a way of stopping Labview from searching for files in certain places. What I want to do is to be sure that I've "got everything". I can only do that by putting it all on a drive I control and stopping Labview from looking elsewhere on other drives. The problem is, if I wrap it all in a project now, then that project will swallow up the stuff from the other drives.

[GerdW]

Hi rthorpe,

when using a project file you will have the chance to see, where each of the VIs is stored on your drives: you can switch from "virtual" project structure to "explorer-like" file/folder view!

And you can (more) easily exchange VIs as the project management will automatically adapt all references/links to VIs you exchange/move within the project…

The guy who wrote it originally didn't know that he'd have to pass on the software to anyone else. So, he wrote it with no thought to transferring it between computers.

Well, that's no excuse…

(This guy never went on vacation and never was ill? And he never does backup his work on your server or whatever backup media you use?)

[rthorpe]

    when using a project file you will have the chance to see, where each of the VIs is stored on your drives:

    you can switch from "virtual" project structure to "explorer-like" file/folder view!

That's a good idea. I've done that, but from within the Lvlib that causes the problem. Not at the top level.

I've managed to get it so that the Lvlib has all the right paths. Unfortunately, this doesn't help much because it seems that the paths in the VIs over-ride the ones in the Lvlib whenever I open a VI. (It all works until I touch something, then it breaks again).

I've attached three pictures. In the first one (Lvlib_1) I click on the file "Read.vi". I then get the dreaded dialog box shown in Lvlib_2. Then I'm back to square one as shown in Lvlib_3.

Thank you very much for your help so far.

[GerdW · Accepted solution]

Hi rthorpe,

- remove/disable network/remote drives

- "hide" all unneeded/unwanted VIs by ZIPping them

- put only the needed/relevant VIs on your LOCAL drive

- then start to setup your project and fix all dependencies

[rthorpe]

Thank you very much.

Doing that worked.

[billko]

---

@rthorpe wrote:
The project I've inherited was envisaged as a one-person thing. The guy who wrote it originally didn't know that he'd have to pass on the software to anyone else. So, he wrote it with no thought to transferring it between computers.

---

Holy cow.  I hope this person isn't working as an engineer any more, because a lot of engineering hours will be spent on this.

First of all, it's NEVER a "one-person thing".  It would be very wise to remember this.  Secondly, always expect that whatever you are working on will eventually be used somewhere else.  (It's called "code re-use", of course.)  Now you and your company are paying (literally) for one person's shortsightedness.

Make your redesign choices with those two points in mind, and people you have yet to meet will worship the ground you walk on.  Or at least they won't be complaining to your manager.  😉