The goal of Workers was to create a Queued Message Handler (QMH) that would look and feel like the LabVIEW QMH template, while being modular, scalable and extensible at the same time.
Developed for both Windows and NI Real-time platforms,
Workers provides you with the following features:
A 'Worker' is the name given to our modular Queued Message Handlers (QMHs). Being modular, Workers join together like building blocks so that you can easily create a hierarchy of them to form the frame of your application. Their modular design also make them re-usable and easy to scale with our Create/Add Worker tool. They are designed to be minimal yet flexible, reducing the need for duplicated code, and can be either statically-linked to one another or dynamically loaded.
Workers allows you to quickly build up the frame of a LabVIEW application with as many Workers as you need with our Create/Add Worker tool. This tool allows you to create and integrate Workers directly together in very little time, saving you effort during your initial development phase and whenever you need to scale your application in the future. With this tool you can also re-use Workers from other projects, or create new Workers based on your own Worker templates.
Workers is built with LVOOP, providing several benefits over non-LVOOP based LabVIEW frameworks. For example, a Worker's functionality can be extended by inheriting the Worker from a Worker base class, where you can put common code that can be utilized by your Workers. This also means that the Workers API and all common framework code is kept out your Workers, significantly reducing code duplication in each Worker. This keeps the structure of a Worker minimal and easy to understand for beginner developers, while also being extensible for more advanced developers.
A framework is only as good as its debugger! From the very beginning the Workers Debug Server was developed along-side the framework, designed to help to make your running code more transparent and easier to navigate. The Debug Server connects to Workers applications via TCP, so that you can observe your applications regardless of the platform you are running your code on. The Debug Server provides both a Task Manager and a Message Log for your running applications. The Task Manager shows you all your running Workers along with their current status. The Message Log shows you the chronological list of messages sent between your Worker Message Handling Loop cases, showing you when and where a message was enqueued and dequeued, as well as when and where any errors have occurred in your Workers.
Workers uses a priority queue to send messages between your Workers' Message Handling Loops (MHLs), providing you with additional functionality over the standard LabVIEW FIFO queues and events. Each message is assigned a priority: low, normal or high, and messages are always dequeued in the same order they are enqueued for any given priority. These features provide you with more flexibility and control over when messages of different importance should be processed first, and which can wait until later.
What’s the call-chain hierarchy of the Workers in your project? How do Workers in your applications call other Workers? Are they statically linked-to or dynamically loaded by another Worker? The Worker Hierarchy Viewer tool shows you this information by showing you the call-chain hierarchy of a Worker in your project. While the LabVIEW Project Explorer shows you a flat view of all the Workers in your project, the Worker Hierarchy Viewer shows you the compile-time tree view relationship of your Workers. A useful tool to help you architect your applications.
Case Labels are a unique feature of Workers that are used in place of 'string constants' to define which case of a Message Handling Loop you want to send a message to. They provide many advantages over string constants and can be easily created for any case by use of a Quickdrop shortcut. They can also be used to jump from 'enqueue' point to 'dequeue' point in your code, helping to you easily track the flow of your messages around your block diagrams while you are developing.
Efficient application development requires not only tools to help you create your applications, but also tools to help you find and fix bugs in your code. Workers by default implements universal application error reporting, meaning that any errors that occur in your code are automatically sent to the Debug Server and/or are logged to file. These errors are timestamped and the location of where an error has occurred is recorded. It is up to you how you ultimately handle your errors, but you will be aware of them and through the Debug Server you can jump directly to where an error has occurred in any Message Handling Loop and immediately start fixing the problem.