Is there a limit on the viSearchPath in LabVIEW.ini?

[batesbc]

Is there a size limit on the viSearchPath in the LabVIEW.ini file? If there is, I'm guessing it's 255. We're having trouble getting an .exe to load quite a few vi's dynamically.  It works fine running from LabVIEW.exe; run from OurApp.exe and we get error 1003's all over despite having c:\Program Files\yadda yadda\vi.lib\* in the search path. I included several subdirs of vi.lib (like platform, utility, etc.) earlier in the path, and the combined length breaks the 255 limit, so I'm hoping that the length is the issue, but I'd like to know what the length is, just to be sure.

[tst]

When loading VIs dynamically, LV does not search for the VI. If it is not in memory or where you said it will be, LV will return error 1003. This is because the search is done only for subVIs, which have their paths stored as a relative path inside the calling VI.

To get the exe to call the VIs, you should include them in the build. You can do this either when you build the executable by adding the top-level VIs as support files or, more easily, by having a VI which will not be called in your top-level VI and let that VI hold all those VIs in it. Since it will not execute, the VIs will only be used when you call them dynamically.

Note that if you're using 8.x you should use a case structure (not the disable structure) with a boolean control wired to it. If you use a constant, LV will ignore the code and the VIs will probably not be included in your executable.

[batesbc]

The VIs that are disappearing are polymorphic VIs (specifically DAQmx stuff), even though the executable has the "disconnect typedefs and remove unused polymorphic VIs" unchecked. We have a Loader.exe, which dynamically calls our DAQmx controller code, which has the DAQmx driver VIs as subVIs. Do subVIs in dynamically called VIs still follow the parent exe's .ini file?

[tst]

As far as I know, if you want to use DaqMX in an executable, you have to install DaqMX on that computer (and yes, that takes a long time and looks like overkill).

[batesbc]

Ah, yes. I'll give that a try. Thanks!

[rolfk]

---

@batesbc wrote:
The VIs that are disappearing are polymorphic VIs (specifically DAQmx stuff), even though the executable has the "disconnect typedefs and remove unused polymorphic VIs" unchecked. We have a Loader.exe, which dynamically calls our DAQmx controller code, which has the DAQmx driver VIs as subVIs. Do subVIs in dynamically called VIs still follow the parent exe's .ini file?

---

tst already told you what is the issue. The reason is that the DAQmx VIs reference DLLs and LabVIEW tries to link to those DLLs but failing to find them it also fails to load the VI in an executable for good reasons. You couldn't do anything with the broken VI anyhow in an exe.

Only the DAQmx installer knows where and how to put all the necessary DLLs and add the correct registry entries for DAQmx to work correctly.

Rolf Kalbermatter

[batesbc]

Ok. DAQmx is installed, using its installer. Same problem.

[batesbc]

I should clarify: *None* of the VIs that do anything are compiled with the executable. We have roughly 3700 of them, the LV 8.x project explorer simply can't handle it. (Incidentally I'm curious what NI thinks constitutes a "large" project...) So we have a tiny Loader.exe that starts, and sits in a 1Hz loop waiting for its global flag to be true. The VIs that do stuff get started via ActiveX calls, and load their subVIs. (They also do dynamic loading of their own, based on the install path of the app.) This all works just fine if we run under LabVIEW.exe. It gets to the point where it's loading DAQmx stuff on the same machine (has LabVIEW and DAQmx installed, but is running from our Loader.exe) and it dies with a 1003 error.

I start LabVIEW, debug the Loader.exe, drill down (using some fun little chicanery to actually *get* to the VI, since it's been dynamically loaded it doesn't show up as a subVI of the main) and find that DAQmx has lost its polymorphic VI connections. These are the same DAQmx files as when we run under LabVIEW.exe. (We haven't copied them anywhere.)

The only difference that stands out is the viSearchPath in the .ini file used. Is there a length constraint on that variable?

[Edit: spelling error]

Message Edited by batesbc on 01-22-2007 01:58 PM

[tst]

I don't know how an executable treats polymorphic VIs which are called dynamically, but your setup sounds a little bit too complicated to me (although I have to admit that 3700 VIs does sound like a very big project).

In any case, based on your description, the best guess I currently have is that the problem is not with the search path (since the DaqMX VIs should know exactly where their stuff is), but maybe with the vi.lib part.

This folder is saved as a logical folder when using the relative path (i.e., it doesn't matter where your VI is, it will always remember that the vi.lib VIs it calls are found in <vilib>/whatever).
Since the EXE does not know where your vi.lib library is, any VI using a vi.lib VI would possibly have some problems. There might be an INI key to set the vi.lib folder to another folder, but I never found it (I wanted to change user.lib to another path).

[batesbc]

Complicated is...certainly accurate. This particular app got its start somewhere around LabVIEW 2 or 3, and it's been upgraded (and added to) for over 10 years. (hence the 3700 VIs...)

There's no key for vi.lib or user.lib listed at http://labview.brianrenken.com/INI/, unfortunately. Oh well. Thanks for the help! I'll keep messing with it, see if I can figure it out.