PlugIn architecture and deployment

[falkpl]

I have developed a DAQ application where the raw data is collected and processed in one of meny (some unspecified as of yet) methods.  I have implemented it with a plug-in architecture as follows the raw data as passed to a subvi which is called dynamically.  All sub vis are stored in a foledr called "Plug-ins" and the application will scan this folder for subvi and populate a list for the user to choose from.  This way I can add new data filters without changing the base code at all.  This all works great until I tried to deploy it (built application).  How can I build an application where the dynamic vis are left in their own folder as individule files, ie not a monolithic program?  I am using LV 7.0 and windows XP.  can this be done?  The advantage of such an architecture is that I can develop new data processing algorithms and deploy them as plugins by simply placing them in the "plug-in" folder.

Paul

[becktho]

Hi Paul

Haven't seen you for a while ;)..

Basically this is possible. The main problem is the target path of you plugin vis. I'm not sure, but I think it is not possible to set a specific target path for some vis. If you could build them into a separate path, no problem. You just have to add them as dynamic vis.

In LV8.0 it should be possible to do this quite easily.

Thomas

[Matthew_Williams]

Yes, you can do what you described.

Open up your dynamic .vi, click 'File'->'Save with Options'->'Application Distribution'->'Save'.
This will create a .llb file which you can call dynamically from within a built application.  Call
with something like the attached.  Note that this example passes in some data; don't know if
you need to do that.

Also be careful about dynamically linked .vis called from your dynamic .vis.  If your .vi calls
something dynamically, you have to also save those secondary dynamic .vis into your .llb with
the procedure above.

Matt

Message Edited by Matthew Williams on 07-14-2006 08:50 AM

[becktho]

The "disadvantage" of this method, is that you have to build a library. I think what paul wants to do is to save the dynamic vis in a folder and that's it.

[Matthew_Williams]

Ahhh.  Makes sense.  Lots of ways to get there.  Thanks.

Matt

[tst]

---

@falkpl wrote:

How can I build an application where the dynamic vis are left in their own folder as individule files, ie not a monolithic program? 

---

It's simple - don't include the dynamic VIs in the build and they won't be included.

The 2 main things to note about this are (as Thomas mentioned) to make sure your calling structure is not dependant on the way your files are structured at design time and (more importantly) to make sure that the dynamic VIs are compiled. Since the RTE can not compile the VIs (and since you're not including them in the build), you will have to make sure that all they are saved and that all their dependancies are kept.
If you already have a VI open in the RTE of the same name, the VIs will open that VI instead of the one they think they should (I don't know how it works with 8, but you probably have to specify using a different instance for the behaviour to be different).

[falkpl]

Yes I have set it up to have a folder (saved in the applications preference file as a path) where all the subvis (all have the same call signature) are stored.  When I added them to the build they were incorperated as part of the application and not seperate files.

[tst]

You might have missed my post as you were probably writing your own - don't add them to the build.

[falkpl]

If I dont include them in the build can I still compile the sub vis separately?  I will be deploying them on a mhchine with the runtime engine only. 

Paul

[becktho]

I'm not sure, but I think you don't have to compile them. I made a simple test and calles vis that were not compiled dynamically (or at least I think I called these ;)).