Build Labview Application which loads functions dynamically

[Ian_Ren]

I am not sure if this is possible for executables, but it works pretty well in the LabVIEW development mode.

I have a LabVIEW program which calls some functions (sub-functions) dynamically. In the develop mode, the sub-functions are in separate *.llb files. When a subfunction is selected from the menu of the main LabVEIW program, the main application searches a particular location/directory for a particular *.llb file; if the *.llb is found, it loads the vi and runs it, if not, it tells the user that the function is not available. The advantage of doing this is that I can add/remove/modify these sub-functions simply by puting in or taking out the *.llb file from that directory without causing any problem on the main program.

Would it be possible to do the same if I buid an LabVIEW executable application (I mean build/compile the main application first, and then add/remove functions by putting/removing some files in a directory)? If yes, then I can distribute new functions to users without having to re-compile the whole thing.


Thanks.

Ian

[Mache]

Hello Ian

It is possible to mimimick your development environment, in a executable if you use the loader method.

Basically loader is a small Vi which dynamically calls your top level Vi Runs it and exits. You only make an executable of your Loader Vi. The Top level Vi and all the subvis can now be put in a LLB file. Once the Path issues are resolved, The application works fine, By changing any Vi in the LLB, functionality is changed Without having to recompile.

Here is more information on this subject ...

http://zone.ni.com/devzone/conceptd.nsf/webmain/095F19486B828D0B86256C2C0061F782?opendocument

[DFGray]

Your method will work fine in an executable, provided you meet one criterion. Your VIs must be fully compiled with no unresolved links. The run-time engine cannot compile VIs. So, if you change the location of something, even if the runtime engine can find it, it will fail due to not being compiled with the right location.

A good way to avoid this problem is to put all subVIs of your dynamic VIs in the same LLB. I also like to create a VI in the same LLB that is statically called from the main program. Its job is to return the directory by returning its own directory. This way, things can move between development and deployment without breaking the dynamic call, which relies on the directory returned for location information.

[Andrew Madry]

The thing that I once got caught on using this method is that everything works fine using the loader technique (ie dynamically calls VIs using call by reference nodes)when LabVIEW is installed on the machine BUT when the deployment is using only the LabVIEW runtime engine the VIs from vi.lib are not there - unless they by chance happened to built into the main executable. When LabVIEW is on the machine the program dynamically calling a VI can find all the sub-VIs called by the plug-in. Some care has to be taken that paths are set up correctly. Of course you need to provide any of your own sub-VIs that you put in the in the plug-in VI.
If you create a new plug-in VI and you used VIs from the LabVIEW palette that you hadn't used in the original executable when the call by reference node runs it can't find these VIs and flags an error (1026). So you have to make sure that with the plug-in you provide the source code of any sub-VI's it calls. This was made clear to me in another posting - the run-time engine doesn't include all the functions in vi.lib. The down side of this is that the plug-in and the code that needs to come with it can become large. I think I saw a posting where someone said that what they did was copy the whole of vi.lib to each deployment computer. I'm not sure if that is a valid way to do things from a licensing point of view.

[Mache]

Hello Andrew,

When Using LOader method, there are a few things to take care of. It is not so terrible when you know what and why. Consider this If you change your executable, You have to rebuild and then you realize there was a small spelling mistake or a control was not aligned. Doing a double check is sometimes as important as good programming.

1. Path Issues - These you will have whether you build executable or release it as a library. This happens if you use relative path.

2. Use of native labview Vi's in your code - When the code changes, You want to distribute the new LLB. Well Use Save with Options and Choose "Application Distribution" Select "Entire Hierarchy", "Include Vi.lib Files" And "Runtime Menu" and "External Routines" If you want your App protected. Click Remove Diagrams. Again Make sure you don't lose your Original file if you choose this. All this saves the whole App as LLB.

Then your Loader has to call your Main Vi dynamically. How difficult is the path Issue to Call One Main Vi in a Vi Library. There is no Licensing Issue here as LV itself gives you this option.

I have used this method for a couple of 200 Vis or more Applications and constantly updated by changing the llb file without any hassle.

[Ian_Ren]

The loader method is what I need. Thank.

One more question, when building the loader (in fact, any applications), is it possible to automatically create a file structure like the follow

C:\Program Files\My Loader program\Loader.exe
\data\subdirectory1
\data\subdirectory1\file1
\data\subdirectory1\file2
\data\subdirectory1\file3
...
\data\subdirectory2
\data\subdirectory3
...

In the application builder, you can only add "support files" and all the support files are in the "\data" directory, but you cannot add "support directories".

Here is one way I do it, but it is not very smart

1)in the "loader" program, add functions to create the data structure I need and move the files to the right directory from the "/data" directory when loader is run the first time,

2)add all the needed files while building the loader program

3)The first time the loader program runs, it creates the file structure.

Is there a smarter way to create subdirectories under the "data" folder? I mean something like "drag and drop".

Thanks for your help.

Ian

[Mache]

You can very easily create this structure as part of the Application builder. Once you have added all the support files under the "Source Files" Tab, go to "Installer" Tab. Click on "Files" You should see all the files you have added including the Exe.

The exe goes in Install Directory. All other files are in Data directory
Click on each file, go to "Installation destination Subdirectory" and Change the \data to \data\sub1
Or Whatever you want.

When your Program installs the files will be put in the directories you indicated. You may even change the name of Data to something else.

But Mind you the all these subdirectories are relative from the install directory.

The one thing you cannot do Is drop Whole Directories as Support files. But you can include LLB's
So you can include a whole set of Vi's as LLB's

[Ian_Ren]

Mache

Many thanks for your help.

Ian

[michael bsc]

hi
i have cfirst/mydll1.dll mydll2.dll
cfirst/csecond/ mydll11.dll mydll22.dll

what happend is that mydll1 calls the mydll11 in the subdirectory and etc .
i need to build setup application in the source files i can add the files all directory.
i have seen there is custom destinations but it is problem i have 200 dll's
it is difficult for each to do what customn directory
can i add some subtree for the installation ????

[Joe_Guo]

try out the OpenG builder from OpenG.org

-Joe