Seeking Architectural Guidance: Implementing a Plugin-Based System

[LEAF-1LEAF]

Hi,

I am currently designing a large LabVIEW application that needs to be highly modular and extensible. Its core functionality needs to be able to load and interact with dynamically loaded "plugin" VIs at runtime.

I have been exploring a few different architectural patterns, including using a VI server or an Actor framework with plugin functionality.

I would particularly like to hear from those who have successfully implemented a plugin-based system in LabVIEW. What were the main challenges you faced? Any insights would be greatly appreciated.

[ShaunR]

On 4/30/2025 at 9:17 AM, LEAF-1LEAF said:

Hi,

I am currently designing a large LabVIEW application that needs to be highly modular and extensible. Its core functionality needs to be able to load and interact with dynamically loaded "plugin" VIs at runtime.

I have been exploring a few different architectural patterns, including using a VI server or an Actor framework with plugin functionality.

I would particularly like to hear from those who have successfully implemented a plugin-based system in LabVIEW. What were the main challenges you faced? Any insights would be greatly appreciated.

1. VI server. Simple and easy to implement with no framework dependencies.
2. Define a distinction between Services and Plugins (plugins don't contain state, services do).
3. Use a standardised uniform front panel interface between plugins. I use a single string control (see this post) and events for returns. An alternative is a 2d array of strings which is more flexible.
4. Each plugin is contained in it's own LLB which contains all of it's specific VI's. Just list the llb's in the directory for plugins to load. Replace the LLB to upgrade; delete to remove.
5. Names starting with an underscore (either in the LLB name, directory name or file name) are ignored and never loaded. They are effectively "private".
6. A scheme to prevent unknown plugins being loaded.