The goal of Workers™ was to create a Queued Message Handler that was as easy to use as the LabVIEW QMH, while being modular, scalable and more advanced where possible. Workers™ provides you with a QMH framework 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™ uses a priority queue to send messages between your Workers' Message Handling Loops (MHLs). Each message is assigned a priority: low, normal or high. This provides developers with flexibility and control over when messages of different importance should be processed... immediately or later when a MHL is idle. The priority queue also adds stability to the initialization and shutting down of your Workers, even if your MHL queues are overloaded with messages.
A framework is only as good as its Debugger! The Workers Debugger has been designed to make your running code more transparent and accessible. Its integrated Task Manager shows you all your running Workers along with their current status and allows you to jump into your running Workers for further debugging. Its integrated Message Log shows you the chronological list of all messages sent between your Message Handling Loop cases, showing you when and where a message was enqueued and where it was dequeued, as well as when and where any errors have occurred in your Workers. With the Debugger you can easily find your bugs and fix them quickly!
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 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 while you are developing, helping to you easily track the flow of your messages around your block diagrams.
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 Debugger 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 interactive Debugger you can jump directly to where an error has occurred in any Message Handling Loop, and immediately start fixing the problem.
Simply designed for beginner developers yet extendable by more advanced developers with LVOOP! Each Worker is a class, inherited from an abstract base class. This means that all common framework functionality is kept out of your Workers, keeping the contents of each Worker minimal and uncluttered. It also means that you can extend the Workers API by adding your own common data and VIs to the parent class of every Worker. Built with LVOOP makes the framework flexible and brings many additional benefits to developers.