There are numerous reasons why you would like to allow your LabVIEW application to be extended with plugins. First you may want to allow your customer or a third party to add some new functionality to your application. LVOOP plugins provide a way for you to allow third parties to extend your application. Second you may want to separate the built and development process of the core application from the development process of the features of the applications. With OOP projects LabVIEW development environment slows down dramatically as the number of classes gets too high. It may be wise to separate your application so that only the core elements form the main application and all other elements are provided as add-on components. Third you may want to control the memory footprint of your application and specify at runtime which components are loaded into memory; there is no need to keep the code for unused features in memory. Consider for example that your application supports multiple file formats or device drivers. You can load the needed file format plugins or device drivers on demand into memory at runtime.

Dynamic loading of classes

Adding extension support to your LabVIEW object-oriented programming application is fairly straightforward. You need to specify one or more interface classes into your core application that act as extension points for your plugins. Your plugins then need to override the dynamic dispatch methods of your interface classes to specify the functionality provided by the plugin. At runtime, you load the plugin classes together with all required support classes and VIs into memory on demand. To load a class into memory on demand, use Get LV Class Default Value node found from Cluster, Class & Variant palette and typecast the returned value of type LabVIEW Object to your class interface type.

I wrote a simple example application demonstrating the principles of LVOOP based plugins. The core application called main specified in a project file main.lvproj has one interface class called Plugin Interface. The front panel of the main application contains a control to specify the folder from which to search the plugins, a listbox that lists all the plugins found in this folder and a picture indicator that displays a picture drawn by a dynamic dispatch method of user selected plugin.

The on-deman loading of the plugins are handled in the Plugin seach folder value change event of main.vi. When a new plugin search folder is specified by the user, the code searches all the subfolders and LLB files under this folder for lvclass files. Each found lvclass file is loaded into memory and then tried to be casted into the Plugin Interface class. If the typecast succeeds, the class is assumed to be a plugin class and added to the array of found plugins.

This simplified method of loading plugins is not very effective as all plugins found are always loaded into memory. If you want to minimize the memory footprint of your application, a more sophisticated plugin loading mechanism is needed. The plugin capabilities need to be known before the plugin is actually loaded into memory. Therefore the plugin capabilities need to be specified in a separate settings file such as an XML file or an INI file. Based on the information provided in this settings file, the code in your plugin loader can decide if the plugin needs to be loaded into memory.

Building the application and the plugin extensions

The main application can be built into an executable without the plugin classes specified. Each plugin can be created in projects separate from the main application. The attached example project main.lvproj contains a built specifications for the main application and the project has no references to plugin classes used.

In our example we have two plugin classes, a Circle class and a Square class. The Circle class provides means of drawing circles and the Square class provides means of drawing squares. Both of the classes are specified in separate projects, circle.lvclass and square.lvclass respectively. The classes inherit from the Interface Class used in and built into the main application.

To built a plugin that can be used with the main executable, we use source distribution built settings. Even though the the name source distribution gives as the impression that this kind of built can be used for distributing source files only, the source distribution can indeed be uses as a binary plugin with LabVIEW built application. Both circle and square projects specify a source distribution built settings with the difference that square is built into a LLB file.

To built a source distribution that can be used as a plugin, several things need to be taken into account. First we need to include our plugin class into the source distribution. Second as the interface class is already included in the main application, it is a good idea to exclude it from the plugin source distribution.

The final thing to take into account when building plugin source distributions is to include all referenced library files into the distribution as these are not available in the runtime environment. By default LabVIEW exclude all library items used by the source distribution and these exclusions need to be removed before building the plugin. The exclusion of library items can be found in the Additional Exclusions section of source distribution built settings. To include all library items used, simply uncheck all the Exclude files from… items as shown in the image below.

After you have built the main example application and both the circle and the square plugin, you can close LabVIEW and try out the main application in LabVIEW runtime environment. To start execute the built main.exe and then select the folder into which you built your plugin source distributions with the Plugin search folder control. Selecting a proper plugin search folder should populate the list control with the plugins found. Clicking on the items on the list control should call the plugin method to draw an plugin defined picture on the picture control to the right.