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.

[losting]

Hi there,

Great question — building a modular LabVIEW application with dynamic plugin loading is definitely a rewarding (and sometimes tricky) path. I’ve worked on similar architectures in test systems for electronic components, where we needed to dynamically load test procedures (as VIs) based on the device type or protocol (SPI, I2C, UART, etc.).

Here’s what worked well for us:

VI Server + Strict Type Definition: We defined a strict connector pane interface for all plugin VIs. This made it easy to load, call, and communicate with each plugin uniformly, whether it was a basic power test or a complex timing validation routine.

Plugin Metadata: We stored metadata (e.g. DUT type, test category, plugin path) in an external config file (JSON or INI), so the main application could dynamically discover and load plugins based on the connected device or selected test plan.

Encapsulation: To keep each plugin clean and focused, we implemented per-plugin state handling internally using FGVs or even mini actor-like modules.

Main challenges:

Version compatibility: When firmware or hardware revisions changed, some plugins required updated logic — this required version tracking and good documentation.

Debugging dynamic calls: Debugging a broken plugin that fails to load at runtime can be painful without good error logging. We included detailed error tracing and visual logging in the framework early on — a huge time-saver.

Hardware abstraction: We wrapped hardware interaction (like GPIO toggles or I2C commands) in common interface VIs to decouple the plugin logic from the actual test instruments.

If your application also deals with automated test equipment or embedded devices, making your plugin architecture hardware-agnostic will greatly increase its flexibility and reusability.

Would be happy to chat more about plugin communication models or modular test design for electronics!

Best,

[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.