User interfaceReady to change the target
Target20 °C
Framework
A shared architecture. Room to grow.
DQMH extends the Queued Message Handler pattern with event-based communication and tools for building modular LabVIEW applications.
One responsibility per module.
Keep your user interface, acquisition, logging, and control logic in separate modules. A module handles its own work and exposes an API for the rest of the application.
Requests go in. Broadcasts go out.
Ask a module to perform an action through a request. Let interested modules react to a broadcast when something changes.
Test a module on its own.
Use the generated API Tester to exercise a module before connecting it to the rest of your system.
Help the whole team contribute.
A common structure makes unfamiliar code easier to navigate, whether you are onboarding a developer or returning to an older application.
THERMAL CHAMBER / DQMH IN ACTIONOne request. A shared update.
Illustrative exampleAcquisition
Sensor reading20.8 °CRunning independentlyLogging
Last saved setpoint—Waiting for an updateControl
Temperature setpoint20 °CReady for a requestRequest · one moduleBroadcast · subscribers
Independent, but connected.
The UI sends a request. Control shares an update with its subscribers.
CHOOSE THE RIGHT STARTING POINT
Two module types. Different needs.
Singleton modules
For a single instance of a responsibility in your application, such as an application-wide logging service.
Cloneable modules
For multiple instances that share a design, such as independent instruments or acquisition channels.
Scripting tools
Add, rename, and manage events and modules while maintaining the framework’s conventions.
CHOOSE WITH CONFIDENCE
When should I use DQMH?
DQMH is a good fit when you need clear boundaries between parallel work and a structure your team can keep maintaining.
Several responsibilities at once.
Coordinate acquisition, control, logging and user interfaces without putting everything into one loop.
Hardware and instrument modules.
Encapsulate device behaviour behind a module API. Use cloneable modules when your system needs several instances.
Test and measurement systems.
Keep measurement, sequencing and reporting responsibilities separate while communicating through events.
Applications maintained by teams.
A familiar structure helps developers with different experience levels share work, review changes and onboard colleagues.
Applications that need to last.
Keep the implementation of each responsibility behind its API so you can evolve modules without rewriting every caller.
Modules you can test independently.
Exercise each module with its generated API Tester before integrating it, and use the tester to investigate communication.
A small, single-purpose VI may need less structure. Start with your application’s responsibilities and team’s experience; choose DQMH when its module boundaries and tools help you manage that work.
THE QUEUED MESSAGE HANDLER PATTERN
Receive quickly.
Handle work in its own loop.
The Event Handling Loop receives a request; the Message Handling Loop executes queued work. This keeps event handling separate from the implementation of an action.
INSIDE ONE MODULE
From an event to the work.
The standard DQMH module builds on the Queued Message Handler pattern.
- 01CallerCalls a request VI
- 02 / USER EVENTRequestAsks for an action
- 03 / EHLReceiveEvent Handling Loop
- 04 / QUEUEEnqueuePass a message
- 05 / MHLExecuteMessage Handling Loop
THE MODULE SHARES AN UPDATEBroadcast event“The measurement is ready.”
- User interface
- Logger
- API Tester