"Workers allowed us to design a clean, modular HAL-based system. Fully abstracted, easy to scale, and simple to extend."

APPLICATION BUILT

We developed a modular PXI-based validation platform using PXIe-148x Chimera cards for GMSL1 and GMSL2 SerDes communication, with migration plans toward GMSL3 support in LabVIEW 2025 Q3.

The system was designed with a strong focus on abstraction and modularity, allowing the application to remain scalable and maintainable as the platform evolved.

Hardware Abstraction Layers (HAL) were used to decouple hardware-specific implementations from the core application logic, making it possible to add new boards and hardware configurations without modifying the main codebase.

Communication between modules was handled dynamically, avoiding direct dependencies and increasing overall system flexibility.

IMPACT ON DEVELOPMENT

This architecture made it much easier to:

• scale the system with new functionality

• support different testing modes such as Capture and Passthrough

• modify individual subsystems without affecting the rest of the application

• maintain responsive performance through background processing

The modular approach also simplified long-term expansion and reduced the effort required to adapt the platform for future testing requirements.

RECOMMENDATION

Workers is especially valuable for applications that require long-term scalability, modularity, and hardware abstraction. The framework encourages clean separation between system components and makes it significantly easier to evolve applications over time.

APPLICATION WORKER CALL-CHAIN DIAGRAM

"Whenever I work on a legacy system or something built without Workers, I immediately think, “This would have been so much easier with Workers.”

APPLICATION BUILT

I use Workers as the architectural foundation for industrial automation and measurement applications developed for multiple clients. During the requirements phase, I already structure the application around the planned Worker architecture, which makes both implementation and testing significantly easier later in the project.

This approach also allows individual parts of the system to be developed early or simulated independently when hardware is not yet available. The abstraction capabilities introduced in Workers 5.0 have been especially valuable for remotely developed systems and projects that need to support future hardware upgrades, such as replacing IO modules or switching DMM hardware.

GETTING STARTED

The examples and training material made it much easier to understand the architectural concepts behind the framework. One of the best ways to learn Workers was by rebuilding existing applications using the framework and then reviewing the architecture with experienced Workers developers.

This helped reveal better abstraction strategies and improved overall application structure.

IMPACT ON DEVELOPMENT

Workers significantly reduced my debugging workload and gave me confidence that applications start up and shut down reliably. Most debugging now focuses only on smaller interface or implementation details rather than large architectural problems.

The Debug Server became an essential tool throughout development, especially for validating initialization behavior, timing, and module interaction. The Call Chain Viewer is also extremely useful when returning to projects after long breaks.

The scripting tools, API Builder, launcher VIs, and modular Worker architecture greatly improved development efficiency by allowing modules to be tested independently and integrated incrementally.

RECOMMENDATION

I would strongly recommend Workers to developers building modular or long-term LabVIEW applications, especially when abstraction, simulation, maintainability, and hardware flexibility are important.

The framework encourages cleaner architecture from the very beginning of the project and makes it much easier to scale and evolve systems over time.

"Workers was both easy to learn and powerful enough to build a multi-module EV battery tester with clean APIs. I have zero regrets choosing it."

APPLICATION BUILT

I developed an application for an EV battery module tester capable of testing up to six battery modules independently. One of the major advantages of the Workers architecture was the ability to create a reusable test-channel UI Worker once and then scale it across all six channels with minimal additional effort.

The application was successfully deployed to multiple customer locations and delivered as part of a production testing system.

GETTING STARTED

The framework was easy to learn thanks to the short explanation videos, sample projects, and documentation. The familiar QMH-style architecture also made the transition approachable.

The Workers Debug Server quickly became one of the most valuable tools during development and debugging.

IMPACT ON DEVELOPMENT

The modular Worker-based architecture allowed each hardware subsystem to be developed and debugged independently. Once a Worker’s public API was functioning correctly in isolation, integrating it into the larger application became significantly more reliable and predictable.

The framework’s scripting tools also accelerated development while reducing coding mistakes and repetitive boilerplate work.

The final application received very positive feedback for its fast loading times, responsive UI, and quick shutdown behavior.

RECOMMENDATION

I would definitely recommend Workers to other LabVIEW developers. The framework is approachable for newer developers while still being powerful enough for advanced architectures and scalable applications.

The active community support was also extremely helpful whenever questions came up during development.

"Worker Public APIs (and HALs) seamlessly integrate with NI TestStand. A powerful framework that provides a real productivity boost."

APPLICATION BUILT

We developed several Workers responsible for communication with our hardware systems. Using the API functionality introduced in Workers 5, we were able to integrate these Workers directly into NI TestStand as custom steps.

This allowed us to build reusable, ready-to-use TestStand libraries while keeping the hardware communication layer modular and standardized.

GETTING STARTED

The documentation and sample projects made it straightforward to get started with the framework. Since the architecture follows the familiar LabVIEW QMH style, it made it quite easy to get started.

IMPACT ON DEVELOPMENT

Workers helped standardize our code structure across the team, making applications much easier to maintain, update, and extend. The Debug Server has also been extremely valuable, especially at customer sites where only the LabVIEW Runtime is available.

Overall, the framework has significantly improved our development efficiency and maintainability.

RECOMMENDATION

I would definitely recommend Workers to other LabVIEW developers. It is easy to learn, integrates naturally into existing LabVIEW development workflows, and provides immediate benefits in code organization, debugging, and long-term maintainability.

“Simple to learn, powerful to scale — Workers makes LabVIEW development efficient for developers at every level.”

APPLICATION BUILT

We developed a scalable Windows-based application for a customer operating around 10 similar industrial machines. Each machine consisted of three hardware modules, managed through a common inheritance-based hardware Worker architecture.

A centralized Head Worker dynamically loaded machine-specific configuration data such as Modbus addresses, IP addresses, and hardware parameters directly from a database. By inheriting from the shared hardware Worker, each machine-specific Worker automatically adapted to its own configuration without requiring separate application development.

This approach enabled us to deploy a single unified application capable of running simultaneously across all machines while ensuring easy scalability, maintainability, and centralized configuration management. Additionally, we developed an independent dashboard system that continuously monitors and displays the live operational status of all machines in real time.

GETTING STARTED

We were searching for a framework that offered strong documentation, ease of implementation, and was friendly for junior developers.

After evaluating multiple frameworks such as Actor Framework, DQMH, and others, we found that the Workers architecture best matched our requirements. One of the key advantages was its accessibility for developers who are familiar with basic QMH architecture but may not yet have deep Object-Oriented Programming (OOP) knowledge. This significantly reduced the learning curve for junior team members while still providing the flexibility and scalability required for advanced application development.

Over the past two years, we have successfully implemented multiple applications using the Workers architecture, and our experience has been extremely positive. It has proven to be an excellent framework for teams with mixed experience levels, enabling both junior and experienced developers to collaborate efficiently within a consistent and maintainable development environment.

IMPACT ON DEVELOPMENT

The framework has significantly improved our development speed, code reusability, and maintainability. By using a modular worker-based architecture, we developed a single scalable application that supports multiple machines with minimal code duplication.

ts clean structure, along with the Debug Server, makes debugging and issue tracing much easier, while also simplifying future modifications and expansion. Dynamic configuration handling reduces development effort when adding new machines or updating hardware settings.

Additionally, the framework enables both junior and experienced developers to collaborate efficiently within the same project structure

RECOMMENDATION

We would definitely recommend the Workers framework to other LabVIEW developers. Features like the Debug Server and the user-friendly Workers Tools menu make development and debugging much easier.

Creating and adding workers, messages, and requests is simple and efficient, which helps improve code organization, reduce development time, and simplify maintenance for teams with different experience levels.

For this example, we will take a working source-code example and turn it into a deployable PPL plugin architecture. To make it easy to follow, this guide uses the DMM HAL Demo Project that ships with the Workers SDK, allowing you to follow along with the steps. The result is a version of the example project in which both the DMM HAL and the DMM Workers are PPLs, suitable for deploying in production in place of the source code.

What you will need

• The DMM HAL Demo Project — one of the example projects that ships by default with the Workers SDK. This is the Source Project you will work from throughout this guide.

• LabVIEW Solution Builder — a free tool that builds packed libraries in the correct dependency order. Download the master branch from github.com/jovianarts/LVSolutionBuilder, then unzip it somewhere convenient..

• LabVIEW 2019 or later — required by the LabVIEW Solution Builder.

Important: Source and PPL modules are not interchangeable

A library compiled into a PPL belongs to the PPL runtime tree. The same library in source form belongs to the development source tree. The two are not interchangeable: a PPL plugin cannot be loaded with source-based parents, and a source plugin cannot be loaded with PPL parents.

Because the source code and the PPLs belong to separate trees, the workflow uses two separate projects: a Source Project, where development takes place, and a PPL Project, where the built PPLs are assembled into an application. Steps 1–3 produce the PPL runtime tree from the development source tree. Steps 4–5 work within the PPL runtime tree.

Let's begin...

Before starting, create a copy of the DMM HAL Demo Project example project that ships with the Workers SDK. (This can be found under the Workers tools menu > Example Projects). Confirm that the example project runs correctly from source. The code should be working before it is built.

Step 1 — Organize the Source Project into libraries

The Solution Builder works at the library level, so each component to be turned into a PPL must reside in its own library.

1. Create a library named DMM Workers.lvlib and add the Worker plugins (Fluke, Keithley and Keysight DMM) to it.

2. Create a library named DMM HAL.lvlib and add DMM HAL.lvclass to it, together with its launchers — Asynchronous Launcher - DMM HAL.vi and Launcher - DMM HAL.vi.

The Source Project should now contain two libraries, each holding one layer of the architecture, as shown below in Figure 2.

Step 2 — Create the packed library build specs

Create a Packed Project Library build specification for each library, as shown in Figure 2:

1. PPL DMM HAL — built from DMM HAL.lvlib.

2. PPL DMM Workers — built from DMM Workers.lvlib.

In each build spec, open the Source Files page and confirm that the library created in Step 1 is the source — not loose classes or VIs.

3. Open the Additional Exclusions page and tick Exclude dependent packed libraries, as shown below. This setting prevents the builder from embedding a private copy of the HAL inside the Workers PPL. Both PPLs then resolve to one shared HAL at runtime — a single shared class identity rather than two separate ones.

Step 3 — Build the PPLs with LabVIEW Solution Builder

The PPLs must be built in dependency order: the HAL first, then the Workers that depend on it. ⭐ Good news! You don't need to manually do this! The Solution Builder determines this order and carries out the builds.

1. Open SolutionBuilder.vi from the copy downloaded earlier from the LabVIEW Solution Builder GitHub repository, and point the Path field on the front panel to your Source Project.

2. Run SolutionBuilder.vi.

The Solution Builder analyses the library dependencies, builds PPL DMM HAL first, relinks it in memory, then builds PPL DMM Workers with the PPL DMM HAL as its linked dependency. After the tool completes, the Status for both build specifications should say Built.

The two output PPLs — PPL DMM HAL.lvlibp and PPL DMM Workers.lvlibp — are written to the build destinations defined in their build specs. Note these locations; the files are needed in the next step.

Step 4 — Create the PPL Project

1. Create a new, separate project as shown in Figure 5 below, and add the two PPLs produced by the Solution Builder — PPL DMM HAL.lvlibp and PPL DMM Workers.lvlibp.

This is the PPL Project. Everything in it works with the packed libraries, which are not the same VIs the Source Project uses. This project corresponds to the PPL runtime tree in Figure 1 above.

Step 5 — Use the PPLs

The PPL Project needs its own top-level VI to run the example. Add a VI named PPL Universal DMM User Interface.vi (as in Figure 5) to the project. It can begin as a copy of the Universal DMM User Interface.vi from the Source Project, but every Worker class and Public API VI used on its block diagram must be replaced with the equivalent Worker class or VI from the PPL libraries, as shown in Figure 6 below. The Source Project and the PPL Project use different files, and the deployed VI must reference the PPL versions throughout.

With that done, you have successfully built Worker PPL plugins. Because PPL DMM Workers.lvlibp was built with PPL DMM HAL.lvlibp as its linked dependency, its Worker classes inherit from the PPL HAL. A Worker (e.g. Fluke, Keithley, etc.) can therefore be wired directly into the PPL HAL Public API VIs.

Building every layer as a PPL, in dependency order, with Exclude dependent packed libraries enabled, places the whole system on a single PPL tree: one DMM HAL, one shared class identity, and any DMM Worker that inherits from it can be loaded without modification..

Step 6 — Update the Workers and rebuild

You can now continue development in the Source Project. New DMM Workers can be created, and existing ones modified, in the usual way.

To deploy those changes, run the Solution Builder again as in Step 3. As long as the DMM HAL source code is unchanged, the Solution Builder detects this and does not rebuild PPL DMM HAL — it rebuilds only PPL DMM Workers. The updated PPL is written to the same destination, and the PPL Project picks up the new Workers without any further changes.

This is the ongoing workflow: develop in the Source Project, build with the Solution Builder, and the PPL Project always references the built PPLs.

Best of luck! 🙂

After debugging, I found that the PPL built for the HAL layer breaks during type casting. This appears to stem from the child class being dependent on the parent class. Even when attempting to build a minimally dependent PPL (similar to the Keithley approach), the HAL classes are still pulled in due to inheritance relationships, which ideally should be avoided.

One approach I considered was disconnecting or removing typedef dependencies before building the PPL, so that the child class is no longer tightly coupled to the parent. However, it looks like the child Main VI directly calls MHL Cases.vi, which introduces another hard dependency. Because of this, even if the typedef dependency is removed, this direct VI linkage becomes another bottleneck and prevents proper decoupling.

Has anyone encountered a similar issue? Is there a recommended workflow or best practice when building PPLs for the HAL layer, especially when dealing with workers and inheritance hierarchies?

Main vi of Keithly DMM class

Would it make more sense to rewrite this as a Worker?

The code I created, which uses "Get LV Class Default Value.vi" and "To More Specific Class.vi" seems to be working correctly as I can launch the remote HAL and it functions normally. However, I see a difference in how the Workers Debug Server shows its status. In the traditional HAL project, all the Workers show their status as "Initialized", but in the remote HAL project, the Workers Debug Server show their status as "Initialize called", which implies the workers did not complete their initialization (even though they seem to be functioning normally).

My question, is the status shown in the debug server expected or is there still a problem to be solved here?