Dynamically loaded VI's with the Application Builder

[Lee Robertson]

We are working on an instrument control applicaiton created by Application Builder in LV6.1. The dynamic loading works well using the VI Server except that sometimes there is a problem finding the subVI's of a dynamically loaded VI. In most cases this can be "fixed" by mass compiling and making sure the directory structure is the same on all machines where the executable is deployed. However, this does not always work. Now we have now begun including all code not built into the application in a single llb using the save VI with options. This will include even the "system subVI's" such as "Config Data Open Reference.vi". We then have to rename all the llb's in the LV6.1 directory (except for the ones needed by mass
compile) and mass compile our llb so that all VI's are linked internally within the llb. We then have to manually link the subVI's that were required to run the mass compile. Then we restore the LV6.1 llb's. The always generates a llb of VI's that can be dynamically loaded via the VI Server from the executable built using Application Builder. Is there an easier way to force the VI links not to look outside a particular llb??? From time to time while editing VI's in the llb they will become reliked to VI's within the main LV distribution and we have to go through this crazy process all over again. Is there any documentation on how the VI Server locates subVI's when used with a standalone application??

Thanks in advance -- Lee

PS: It is not tractable to list all the possible dynamically loaded VI's in the applicaition builder at build time (the list is huge (several hundred) and seems to change daily). If we can figure out how the VI Server locates the subVI's of dynamicall
y VI's then we can stop using the llb!! (it is now ~60MB).

[mikeporter]

There are a few issues here to address. First, don't have VIs that you build with the same name as ones in LV distribution--ever. That will resolve many of the problems it sound like you are having. The basic rule here is to only use a VI name once--and the ones in the VI.llb directory are already taken.

Next, you can't force LV to open a particular copy of a VI. It will use the first one it finds. For example, if the VI is already open, a new VI opening up will use that one regardless of which one you had installed originally. If the VI isn't already open, LV will look in the last place where you saved it. If it can't find it there it start doing a search of the directories listed in the "VISearchPath" line of the application's *.ini file.

Finally, a way
of reducing the size of the big plugin common library is delete from it any files that already exist in the main part of the application. (This task is easier if you build the main executable such that it has a small *.exe and a seperate library.)

Also it might be helpful if you could breakup the plugins into related families of operations (i.e. acquisition, gui, signal processing, etc).

Finally, you might want to take a monent and ponder whether several hundred plugins are really necessary, or are you writing code that is perhaps a teeny bit over-specialized. It's just that several-hundred seems like an awful lot of unique plugin functions... Don't mean to step on your toes, but it's a question that needs to be asked.

Mike...

[Lee Robertson]

Hello Mike Porter,

Thanks for your response to my question. I see that I rambled on and the actual question got lost. Here is the problem: When we install our LV application built with the Application Builder, the VI Server on the target machine (it does not have LV installed -- uses the Runtime Engine only) sometimes cannot find the subVI's wired into VI's that are called by either an "Invoke Node" or a "Call By Reference Node". If we lump all the code used by the dynamically loaded VI's into a single llb and make sure that all the VI's in the llb are linked only to other VI's in the same llb then all is well. If any of the VI's in the llb contain a link to a VI not in the llb then the dynamically loaded VI that calls that subVI will not execute. As stated in my previous posting, setting this up is very awkward. Is there an esier way?

I should also point out that no VI's have the same name as a VI in the LV6.1 distribution. But, subVI's from the distribution that are called by dynamically loaded VI's in our llb must also be included in the llb or the dynamically loaded VI will not execute on a machine without LV installed. A copy of the subVI from the distribution must be in our llb and all links to it must point to the copy in our llb NOT to the one in the LV distribution or it does not work.

Also, we tend to accumulate so many plugins because this application is used to run equipment at a national user facility. People from the outside routinely bring their own equipment and hook it up to our control sofware in order to integrate it into the experiment. We have a template for controlling a device from our control program which we use to quickly add new components to the software on-the-fly. There is never time to rebuild the application so we just add the new VI's to our llb and go -- the executable does not need to be rebuilt. It works well, but the number of VI's quickly gets out of hand. I try to keep out llb cleaned out but things become too interdependent. The bulk of the code in the llb is stuff from the LV distribution that is used by our VI's and a copy of which must be included in our llb.

I'm rambling again so I'll stop with one last question: Is there any documentation on how the VI server locates a VI when running on the target machine (without LV installed -- only the Runtime Engine and the application we built).

--Lee

[Greg_McKaskle2]

> Thanks for your response to my question. I see that I rambled on and
> the actual question got lost. Here is the problem: When we install
> our LV application built with the Application Builder, the VI Server
> on the target machine (it does not have LV installed -- uses the
> Runtime Engine only) sometimes cannot find the subVI's wired into VI's
> that are called by either an "Invoke Node" or a "Call By Reference
> Node". If we lump all the code used by the dynamically loaded VI's
> into a single llb and make sure that all the VI's in the llb are
> linked only to other VI's in the same llb then all is well. If any of
> the VI's in the llb contain a link to a VI not in the llb then the
> dynamically loaded VI that calls that subVI will
not execute. As
> stated in my previous posting, setting this up is very awkward. Is
> there an esier way?
>


The previous post listed some of this, but both the runtime engine and
the development system work the same way. First they look for the VI
already in memory. Then they look at the place where the caller says it
is located. If you loaded VI A, and it refers to B, then it also has a
relative path to where it thinks LV can find B. Then LV will start
searching using the search path options setting.

It sounds like you should change your options setting to first search
your plugin location, and I'd suggest that your plugin location change
from an LLB to folders. There isn't anything special about LLBs and
searching, they work exactly the same as folders. I think you should
also make sure that you search subFolders and LLBs beneath your plugin
folder. I don't remember whether you add the * or set a checkbox, but
this will tell LV to recursively search beneath p
lugins before going on
to the next place in the search path.

Greg McKaskle

[Andrew Madry]

I've posted this on 21 Oct 02. Doesn't answer question but I thought it might help this discussion:

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?

Andrew Madry (andrew@madry.com.au)

ps Using LV 6.1 Win 98SE

[dynamic]

Andrew,

Just wondering if you ever found a solution to your problem. I believe I am having a similar problem. I'm using labview 7.1 Developer Suite and have a vi that uses a timed loop (which I believe is new to labview 7). When the vi is called dynamically from a loader vi that is running in the runtime environment I get an error similar to the one you referred to:

Missing typedef AlarmRef __NATIONAL_INSTRUMENTS_lvalarm.ctl in VI VI.vi.
Missing typedef timing.ctl in VI VI_3.vi.
Missing subVI loadlvalarms.vi in VI VI_3.vi

If the vi is called dynamically from the loader vi in the development environment it works fine.

Mike