Overview

The video below is called ``DQMH Decisions Behind the Design'' and can be found at: bit.ly/DelacorQMH.

Decisions Behind the Design video DQMH Decisions Behind the Design video shows a presentation given at NI week 2016 where Fabiola De la Cueva gave an overview of what the DQMH is, the differences between DQMH and the NI QMH and some of the decisions behind DQMH design.

To understand this section of the documentation better, look at the corresponding Main.vi diagram in the NI QMH documentation to contrast the differences with the DQMH Module Main.vi.

Here are the primary differences:

Nomenclature

DQMH Event

LabVIEW code that carries custom data throughout the application. Implemented using Custom Events (also known as User Events). These events allow different parts of an application to communicate asynchronously when the events are programmatically generated. An event structure handles both types of events: end user interaction with front panel (i.e., a value change event on a control) and programmatically generated user events. More details can be found on the LabVIEW Help entry for User Events (or custom events). A DQMH can send events to multiple Event Structures and multiple locations in the code can send events to a DQMH module. DQMH Events are many to many.

There are two types of DQMH Events:

Request

Code that fires an event requesting the DQMH Module Main.vi to do something. Multiple locations in the code can send events to the DQMH module. Request Events are many to one. Requests are asynchronous events, the code that fires the event does not wait for a response from the DQMH Module Main.vi. Creating a Request and Wait for Reply type of event makes the Request synchronous.

Broadcast

Code that fires an event broadcasting that the DQMH Module Main.vi did something. Multiple event structures can register to handle the Broadcast Events. Broadcast Events are one to many.

DQMH Module Main

Each DQMH Module has a Main.vi, the full name for the Main.vi is DQMH Library Name:Main.vi. For example My Singleton Module.lvlib:Main.vi or My Cloneable Module.lvlib:Main.vi. This document refers to this VI as ``DQMH Module Main''. This VI can be renamed without breaking any of the DQMH scripting tools.

The DQMH Module Main.vi repeatedly performs the following steps:

A user interacts with the front panel, causing the Event structure in the Event Handling Loop (EHL) to produce a message. LabVIEW stores the message in a queue.
1. The DQMH Module Main.vi also registers to listen to requests sent by other VIs. Another VI requests that the DQMH module do something, causing the Event structure in the EHL to produce a message. LabVIEW stores the message in a queue.
The Message Handling Loop (MHL) dequeues a message from the message queue.
The message is a string that matches one of the subdiagrams of the Case structure in the MHL. Therefore, reading the message causes the corresponding subdiagram of the Case structure to execute. This subdiagram is called a “ message diagram” because it corresponds to a message.
Optionally, the message diagram produces another message, storing it in the message queue.
1. The DQMH Module Main.vi can optionally broadcast an event to other VIs that are registered to listen to them.
In the NI QMH the EHL only registers to listen to the Stop message. In the DQMH the EHL registers to listen to all the request events.
The DQMH Module Main.vi has Admin code that manages whether the module is a single instance (singleton) or it can be called multiple times in parallel (cloneable).

Notes

The EHL is the producer loop. The MHL is the consumer loop. These loops run in parallel and are connected by the message queue, which facilitates communication between the loops.

The message queue is a LabVIEW queue that stores messages for consumption. The two-loop architecture allows the EHL to receive external requests or user interactions and send them as messages to this queue while the MHL may be busy consuming previous messages. Each message queue belongs to a single MHL. Note that in the DQMH the VIs that manage the queues are not copied to the project like in the NI QMH. In the DQMH the queues are wrapped in a class and the managing VIs are stored in vi.lib. If the developer is comfortable with LabVIEW Object Oriented Programming, she can choose to override some of these VIs and create his own Message Queue class.

Every iteration of the MHL reads the message at the front of the message queue and then executes the corresponding message diagram. Although the MHL primarily consumes messages, it also can produce them.

Each loop handles errors using a loop-specific error handler subVI. If the DQMH Module Main.vi encounters an error in the MHL, LabVIEW displays an error message. These VIs are also wrapped in the DQMH Queue class and reside in vi.lib. If the developer is comfortable with LabVIEW Object Oriented Programming, she can choose to override some of these VIs and create his own Message Queue class.

Unlike the NI QMH template that encourages having an MHL for each task, the DQMH encourages having a new DQMH Module per task. With the DQMH scripting tools, the developer can select DQMH Consortium DQMH Module Add New DQMH Module… to quickly add a new module to his project.

Notice the Data cluster in the above diagram. This cluster contains data that each message diagram in the MHL can access and modify. In this template, the cluster is defined as a typedef (Module Data–cluster.ctl). Each typedef belongs to a single DQMH module and should only be modified by code in Main.vi.

Test Module API.vi

The DQMH also has a Test Module API.vi for each DQMH module.

This document refers to this VI as Tester.

This tester provides a convenient way to test all the request and broadcast events implemented by the DQMH Module.

The Test Module API.vi gets added when the developer selects Tools DQMH Consortium DQMH Module Add New DQMH Module…, and it tests the request and broadcast events that come with a DQMH Module.

The tester for singleton DQMH Modules registers to listen to the broadcasts from the DQMH Module Main.vi and handles each broadcast event in the event structure.

When the tester stops, the last request to be sent is to stop the module (in case it was not stopped earlier). It is important to execute that last request to avoid leaving the DQMH Module Main.vi running.

One of the advantages of the DQMH Module Main.vi design is that it can run headless.

Another advantage is that the tester can be used as a ``sniffer'' to monitor the status of a DQMH module that is already running.

The Core Requests and Broadcasts that come with a DQMH Module are:

Requests:

Show Module Panel: By default the module does not show the front panel of its Main.vi when it is started. Execute this request to show the front panel of the DQMH Module Main.vi. This request cannot be removed via Tools>DQMH Consortium>DQMH>Event>Remove DQMH Event….
Hide Module Panel: Execute this request to hide the front panel of the DQMH Module Main.vi#8202;. This request cannot be removed via Tools>DQMH Consortium>DQMH>Event>Remove DQMH Event….
Get Module Execution Status: Execute this request to request the DQMH Module Main.vi to report its current execution status via the Update Module Execution Status broadcast. This request cannot be removed via Tools>DQMH Consortium>DQMH>Event>Remove DQMH Event….
Show Diagram: Execute this request to show the block diagram of the DQMH Module Main.vi#8202;. This request does not work in executables. This request can be removed via Tools>DQMH Consortium>DQMH>Event>Remove DQMH Event….…
Do Something: Execute this request to tell the DQMH Module Main.vi to do something. The Main.vi then will broadcast that it did something. This request can be removed via Tools>DQMH Consortium>DQMH>Event>Remove DQMH Event….
Do Something Else: Execute this request to tell the DQMH Module Main.vi to do something else. The Main.vi will display the payload received. This request can be removed via Tools>DQMH Consortium>DQMH>Event>Remove DQMH Event….
Do Something Else and Wait for Reply: Execute this request to tell the DQMH Module Main.vi to do something else and return the reply immediately. The reply is not returned via a broadcast. This type of event is useful when the developer requires a synchronous message. This request can be removed via Tools>DQMH Consortium>DQMH>Event>Remove DQMH Event….
Stop Module: Execute this request to stop the DQMH Module Main.vi#8202;. This request cannot be removed via Tools>DQMH Consortium>DQMH>Event>Remove DQMH Event….

Disable the Include ``Do Something'' events in new module?option when creating a new DQMH module to exclude the “Do Something” events described above.

Broadcasts:

Module Did Init: The DQMH Module Main.vi broadcasts that it initialized without issues. This broadcast cannot be removed via Tools>DQMH Consortium>DQMH>Event>Remove DQMH Event….
Did Something: The DQMH Module Main.vi broadcasts that it did something. This broadcast can be removed via Tools>DQMH Consortium>DQMH>Event>Remove DQMH Event….
Status Updated: The DQMH Module Main.vibroadcasts a new status. This broadcast cannot be removed via Tools>DQMH Consortium>DQMH>Event>Remove DQMH Event….
Error Reported: The DQMH Module Main.vi broadcasts that an error occurred. This broadcast cannot be removed via Tools>DQMH Consortium>DQMH>Event>Remove DQMH Event….
Module Did Stop: The DQMH Module Main.vi broadcasts that it did stop. This broadcast cannot be removed via Tools>DQMH Consortium>DQMH>Event>Remove DQMH Event….
Update Module Execution Status: The DQMH Module Main.vi broadcasts whether it is currently running, this is used when the Start Module.vi executes and the module Main.vi is already running. This broadcast cannot be removed via Tools>DQMH Consortium>DQMH>Event>Remove DQMH Event….

Disable the Include ``Do Something'' events in new module? option when creating a new DQMH module to exclude the “Did Something” event described above.