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

[tst]

BTW, if this is correct, one way to find out might be putting the exe inside the LabVIEW folder. Presumably if it is in exactly the same place as LabVIEW.exe, it should have the same paths, but that's just a guess.

Another option might be not to load the vi.lib VIs dynamically.

[DFGray]

And to answer your original question, paths in LabVIEW are length limited in two ways.  First, the underlying OS imposes its file system limits.  For WinXP, this is 255 characters.  Vista will add a few more (260?), but not much.  LabVIEW also has an internal limit, but I forget whether it is on each folder or the full path length.  In any case, you will hit the OS limit before you hit the LV limit (this may not be the case under Linux, depending on which file system you choose).  Weird things happen when you go over this limit.  You get errors, but not what you expect.  It has been so long since this happened to me that I cannot remember any more details.  If there is interest, I can try to dig them up.

As you might expect, developers of large applications with complicated file system structures are at high risk to find this problem (that is certainly how it happened to me).  People have successfully deployed applications with tens of thousands of VIs, but you do have to pay attention to path length.

Good luck!

[tst]

Damien, in this case my understanding is that the perceived problem is not with any specific path length, but with the combined length of all the paths used in the VISearchPath key of the ini file.

In any case, as I said, I think that the actual problem in this case is the attempt to call either vi.lib VIs or VIs calling vi.lib VIs from an executable, where the VI doesn't know how to found those VIs, since it doesn't know where <vilib> is.

[batesbc]

Good to know that others have done projects larger than ours, I was a little worried when I got a short stunned silence at an NIWeek '05 session about LabVIEW 8.0, they were talking about the (then-new) Project Explorer.

Does the 255-character limit on individual paths apply to the length of the viSearchPath variable? (When LabVIEW reads the .INI file, is it only retrieving the first 255 chars of that string?)

Message Edited by batesbc on 01-23-2007 08:28 AM

[tst]

OK, I just did a quick test and it seems that this is indeed the case - dynamically calling a VI that points to a vi.lib VI returns an error 1003, but moving the executable to the LabVIEW directory solves this.

So the quick solution to your problem would be to put the exe in the LV directory, but if you already have LV installed, you might as well use it run the application.

The other option is to create distributions of your VIs which will include the vi.lib VIs, either as LLBs or as folder hierarchy. The problem with this is that it is more complicated and that you need to try avoiding creating duplicate hierarchies with the same VIs or (worse) different versions of the same VIs.

[batesbc]

Many thanks, tst. We'd run it under LabVIEW.exe all the time, but eventually it has to run under the Runtime. (hence the Loader.exe mess.)

[rolfk]

---

@batesbc wrote:
Good to know that others have done projects larger than ours, I was a little worried when I got a short stunned silence at an NIWeek '05 session about LabVIEW 8.0, they were talking about the (then-new) Project Explorer.

Does the 255-character limit on individual paths apply to the length of the viSearchPath variable? (When LabVIEW reads the .INI file, is it only retrieving the first 255 chars of that string?)

Message Edited by batesbc on 01-23-2007 08:28 AM

---

LabVIEW paths have only a 255 character limit per path hierarchy level. This is because LabVIEW uses a Pascal String for each level. Another limit a LabVIEW path has is a 32767 path element levels. That means a path can consist at most of 32767 hierarchy levels since the numbers of levels is stored in an int16. As you can see this is very unlikely to be ever a problem. Under Windows the Winapi limit of 260 characters for a complete path (unless you use a special trick wich only works for some APIs that are also available as Unicode variant) is much more likely to cause problems and getting around that limit is a nightmare of its own.

And no! LabVIEW does not read 255 character for the viSearchPath but any and all there are up to 2^31 chars, the theoretical limit for LabVIEW string handles.

Rolf Kalbermatter

Message Edited by rolfk on 01-23-2007 06:39 PM

[batesbc]

Thanks for the info, rolfk. Good to know that's not the problem.

[tst]

Another option for fixing this is copying the entire vi.lib folder into your application folder and this should presumably solve your problems, but I'm not sure if this is legal and you might find out you have problems when calling things like DAQmx.

In general, I still believe the best solution would be either to create a distribution or to place some of the low level VIs into your build and take the memory hit.