LabVIEW has been on the market for several decades now, and over time has become an industry standard for the quick and easy acquisition, visualization, logging, and control of data from real world hardware. While LabVIEW makes it is easy for small and individual tasks to be developed in a very time efficient manner, the development of more complex multi-process applications remains a difficult and time-consuming process for most. Applications that require several independent loops, are robust, scalable, extensible, and easy to debug take time and experience to develop. Features that allow scalability, modularity, extensibility, and transparent debugging should be built directly into the code from the very beginning.

Options exist to help developers create multi-process applications in LabVIEW. The NI LabVIEW templates provide single-use design patterns. The Actor Framework provides enhanced scalability, extensibility, and priority queues through the use of LVOOP, yet is rather complex for novice developers to understand. Other frameworks exist from third parties. However, I still felt that more could be done to help novice developers that come out of the NI LabVIEW Core training courses produce quality applications quickly and easily in LabVIEW in a simple way, without requiring LVOOP experience, to learn a new design pattern, or use an unfamiliar framework architecture.

The backbone of many multi-process LabVIEW applications uses a Queued Message Handler (QMH) based architecture whereby applications are built up out of a hierarchy of QMHs which are either statically linked to or loaded dynamically by each other. While this is one of the most widely used, understood, and accepted ways of developing applications in LabVIEW, without the use of a framework and tools it is a slow and inefficient process to create, add and integrate many QMHs together. To help solve these problems, Workers™ was created.

The goal of Workers™ was to provide a scalable, modular, and extensible QMH replacement of the LabVIEW QMH template. Each QMH needed to be as easy to use as the LabVIEW QMH template and provide a quick and simple way of building a functional hierarchy (application) out of many QMHs. Each QMH had to be as minimal as possible, providing only the fundamental features of a QMH. A messaging API for communication between QMHs had to be easy to use and understand. Code duplication of VIs that perform the same function in every QMH had to be avoided at all costs. Any additional features that could be integrated to improve a developer’s coding efficiency, flexibility, workflow, data flow tracking and debugging, without bloating the basic LabVIEW QMH coding style, were added.

And thus Workers™ was born, the name simply implying that an application can be built out of a hierarchy of QMHs, with each QMH assigned some work.

I hope that Workers™ will be able to increase the productivity of novice and advanced developers alike, allowing you to develop larger projects in less time, and with less complexity.

Peter Scarfe, Creator of Workers™ for LabVIEW.