Problem with VI loader technique

[Andrew Madry]

I thought I'd post a problem I've found with the vi loader technique.

A posting titled "Dynamically loaded VI's with the Application Builder" 4/29/02 by Lee Robertson points to what I believe is the same problem I've found but I don't think was solved by the answers to that posting.

A loader uses VI server to dynamically load into memory all the VI's needed by the application. You then run the Main vi and close the loader vi. The loader method is covered in the book LabVIEW GUI essential Techniques Chapter 8. A Developer Zone article by Labviewguru was also recently issued and I've followed the various positings on the subject before this.

When using a loader there are issues to do with the difference in vi pathnames depending on whether the loader is run from the development environment or an executable. You also have to be careful with pathnames for the loaded files and whether they are in a llb or a directory. The loader program can be set up to deal with this and I believe the problem I describe below is not to do with this. Note also you musn't use any vi names from the LabVIEW distribution in your main application.

I converted an application over to the loader method. A small executable which acts a Splash Screen uses vi server to load in vis from a LLB which is the original application. It all works when the loader vi runs from the development environment. When the loader was built into an executable the main program didn't run (broken run arrow). Message comes up "A subVI, Type definition or external subroutine is missing or inconsistent with the current VI". The problem isn't to do with pathnames. I can create a "dummy" main program with not very much in it which works with the loader built into an executable. After deleting sections of my main program step by step I got down to the the Config File VIs which I used to read data from an ini file into my application. I notice that the Open Config Data vi is mentioned in the posting I noted above. I'm able to get round the problem by explicitly putting each of the conifg file VIs used (from vi.lib) in a directory which I expicitly get the loader to load in. It's interesting I can cause my simple dummy main program to break when being called by the exe loader by simply putting in an open config data vi and close config data vi. Also note I can get my big main program to work with the exe loader by just taking out the config file VI's.

I can see now what the problem the 4/29/02 posting is referring to. They had to build system subVIs into an extra llb. If this is the case it seems to defeat the value of using a loader.

So I'm not sure if this is a particular problem with the Config File VI's. There are some typedefs used in config.llb. There are several VIs marked top level. Maybe these cause a problem? That would have to be a bug. The worry is that it's going to occur with some other vi.lib vi's. I wondered whether or not all the vi.lib vis were built into the Run-time engine. How would one know which ones to add as dynamic vis?

Another thing I noticed with the loader was that I had to make sure I didn't load any vi's from the llb which weren't called by the Main program or any of its subvis. This caused an error.

Any comments appreciated, Andrew Madry (andrew@madry.com.au)

ps Using LV 6.1 Win 98SE

[JeanPierre]

You wrote:"I wondered whether or not all the vi.lib vis were built into the Run-time engine"

NONE of the VIs from vi.lib is included in the Run-Time Engine.

Depending of your needs you may:
1)include all subVIs required by the application in your LLB, including those from vi.lib directory. That is if the application have to run on a machine where LabVIEW is not installed, only RTE. This can be done using "Save with Options..." on all your top level VIs and saving the entire hierarchy including vi.lib VIs in a LLB
2)Change the path option in the build application to set "Library Directory" to the LabVIEW directory. That way, the loader will be able to find vi.lib VIs from the installed LabVIEW.

[Alex]

x@no.email (Jean-Pierre Drolet) wrote in <506500000005000000C3AB0000-
1031838699000@exchange.ni.com>:

>You wrote:"I wondered whether or not all the vi.lib vis were built
>into the Run-time engine"
>
>NONE of the VIs from vi.lib is included in the Run-Time Engine.
>
>Depending of your needs you may:
>1)include all subVIs required by the application in your LLB,
>including those from vi.lib directory. That is if the application have
>to run on a machine where LabVIEW is not installed, only RTE. This can
>be done using "Save with Options..." on all your top level VIs and
>saving the entire hierarchy including vi.lib VIs in a LLB
>2)Change the path option in the build application to set "Library
>Directory" to the LabVIEW directory. That way, the loader will be
able
>to find vi.lib VIs from the installed LabVIEW.
>

and 3) It might be that you need the DLL's that LabVIEW calls in the same
directory as the EXE. Some of these such as lvanlys.dll and lvpng.dll are
required and if absent, give the "not executable" error.

cheers, Alex.

--

Alexander C. Le Dain, PhD
ICON Technologies Pty Ltd
http://www.icon-tech.com.au

******************************************************************
* The LabVIEW FAQ http://www.icon-tech.com.au/thelabviewfaq.html *
******************************************************************

[Andrew Madry]

Thanks for reply.
On 1) This certainly works. However it seems to defeat the purpose of the loader as the llb gets big. It's nice if the llb just has the vis you write and not the vi.lib ones.
2) the problem I described was on a machine with LabVIEW installed. As I understand it the Options->Path-> library directory is a LabVIEW application setting. I had it on the default setting which is the LabVIEW directory. It's not an option one can select from the application builder (or maybe I've missed something here). I found that When the loader is run as a vi from the LabVIEW development environment everything is OK. It obviously knows where to look for the vi.lib files according to the labVIEW library path setting. The confusing thing is that
when the loader is built into an application (exe) it knows where to look for "most" of the vi.lib files but apparently not all. I mentioned the problem with the Configuration File vis. As far as I can tell it was the presence of these vi's that caused the problem in my case. I'm a bit suspicious because they were mentioned in the other posting I referred to.

[JeanPierre]

Andrew,

As you will become familiar with the technique, you will realize that you don't have to distribute the VIs in a single LLB. You can save the VIs in many LLBs or directories. This allows to update only a part of the application. The main point to take care is that all required subVIs will be found by the loader. That is what the Application Builder does: it loads all required VIs in memory and save them in one or two locations. Since the relative paths of the VIs aren't changed when the application is distributed, there is no search problem; all VIs are found where they are expected to be.

The Application Builder does all this saving/relinking for you but if you need the flexibility of the plug-in architecture (loader), you have to do it by yourself.

The following applies to point 2)(vi.lib VIs not included in the distributed LLB):
When the loader is built into an application, by default it expects vi.lib directory to be in the executable directory, where obviously it isn't. Since internally, a VI that calls a subVI from vi.lib stores the location of the subVI relative to vi.lib directory (e.g. \utility\file.llb\...). When the loader loads a VI with a vi.lib directory, the VI is not found unless the "Library Directory" option is changed to point to the actual vi.lib. The "Library Directory" option is an application option, not an Application Builder option. You can set the location of the vi.lib library if you let, in the loader run-time menu, the item Tools/Options. You can set it manually when running the loader (relaunch requird to take effect) to enter the vi.lib path (actually, the parent directory of vi.lib). Alternatively, you can put a line in the application ini file setting the "libdir" value, for example:

libdir=C:\Program Files\National Instruments\LabVIEW 6

When you are set this way you shouldn't have problem with the VIs from vi.lib. At my place, the vi.lib directory is put on a network shared drive and other loader applications run without problem using it remotely, including Config file VIs.

It is a lenghtly explanaition of a convoluted problem, if you need more ligth on some points, just ask.

[Andrew Madry]

Jean-Pierre
Thank you!
I checked the run-time menu of the built loader and saw that the library path was pointing to the directory the application was in. Originally I had disabled the run time menu so didn't think to look there. I reset it as you suggested to the labVIEW directory and all is well.
I have renewed faith in the loader method.

cheers
Andrew

[Intern2005]

Hello,

I would like to know how to get the Vis or SubVIs adapted to the VIS that I got from NI site. Indeed, each time I want to test a VI from the NI site, I download it, and I open it. But then, the application search into the dirctory "vi.lib" the necessary SubVIs or VIs but it always fail becasue I don't have them in my vi.lib directory.
So I choose ignore SubVI but the application requires always the SubVIS needed. If I always push "Ignore SubVIS" or "Ignore controls", I get the apllication but it's impossible to run it since lots of SubVIs are missing...!

For example, I downloaded a VI entitled "PID_Temperature_Control". When I open it, the progam asks the path to get many SubVIs like "FP Open.vi", "FP Create Tag.vi", "FP Close.vi", "FP Read (Polymorphic).vi", "FP Read (Float).vi", "FP Write (Polymorphic).vi", "FP Write (Float).vi", "PID.vi", "PID (DBL).vi".

So do I have basically each time I want to use a Vi for my program to search for any SubVIs on the site or can I rather download directly a full vi library, or a subvi library that can help to provide the SubVis required so as not to waste time by looking for the needed SUbVIs?

Thanks in advance

[becktho]

I once tried the loader technique, due to the big advantage of modularity - and I also discovered this "problem" concerning vi.lib-vis.
Since then I didn't come back to this again, because I think it's very annoying that I have to take care of this vis. Because if I for example add functionality in a llb (e.g. print a report), I always have to be aware to add the necessary vi-lib vis. If I don't remember I may spend hours and hours for error-fixing.

I think it was better, if NI provides a special RTE for loader applications. I don't want to install the LV-Environment just because I use the loader and don't want to take care about vi-lib.

Thomas

[tst]

Your question has no connection to the original thread. You really should start a new thread if you have a new question.
As for your question, the VIs don't work because they require VIs which you don't have to run properly (In your example, FieldPoint Support, which comes with LVRT, and the PID VIs, which come with the control toolkit). These toolkits are extra and need to be purchased. If I am not mistaken, the examples on this site also say which version of LV and which toolkits you need to have installed in order to run the example.
If you want a PID VI, there is supposed to be an example in standard LV. Try Help>>Find Examples.