VI coming up with wrong library directory - Help!

[bpownall]

I'm pretty much a LabVIEW newbie, so please be gentle...

I've written a VI which moves a sensor in a plane over a sample and takes a measurement at each point.

I want to modify the VI so the sensor can take measurements in multiple planes, at various distances from the sample.

Normally, I'd just do the editing at the PC that is running the system.  However, that PC is used for several other things, and I didn't want to tie it up while I was doing my editing.

I moved the VI to a folder on a network drive, and tried editing the VI on a different, networked, PC.

However, on the network PC, my VI is looking for the sub VIs in the wrong directory.  When I investigated, I discovered that on the networked PC, LabVIEW is looking for library files in C:\temp.  Note that this is _not_ the default location.   (The "Use default" box is unchecked when selecting "Library Directory" under "Paths" in the "Options..." dialog.)  The default location is C:\Program Files\National Instruments\LabVIEW 7.1 on both the network PC and the measurement system PC.  (On the measurement system PC, my VI _does_ use the default directory for library files.)

I've tried Google and searching the discussion board, but haven't come up with any useful hits.

The system administrator is willing to work with me on this problem, but he says he's pretty clueless when it comes to LabVIEW.  (Note that I'm _not_ a system administrator on the networked PC, so I can't make any changes that stick.)

This is a LabVIEW 7.1, Windows XP Pro SP2 system, if that matters.

I'm guessing that some initialization file is messed up, but I have no clue what to do about it.

Any help or suggestions?

Bob Pownall

[JLS]

Hello,

The first question that comes to mind is, where are those subVIs on the new machine?

I think LabVIEW is going to try to load subVIs with the following priority in 7.1:

1. if a subVI with the same name is already in memory, use that version (regardless of disk location)
2. attempt to load from the same relative path as found the last time the top-level VI was opened (relative to the top-level VI)
3. attempt to load from the default location set in tools -> options

Actually, this suggests a solution as well.  If you have a location from which you prefer to have the subVIs on your new machine, just:

0. save your subVIs to that location,
1. open the subVIs from that location,
2. open your top-level VI - it'll reference those subVIs already in memory, and
3. save the top-level VI.

Convenient choices for that location would be either the same level as the top level (probably for simple VIs/apps), OR in a "subVIs" folder (for slightly bigger VIs/apps), or in folders organized by function (probably more meaningful for large projects).  Regardless and owing to item number 2 in the first list above, if you drag the whole folder hierarchy containing all your VIs/subVIs from one machine to the next, you should be able to open any of those VIs without issue - provided the appropriate version of LabVIEW is installed 😉

I hope this helps!

JLS

[bpownall]

Hi JLS,

  Thanks for your response!

  I think I wasn't clear in my initial message.  The sub VIs (and maybe I'm using the wrong term here) that aren't being found and loaded are part of LabVIEW 7.1.  They're not things I wrote.

  The missing sub-VIs are supposed to be loaded from the C:\Program Files\National Instruments\LabVIEW 7.1\vi.lib folder, mostly from the express\express shared and express\express output subfolders, but some from utility\error.llb, utility\file.llb, instr\_visa.llb and \InstrIOAsst\IIOA.llb subfolders as well.

  For example, on the networked PC, LabVIEW is looking for the Simple Error Handler.vi sub-VI in C:\temp\vi.lib\Utility\error.llb\Simple Error Handler.vi instead of in C:\Program Files\National Instruments\LabVIEW 7.1\vi.lib\Utility\error.llb\Simple Error Handler.vi.  (FWIW, C:\temp exists on the networked PC, but not C:\temp\vi.lib.)

  Again, this appears to be due to the fact the LabVIEW Path setting on the networked PC has "Library Directory" set to C:\temp instead of the default of C:\Program Files\National Instruments\LabVIEW 7.1.

  All of the necessary sub-VIs (and again, I may not be using the correct term here) are present on the networked PC, but they are in the standard LabVIEW location and for some reason my VI isn't looking for them there.

  I could try moving all of the necessary sub-VIs to the C:\temp directory but 1) it seems like a cleaner fix would be to figure out _why_ LabVIEW isn't looking in the default location for library files and fix that and 2) if I move the necessary sub-VIs to the C:\temp directory, then modify my VI to do what I want, won't my VI look in the C:\temp directory when I move it back to the measurement PC?  (Since I'm not an a sysadmin on the networked PC, I'm not even sure I _can_ create the subdirectories under C:\temp that would be necessary to make method #2 work.)

Bob Pownall

[mikeporter]

The reason LabVIEW is looking in c:/temp for the subVI is because that directory was the place where the file is located on the original machine. LV always looks in the last known location for subVIs.

Mike...

[bpownall]

Hi Mike,

  Maybe I'm missing something, but I don't see how that can be the case.  The PC I used to develop the VI (i.e. the PC that controls the measurement system) doesn't even _have_ a C:\temp folder, let alone all the subfolders underneath C:\temp.

  The networked PC I'm trying to use to modify the VI has a C:\temp folder, but not any of the LabVIEW-related subfolders

  Again, the VI works fine on the PC I used to develop the VI, but not on the networked PC.

  If the VI is looking in C:\temp for all the sub-VIs, then why do I not get any errors when I try running the VI on the PC I used to develop the VI?  (As noted above, it doesn't have a C:\temp folder.)

  Again, to me it seems like the key is figuring out why LabVIEW and the VI are using the default location of C:\Program Files\National Instruments\LabVIEW 7.1 for the library directory on the development system, but they are using the non-default location of C:\temp as the library directory on the networked PC.

  Am I missing something?  (Quite possibly.  As I said at the start, I'm pretty much a LabVIEW newbie.)

Bob Pownall

[JLS]

Hello,

Is it possible that your or someone else could have saved a copy of that VI under that temp directory?  That would explain why LabVIEW is looking there.  If you know where the VI is in the palette (sounds like it's a LabVIEW native/provided VI) then you should just replace it with the one from the palette and save your top level VI.

If LabVIEW can't find a VI which installs with LabVIEW and the above case isn't the problem, you should try a clean uninstall/reinstall of LabVIEW (actually a repair may suffice) on the failing machine, just to make sure all the pieces are in place.

Best Regards,

JLS

[bpownall]

Thanks for all the responses.

The current situation is: I've found a different networked PC, with a different installation of LabVIEW  7.1, and everything is working fine.  My VI is loading properly.  All the sub-VIs are (apparently ) being found where they should be.  (I should note that LabVIEW on this new networked PC has the library directory set to the default value of C:\Program Files\National Instruments\LabVIEW 7.1.  Remember that the old networked PC, the one I was having problems with, had the library directory set to the non-default value of C:\temp, a Windows folder that didn't even exist on the PC I used to write the VI.)

I'm not sure what the problem is with the first networked PC, but my guess is a corrupt or incorrect installation of LabVIEW.  If I have time, I'llt ry working with the system administrator to fix it.  (Basically, I'm going to see if we can get LabVIEW on the networked PC that is having problems to use the default location for the library directory.)

Again, thanks for the help.

Bob Pownall

[JLS]

Awesome - yeah, porting VIs from machine to machine, especially with the same LabVIEW installation should be seamless as long as everything (custom subVIs etc.) comes along for the ride - the native ones should always be accessible as you experienced on your most recent trial/pc.

If this problem persists or you see it again, get back to us with any new info and we'll see if we can make more progress on it!  I'm guessing a clean installation on the "bad pc" will probably just "magically" make everything ok 🙂

Best Regards,

JLS