Introduction
DQMH was originally created and maintained by Delacor, with Fabiola De la Cueva being the chief architect. In 2021, Delacor transferred all rights and responsibilities to the DQMH Consortium, LLC |
Generalities
The DQMH® Project Template is based on the NI Queued Message Handler Project Template (NI QMH).
The DQMH improves the NI QMH by:
-
providing safe, event-based message handling and scripting tools,which makes development easier
-
encouraging consistent style among different developers in the same project, which improves efficiency
The DQMH provides the greatest benefits in applications employing multiple modules running in parallel that communicate with each other. These different modules can run either with their front panel open or headless (with their front panel closed).
The DQMH can also be used for applications that have a single module in which a Tester has the capability of eavesdropping on the different DQMH events and messages (both in development mode and in an executable).
Each DQMH module has a structure similar to a NI Queued Message Handler module, and it has a Test DQMH Module API.vi (also known as the “Tester”) to help troubleshoot, debug, and eavesdrop on the communications between the DQMH Module and its calling code.
If the developer is creating an application that will employ multiple DQMH modules, the best place to start is with the Project Templates. This is done by clicking Create Project from the Getting Started Window in LabVIEW, and then clicking the DQMH Project Template.
If the developer is creating a single DQMH module that will be called by their existing code or used as a stand-alone application, open an existing project and use the utility.
Starting with DQMH 4.1, there is also a Sample Project Template for the DQMH version of the Continuous Measurement and Logging (CML DQMH) Sample project. Create a copy of this sample project by clicking Create Project from the Getting Started Window in LabVIEW, and then clicking the CML DQMH Sample Project Template.
DQMH Background
Implementing communication between DQMH modules using events is based on the concepts presented by Justin Goeres during CLA Summit 2011 and NIWeek 2011 (more information here). The main modifications to Justin’s approach were (1) changing the nomenclature from Private/Public events to Request/Broadcast events, and (2) using the NI QMH as the basis for the modules instead of the JKI State Machine.
Documentation assumptions
This documentation assumes that you are familiar with Producer/Consumer design pattern and with the NI QMH Project Template. If you are not familiar with these topics, the NI QMH documentation can be found by clicking Create Project from the Getting Started Window in LabVIEW and then clicking the More Information link in the NI QMH project description. You can also create a project based on this template, which will include a copy of the documentation.
Use Cases
Modularity
The first and foremost feature of the DQMH template is modularity, which can be thought of as dividing up a complex large-scale project into a series of simpler small-scale projects. Thus any good modularization framework should be based on a good small-scale template that should be usable by itself for a small-scale project.
It might seem "overkill" in a way to use a modular framework with only one module, but there are advantages, such as when project requirements unexpectedly grow and the project isn’t so small-scale anymore.
Templating
Reducing DQMH to that single aspect of modularity doesn’t do it justice, though. Even for stand-alone modules, you benefit from all the built-in features that come with DQMH: QMH pattern (no manual creation of loops or queues or events), scripting tools for adding functions, API testers for testing templates and more.
Parallelism
The DQMH template is useful for applications where multiple tasks occur in parallel, often at different rates. It is also useful when multiple instances of the same Front Panel are needed (this requires using a cloneable DQMH Module). For example, consider an application that controls a single temperature chamber and needs to log data from multiple units under test (UUTs). A cloneable DQMH Module would be used to implement a single UUT and a singleton DQMH Module would be used to implement the temperature chamber.
Singleton Design Pattern
The
utility can add individual DQMH Modules to existing projects. This is useful for applications where a continuous running process needs to be added and the rest of the code needs to communicate with this process. For example, consider an application where communication with a serial instrument needs to poll the serial port continuously waiting for a series of commands to be received. A singleton DQMH module could implement the communication with the instrument. The existing application could start this singleton DQMH Module and register to listen to the serial port commands. The Test DQMH Module API.vi could then be used to eavesdrop on the communication between the Singleton DQMH Module and the rest of the code as well as a vehicle to test the instrument connected to the serial port as well.Stand-Alone Applications
The
utility can also be used to add a new DQMH module to a new project where the DQMH is intended to be the standalone application.Refactoring
For existing applications, when adding features that will (or might) be used in other applications, refactoring your application and carving out said functionality into a DQMH module will provide the required level of modularity, i.e. the code to be shared is kept separate from the rest of the application, it is not depending on the rest of the application, and it provides a well-defined and documented API defining how it should be integrated into applications.
Due to the way that DQMH is designed, it does not dictate the architecture of the whole application. Developers can start out by adding a single module to their application, not having to migrate the complete application in one go.
Design and Architectural Templating
Another use of the DQMH Module template is for teams with different levels of proficiency. The DQMH Module could be designed and implemented by one team member, and others with less LabVIEW familiarity could just call the DQMH Module API VIs in their code, without having to understand how the DQMH Module itself is implemented.
Resources
Here are some videos of presentations the Delacor team has given on real world examples using DQMH.
The following video is from a presentation we gave at NI Week 2017 where we created an application from scratch to executable in less than one hour.
You can find more details about this presentation at bit.ly/rapidDQMH |
The following video is from a presentation we gave at NI Week 2015. Starting at minute 29:55 the video describes how we modeled and implemented the application using DQMH modules.