Welcome to Workers for LabVIEW

Build scalable, modular, and maintainable LabVIEW applications

Workers for LabVIEW is a modular application framework designed to help developers build scalable, maintainable, and reusable LabVIEW applications.

The framework combines the familiarity of the NI Queued Message Handler (QMH) development style with the flexibility of LabVIEW Object-Oriented Programming (LVOOP), allowing applications to be constructed from independent modules called Workers. Each Worker encapsulates its own functionality, state, APIs, and execution, making complex applications easier to develop, understand, test, and maintain.

Workers was created with a simple goal: to make modern modular software architecture accessible to everyday LabVIEW developers. The framework provides the architectural foundations, development tools, debugging utilities, training resources, and example projects needed to build applications ranging from small desktop utilities through to large test, automation, and real-time systems.

Whether you are new to software architecture or an experienced LabVIEW developer looking to build larger and more maintainable applications, Workers provides a practical and approachable path to modular application development.

Why develop with Workers ?

Familiar Development Style

Workers adopts the familiar development style of the LabVIEW Queued Message Handler (QMH), allowing developers to quickly understand and work with the architecture. Each Worker is implemented using a Message Handling Loop (mandatory) and an Event Handling Loop (optional), providing a structure that feels familiar while still supporting large-scale modular applications.

Worker A : Main.vi

Modular Application Architecture

Workers applications are built from reusable modules called Workers. These modules can be combined to form application hierarchies, allowing systems to grow from a handful of modules to large applications containing dozens of independent processes. Modules can be linked statically or loaded dynamically at run-time, while initialization and shutdown sequencing is managed automatically by the framework.

Example Worker call-chain hierarchy of a Workers application

Clear and Maintainable Communication

Workers communicate through strictly-typed Public APIs. This decouples a Worker from its Caller, allowing it to run, be tested, and be reused without compile-time dependencies on the applications that use it.

Messages are exchanged as Requests sent to a Worker and Responses sent back to a Caller (that a Caller must register), creating a clear and predictable message flow through the application.

Message flow across a Workers application

Hardware Abstraction and Reuse

Hardware Abstraction Layers (HALs) allow applications to communicate with different hardware devices through a common API. By taking advantage of LabVIEW's object-oriented features, Workers allows you to natively create abstract Public APIs defined in a base class. Different Workers can inherit from this base class, provide their own device-specific implementations, and be selected or loaded at run-time without changing the application code that calls those APIs.

Using a HAL in place of a concrete module allows you to load different hardware implementations at run-time

Workers 5.0 Introduction Presentation

Dr. Peter Scarfe, creator of Workers for LabVIEW, presented an Introduction to Workers 5.0 live on stage at GDevCon ANZ 2025 in Sydney, Australia. Here is the full 1 hour recording, explaining the "why" behind the framework's design and architecture, along with the key features of the framework.

GDevCon ANZ 2025 - Introduction to Workers 5.0 Presentation - Live

Good to know

You do not need prior experience with LabVIEW Object-Oriented Programming (LVOOP) to start developing with Workers. The framework is designed to be approachable for developers with little or no LVOOP experience. Many users begin by building applications using Workers' modular architecture and gradually adopt more advanced features such as Hardware Abstraction Layers, inheritance, and API overrides as their experience grows.