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 National Instruments 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 Windowin LabVIEW, and then clicking theDQMH 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 Tools>Delacor>Module>Add DQMH Module 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 Windowin LabVIEW, and then clicking theCML DQMH Sample Project Template.
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.
Updated video link to Validating an Existing DQMH Module that shows the new features for DQMH 5.0 and how to validate an existing DQMH 4.2 project to match DQMH 5.0
Clarified that the Application is implemented using a State Machine in the Getting Started section
Added DQMH as alternative to XControls in the Use Cases section
Added clarification at the beginning of the Nomenclature section that it is a list of links to other sections in the document
Updated figures and description for DQMH Cloneable modules in the DQMH Singleton Module vs Cloneable Overview section in this document. Specifically added in blue the new sections of the Cloneable module and an explanation of what they are there for
Added note with some improvements developers can make to projects created from the CML DQMH Sample Project
Added to DQMH in LabVIEW Real Time that starting with DQMH 5.0 we do support both DQMH Singleton and Cloneable modules in Real Time
Added video to Validating an Existing DQMH Module that shows the new features for DQMH 4.2 and how to validate an existing DQMH 4.1 project to match DQMH 4.2
Updated the Adding a New DQMH Module from a Custom Templatesection to describe the new Delacor>DQMH>Module>Create DQMH Module Template... menu option and the change in disk location for the DQMH Template Example
Replaced the XML contents of the Metadata in the Adding a New DQMH Module from a Custom Templatewith an image of the code and indications of where to find the example file to copy its contents from there. Some developers reported that copying the code directly from this document would result in errors.
Updated new menu organization going from having all the tools within the Delacor>DQMH> menu to having four menus: Delacor>DQMH>Event, Delacor>DQMH>Module, Delacor>DQMH>Real-Time Tools, and Delacor>DQMH>Testing Tools
Version 2.1.0.2: Published documentation at: delacor.com/dqmh-documentation. Updated images to reflect DQMH 2.1 version. Added description of what “DQMH Module Main” refers to in the Nomenclature section. Clarified the titles for the shipping examples and provided a link to skip TestStand sections if not using it. Added links at the end of each section to go back to the Table of Contents.
Version 2.0.0.0: Added section on how to use the new Rename DQMH Module utility. Updated images. Fixed typos.
Version 1.0.0.1: DQMH documentation for first public release
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.
The DQMH template can also be used to create custom controls and indicators that will be embedded in a Subpanel in another VI. DQMH modules are a good alternative to XControls where the Main.vi has the implementation for the control.
The Tools>Delacor>Add DQMH Module 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.
The Tools>Delacor>Add DQMH Module 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.
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.
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. 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.
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 nomenclaturefrom Private/Public events to Request/Broadcastevents, and (2) using the NI QMH as the basis for the modules instead of the JKI State Machine.
Create some DQMH events. For example, create a new Request named Change Front Panel Color for the Singleton module. Add a color box as the argument. On the API Tester, create a color box control that will be fed to the Change Front Panel Color VI created by the DQMH tools. Implement the change of the front panel color directly in the Main.vi for the Singleton module. Run the Singleton API Tester and observe how the color of the Singleton Module changes when you change the color from the API Tester
Learn how you can use the Tester VI to troubleshoot your modules and applications as the application is running
Get the DQMH Framework badge. One of the learning badges offered by National Instruments
You can compare and contrast the CML DQMH Sample Project with the Continuous Measurement and Logging Sample Project that ships with LabVIEW and it is also available in the Create Project dialog
Look at ways you can improve your CML DQMH project. For example, the project couples all the contents by all sharing the Settings Editor. Instead, try to separate the editor from the individual DQMH modules. What if each DQMH module would own their own configuration and just send their configuration page to the Configuration Editor? Before making any changes, make sure you model your solution using the tables and models recommended in Tips and Tricks for a Successful DQMH Based Project
Get the DQMH Framework badge. One of the learning badges offered by National Instruments
Learning Path 3: Using DQMH Modules Generated by Others
Tom's LabVIEW Adventure DQMH - Tutorial Series (Delacor Queued Message Handler). Tom is a friend of Delacor and he made this series as a contribution to the LabVIEW Community. He did consult with Delacor but this work is independent of Delacor, LLC.
Upgrading your existing code created with previous versions of DQMH to DQMH 5.0
The best way to identify how the new features in DQMH 5.0 affect your existing projects is to validate them. The Validating an Existing DQMH Modulesection includes a video demonstrating upgrading a DQMH project created with DQMH 4.2 to DQMH 5.0.
DQMH 5.0 prompts the developer to run the validate module tool right after upgrading DQMH via VIPM
Added the ability to validate all modules in the project. We also added a VI (Validate DQMH Module (Headless).vi that you can pass in a project path and it will programmatically validate all modules in the project and return a result. This VI could be used as part of CI/CD process to validate DQMH modules.
Added a button to the Validation Results UI that allows you to analyze another module after you are done viewing the results for the current module. We also added a button to the "all tests passed" dialog to allow you to validate another module
Changes to the way we start DQMH modules
DQMH 5.0 modifies how the DQMH modules are launched. DQMH now uses Start Asynchronous call instead of the Run VI Method. This change adds a VI Reference Management which is an action engine that manages the lifetime of the VI reference. Open VI Reference requires root loop access. By keeping VI reference open, subsequent calls to start module for that cloneable module do not require root loop access.
DQMH 5.0 replaces the code that used to wait for the last clone with a named notifier. This notifier fires when the last clone running stops. Clones share their DQMH event references. The first DQMH clone to start owns the event references, and when it stops, it waits until the last clone stops before destroying the shared references.
DQMH 5.0 now supports both Singleton and Cloneable modules in Real Time
API Testers
Improved API Tester developer experience: The API Tester does not stop the module on exit if it was already running when the API Tester started running. This is useful when using the API Tester as a sniffer
Request and Wait for Reply
Request and Wait for Reply now returns an error if the reply times out
DQMH Templates
If your custom DQMH template requires a different enqueue (for example for a DQMH Queue child or if the DQMH libraries were built into a PPL), we added the ability to specify a custom enqueue message VI to be scripted into the MHL when creating request events
A description of how to get started with DQMH can be found on the video "DQMH Getting Started" found at: bit.ly/DelacorQMH
The video is embedded below, followed by a description of what can be seen at different times in the video:
Getting Started with DQMH video
This video shows where to find the documentation for the Delacor Queued Message Handler toolkit, how to create a project from the template and where to find the shipping examples. The video explains what a Singleton vs Cloneable module is and how to run the testers and the individual modules.
0:00 Where to find Documentation
0:30 Create a DQMH from Project Template
1:20 Add a new DQMH Module to an existing project
1:40 Where to find the DQMH shipping examples
2:05 DQMH Project Template structure
3:40 Nomenclature: Request, Broadcast events and DQMH Module design pattern
5:12 DQMH as a stand alone module or part of a larger application
5:28 Steps to add a new DQMH Module
6:43 Module structure
8:30 Request event
8:58 Broadcast event
16:56 Shipping examples: Simple VIs calling DQMH public API (singleton)
19:50 Shipping examples: Thermal chamber with DUT (singleton & cloneable)
31:18 API tester tests errors when module is not running
An application that uses the DQMH will have one or more DQMH modules. Each DQMH module will have a Main.vi that is a version of the Producer/Consumer design pattern, where the user interface (producer) produces messages and the tasks (consumers) consume them. However, in the DQMH template, you can also produce messages from other DQMH modules or other VIs.
This template includes the following:
1 singleton DQMH module (can have only one instance of its Main.vi running at any given time)
1 cloneable DQMH module (can have one or multiple instances of its Main.vi running in parallel)
The video below is called "DQMH Decisions Behind the Design" and can be found at: bit.ly/DelacorQMH.
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.
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.
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 Tools>Delacor>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 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>Delacor>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>Delacor>DQMH>Event>Remove DQMH Event….
Hide Module Panel – Execute this request to hide the front panel of the DQMH Module Main.vi. This request cannot be removed via Tools>Delacor>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>Delacor>DQMH>Event>Remove DQMH Event….
Show Diagram – Execute this request to show the block diagram of the DQMH Module Main.vi. This request does not work in executables. This request can be removed via Tools>Delacor>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>Delacor>DQMH>Event>Remove DQMH Event….
Do Something Else – Execute this request to tell the DQMH Module Main.vi to do something else. TheMain.vi will display the payload received. This request can be removed viaTools>Delacor>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>Delacor>DQMH>Event>Remove DQMH Event….
Stop Module – Execute this request to stop theDQMH Module Main.vi. This request cannot be removed via Tools>Delacor>DQMH>Event>Remove DQMH Event….
Note: Deselect theInclude “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>Delacor>DQMH>Event>Remove DQMH Event….
Did Something – TheDQMH Module Main.vi broadcasts that it did something. This broadcast can be removed via Tools>Delacor>DQMH>Event>Remove DQMH Event….
Status Updated – The DQMH Module Main.vibroadcasts a new status. This broadcast cannot be removed via Tools>Delacor>DQMH>Event>Remove DQMH Event….
Error Reported – The DQMH Module Main.vi broadcasts that an error occurred. This broadcast cannot be removed via Tools>Delacor>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>Delacor>DQMH>Event>Remove DQMH Event….
Update Module Execution Status – The DQMH Module Main.vibroadcasts 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>Delacor>DQMH>Event>Remove DQMH Event….
Note: Deselect the Include “Do Something” events in new module? option when creating a new DQMH module to exclude the “Did Something” event described above.
Each DQMH module has its own project library (lvlib). This facilitates having the same icon header for all the members of the library and specifies which VIs are public and which VIs are only used by the library itself.
Each DQMH module has a Public API virtual folder that lists the VIs that can be called by VIs outside the library.
Within the Public API folder there is a Requests virtual folder that lists all the VIs wrapping the firing of the requests that can be sent to the DQMH Module Main.vi
In order to start a DQMH Module, two VIs need to be called: Start Module.vi and Synchronize Module Events.vi. These two VIs take care of launching the DQMH Module Main.vi as well as making sure the DQMH Module Main.vi has created its own request and broadcast events before the calling VI can fire or register to listening to broadcast events.
The Obtain Broadcast Events for Registration.vi can be used when the calling VI is not ready to start the DQMH Module Main.vi or it expects the DQMH Module Main.vi to have been started by another module. The Obtain Broadcast Events for Registration.vi will have the broadcast events if the DQMH Module Main.vi has already started or it will have empty references and it can be used to declare the event reference type for registration.
The DQMH Module Main.vi is a private VI. This encourages developers to use the public API to interact with the DQMH module.
The calling code can be another library or simple VIs. In the DQMH project template a Simple State Machine application is used to call the singleton and cloneable DQMH modules.
The Build Specification for an executable that uses Application.lvlib:Main.vi as the startup VI.
Notes:
The DQMH Module Main.vi creates its request and broadcast events to ensure that even if the calling VI leaves memory the references are still valid. This feature of the DQMH module facilitates calling the DQMH modules via TestStand as well as easily defining the lifetime of a given module’s event references. The combination of Start Module.vi and Synchronize Module Events.vi ensures that the DQMH Module Main.vi is ready to receive requests and the calling VI is ready to receive broadcasts.
The code that calls the DQMH module can be very simple, not even needing an event structure (especially if the calling VI does not care about broadcast events or is only calling request and wait for reply events). Refer to the Thermal Chamber Control example available from the Help>Find Examples…>Directory Structure>DelacorDelacor QMH>DQMH Fundamentals – Thermal ChamberDQMH Fundamentals – Thermal Chamber.lvproj >> Thermal Chamber Controller.vi for an illustration of this approach.
If the DQMH Module libraries are locked (right click the module .lvlib and choose Properties>Protection), only the public VIs appear in the Project Explorer window. This can be useful when sharing code with other members of the team to highlight the VIs that they will be using in calling code.
DQMH Singleton Module vs Cloneable Module Overview
A Singleton DQMH module can have only one instance of its Main.virunning at any given time. Every time theStart Module.vi is called, the same DQMH Main.vi instance is used.
A Cloneable DQMH module can have one or multiple instances of its Main.virunning in parallel. DQMH 3.0 added code for cloneable modules to be executed as singletons. If the cloneable is running as a singleton, the same instance will be returned every time Start Module.viis called (Module ID = 0). If it is running as a cloneable, the cloneable module assigns a new Module ID number to each new instance that is started when calling the Start Module.vi.
The calling code needs to provide the Module ID as an input to every request and broadcast VI. The event structure inside the EHL in the cloneable DQMH Module Main.vi has to determine if a request event was sent specifically to that clone before enqueuing the message to the MHL. A Module ID value of -1 means that the event was intended for all instances of the cloneable module.
A cloneable DQMH module library has a folder called Multiple Instances; this folder contains the Action Engine that manages the different instances of the module.
The cloneable DQMH module comes with a group of VIs to update a Module ID ring that can be used in the Tester or in the Application code to address the different instances of the module.
Since the DQMH Module Main.vi owns the lifetime of the request and broadcast events, code is needed to determine if the first instance can close. Before stopping, the DQMH Module Main.vi checks to see if it was the first instance of the module that was launched (and hence, the owner of the event references). If it was the first instance launched, then the module will exit both EHL and MHL loops and hold in the Close.vi waiting for all the other instances to close. The VI continues to run (with its panel hidden) until it is the last instance running, at which point it destroys the event references and stops.
The Clone Registration AE.vi is the action engine that manages all the DQMH cloneable module instances.
These VIs are the public API for the Clone Registration Action Engine and are used for the following tasks:
Initialize the clone registry
Add a new clone to the registry
Remove a clone from the registry when it stops
List all the available clones
Check if a module was the first clone to be registered
The Clone Registration functionality resides in a library with a Public API, which allows the developer to implement the registry with a different underlying mechanism besides an action engine if she so desires.
DQMH 5.0 modifies how the DQMH modules are launched. DQMH now uses Start Asynchronous call instead of the Run VI Method. This change adds a VI Reference Management which is another action engine that manages the lifetime of the VI reference. Open VI Reference requires root loop access. By keeping VI reference open, subsequent calls to start module for that cloneable module do not require root loop access.
DQMH 5.0 replaces the code that used to wait for the last clone with a named notifier. This notifier fires when the last clone running stops. Clones share their DQMH event references. The first DQMH clone to start owns the event references, and when it stops, it waits until the last clone stops before destroying the shared references. See 2. above.
The fact that the DQMH Module owns its own event references facilitates integration with TestStand. Refer to the Thermal Chamber Control example available from the Help>Find Examples…>Directory Structure>DelacorDelacor QMH>DQMH Fundamentals – Thermal Chamber for the Thermal Chamber Controller TestStand example sequences.
The ability to call the Public API methods of any DQMH module directly from TestStand results in a very clean TestStand sequence without the need for passing communication references or state data between the calling sequence and the code modules. A vital part of this architecture from a TestStand perspective is that the event reference lifetimes are owned by the DQMH module itself. TestStand can simply make a call to start a module and then make further calls to the module’s APIas required. An added benefit of the DQMH module’s use of events is that the API Testers that are created with each DQMH module can be used as “sniffers” to aid in debugging. Likewise a TestStand sequence can make calls to a DQMH module that is already running, allowing you to treat the module as a service. As the TestStand sequence is only making calls on thePublic API of a module, the majority of any debugging required will be carried out in LabVIEW.
To start a DQMH module from TestStand, a call should be made to the Start Module.viof the module:
The Start Module.vireturns a Wait for Event Sync? value that should be passed to the Synchronize Module Events.vi of the same module - This Boolean value can be persisted in a sequence local in TestStand. This approach is used to ensure the events are appropriately created (and therefore “owned”) by the DQMH module before calls are made to it using request events.
From this point onwards calls can be made directly to the Public API of the DQMH Module directly.
For cloneableDQMH modules the only additional point of note is that the Module IDshould be provided to allAPI calls so the eventswill be handled by the correct instance of the module. The Module ID is returned by the call to Start Module.viand should be persisted in a sequence local in TestStand so that subsequent calls to the module can be addressed correctly using this Module ID.
DQMH 4.1 introduced the CML DQMH, short for Delacor Queued Message Handler Continuous Measurement and Logging Sample project.
The video below is a presentation that Fabiola De la Cueva gave at GDevCon that goes over how we created the DQMH version of the NI QMH based sample project.
Look at ways you can improve your CML DQMH project. For example, the project couples all the contents by all sharing the Settings Editor. Instead, try to separate the editor from the individual DQMH modules. What if each DQMH module would own their own configuration and just send their configuration page to the Settings Editor? Before making any changes, make sure you model your solution using the tables and models recommended in Tips and Tricks for a Successful DQMH Based Project.
LabVIEW Example 1: Thermal Chamber Controller Example.vi
This example implements a Thermal Chamber Controller with a singleton Delacor QMH module. The chamber is configured to reach a temperature set point. Once the temperature is reached, the VI stops. This illustrates that there is no need to have an event structure in the calling code and provides an example of a DQMH module being used in a traditional “Configure > Read/Write > Close” application.
To get the example:
Go to Help>Find Examples…
From the NI Example Finder window, select Directory Structure>Delacor>Delacor QMH>DQMH Fundamentals – Thermal Chamber.
LabVIEW Example 2: Thermal Chamber Controller with DUT.vi
This example implements a Thermal Chamber Controller with a single DUT, using a singleton Delacor QMH module for the controller, and a single instance of a cloneable Delacor QMH module for the DUT. The chamber is configured to reach a temperature set point. Once the temperature is reached, the Unit Under Test (UUT) performs a Self-Test and returns the result. The Unit Under Test code is configured for an 80% pass rate for demonstration purposes. This example illustrates that there is no need to have an event structure in the calling code and provides an example of two DQMH modules being used in a traditional “Configure > Read/Write > Close” application.
To get the example:
Go to Help>Find Examples…
On the NI Example Finderwindow, select Directory Structure>Delacor>Delacor QMH>DQMH Fundamentals – Thermal Chamber.
LabVIEW Example 3: Thermal Chamber Controller with Multiple DUTs.vi
This example implements a Thermal Chamber Controller with multiple DUTs, using a singleton Delacor QMH module for the controller, and multiple instances of a cloneable Delacor QMH module for the DUT. The chamber is configured to reach a temperature set point. Once the temperature is reached, multiple Units Under Test (UUTs) each perform a Self-Test and return the result. The Unit Under Test code is configured for an 80% pass rate for demonstration purposes.
This example illustrates that there is no need to have an event structure in the calling code and provides an example of two DQMH modules being used in a traditional “Configure > Read/Write > Close” application. The example also illustrates how to manage multiple instances of a cloneableDQMH module.
To get the example:
Go to Help>Find Examples…
On the NI Example Finder window, select Directory Structure>Delacor>Delacor QMH>DQMH Fundamentals – Thermal Chamber.
Open DQMH Fundamentals – Thermal Chamber.lvproj.
OpenThermal Chamber Controller with Multiple DUTs.vi.
TestStand Example 1: Thermal Chamber Controller Example.seq
This example sequence is a very simple introduction into calling the Public API of a DQMH module from TestStand. This example starts a Thermal Chamber Controller DQMH module (singleton) and executes the following sequence:
Update the Set Point, Ramp Rate and Heater State (to allow heating).
Monitor the status until the target Set Point is reached.
This example provides an example of a DQMH module being used in a traditional “Configure > Read/Write > Close” application. TestStand can be used to quickly define sequential operations to be performed by a DQMH module.
TestStand Example 2: Thermal Chamber Controller Example With DUT.seq
This example sequence is an introduction into calling the Public API of multiple DQMH modules from TestStand. This example starts a Thermal Chamber Controller DQMH module (singleton) and a single instance of the Device Under Test DQMH Module (cloneable) and executes the following sequence:
Update the Set Point, Ramp Rate and Heater State (to allow heating).
Monitor the status until the target Set Point is reached.
Perform a simulated self-test of the DUT.
To get the example:
Go to Help>Find Examples…
On the NI Example Finder window, select Directory Structure>Delacor>Delacor QMH>DQMH Fundamentals – Thermal Chamber.
Open DQMH Fundamentals – Thermal Chamber.lvproj.
Open Thermal Chamber Controller Example With DUT.seq.
TestStand Example 3: Thermal Chamber Controller Example With Multiple DUTs.seq
This example sequence is an advanced example calling in to the Public API of multiple DQMH modules from TestStand. This example starts a Thermal Chamber Controller DQMH module (singleton) and multiple instances of the Device Under Test DQMH Module (cloneable) in addition to a TestStand Manager DQMH Module (singleton). The TestStand Manager acts as a relay, monitoring the execution status of the TestStand sequence and calling the Stop Module.vi of the other modules should the sequence be terminated or aborted. This prevents the likelihood of being left with orphaned running DQMH modules.
We utilize batch synchronization in TestStand to ensure that only a single thread will execute code associated with Thermal Chamber Controller operations. However, all threads will communicate and interact with a unique instance of the Device Under Test module. For more information on Batch Synchronization and Thread Scheduling please refer to the TestStand 1: Test Development course provided by National Instruments.
Note: This sequence programmatically sets TestStand to execute using the BatchModel.seq process model file in order to better demonstrate the use of cloneable DQMH modules.
The following section assumes that the Include "Do Something" events in new module? option was selected and that the "My Singleton" and "My Cloneable" DQMH modules were not renamed when the project was created.
Videos demonstrating the following steps and other examples are available at: bit.ly/DelacorQMH.
In the Project Explorer window, open and run My Singleton Module.lvlib:Main.vi.
Click the front panel controls and watch theStatus indicator display messages.
Stop the VI by closing the front panel. Since the module was started as a standalone module, the front panel does not close, but the VI stops.
Now run the Test My Singleton Module API.vi under the Testers virtual folder.
Click the Start Module button and wait for the LED indicating that the Module is runningto turn on.
Click the front panel controls and watch the tester update according to the requests sent and the broadcasts received.
The following video describes how to use the DQMH API tester as a sniffer. The video is called "DQMH API Testers As Sniffers" and it can be found at : bit.ly/DelacorQMH.
Follow these steps:
Run Application.lvlib:Main.vi.
On the Application.lvlib:Main.vi that is running and is titled "Application", click the Start My Singleton Module button once, a My Singleton panel will show. Then go back to the Application window and click the Start New Instance button several times. Several My Cloneable module panels should appear.
Click the front panel controls in Application.lvlib:Main.vi and observe the behavior of the DQMH Module Main VIs depending on the actions you performed.
Choose different module instances to communicate with by selecting different options in the Select Cloneable Module Instance ring.
Run the Test My Singleton Module API.vi under the Testers virtual folder.
Click the Start Module button (at this point, this is only needed to get the correct state on the Module Running? indicator).
See how actions on the Application.lvlib:Main.vi are reported in the tester. Also, actions can be initiated from the tester.
Repeat steps 5-7 by running Test My Cloneable Module API.vi under the Testers virtual folder.
Click the Refresh button to update the list of clones currently running.
See how actions on the Application.lvlib:Main.vi are reported in the tester. Also, actions can be initiated from the tester.
A DQMH module represents a task the application can perform, such as acquiring data or logging data, in parallel with other tasks. Each DQMH module can be divided into sub-tasks that correspond to states. The DQMH also responds to requests that other VIs can make in order to ask it to perform certain actions. It can also broadcast information to any VI that is registered to receive its broadcasts.
To create a new module:
Videos demonstrating the following steps and other examples are available at: bit.ly/DelacorQMH
Go to Tools>Delacor>DQMH>Module>Add New DQMH Module…
Provide a Module Name in the Add New DQMH Module dialog. This will be the name of the DQMH Module library.
Provide a Module Save Path. By default, if this project was created using theDQMH project template, the module will be saved under the Libraries\<Module Name> subfolder next to the .lvproj file on disk. A different path can be specified.
Specify whether or not you want to Include “Do Something” events in new module? If you are already familiar with creating DQMH modules, you can deselect this option, which will create a DQMH module with the minimum required set of events.
Optionally, click the Edit Overlay button. This overlay will be used by the new DQMH Module library and its VIs. This overlay can be later changed by right-clicking on the Module Library and selecting Properties>General Settings>Edit Icon.
Click OK to create the new DQMH Module. The new module .lvlib and TesterVI will be selected in the project explorer window after the new module is created.
The previous section describes how to add a new DQMH Module. This option lists “Singleton” and “Cloneable” DQMH modules as the only two types supported. Follow the steps below to create a custom DQMH Module template and add it to the list of available DQMH Module Types. After completing the steps below, the available types will be “Singleton”, “Cloneable”, and “MyNewModule”. Where “MyNewModule” is the name of the new custom DQMH module template.
To create a new DQMH Custom Template:
A demonstration of how to create a customized DQMH template can be found on the video "NI week 2016 Create DQMH Module From Template" found at : bit.ly/DelacorQMH. The video is embedded below:
Note: A DQMH Template Example is included with DQMH and can be found in <LabVIEW>\examples\Delacor\Delacor QMH\DQMH Template Example and includes a DQMH Template Example Module, its tester and its XML file mentioned below.
Go to Delacor>DQMH>Module>Create DQMH Module Template... menu and follow the wizard
Go to Tools>Delacor>DQMH>Module>Add New DQMH Module… and verify that <MyNewModule> is offered as an option for Module Type and the description text from the <MyNewModule>.xml file is displayed.
A DQMH Event can be either a requestor a broadcast. A request is code that fires an event that the DQMH Module Main.vi has to act on. A broadcast is code that fires an event that informs other VIs that are registered to listen that the DQMH Module Main.vihas done something. There are also synchronous events of the type request and wait for reply. These events are fired when the DQMH Module Main.vi needs to return a reply to the VI that called the request and this calling VI must wait until it gets that reply (or the request times out).
To create a new event:
Videos demonstrating the following steps and other examples are available at: bit.ly/DelacorQMH
Go to Tools>Delacor>DQMH>Event>Create New DQMH Event….
Two windows will open: the Create New DQMH Event window and the Arguments Window.
If you select to create a Request and Wait for Reply, an additional Arguments Window will open.
In the Create New DQMH Event window select the DQMH module for which you wish to create a new event. This drop down menu will only list valid DQMH modules found within the project.
In the Create New DQMH Event window, specify the type of event you wish to create. A description of each event type appears next to the drop down selection:
Request: An event generated by a caller that the module is registered to receive. Typically a requesteventis a request for the module to “Do something”.
For a request event, check the box if you want the tool to add a button to the API Tester to fire this event (this will reduce the number of things you need to do when the tool creates the request event and its associated code).
Typically a broadcastevent is generated after the module acts on a request. For broadcastevents, you are given the option to use the same argument as an existing request. An example would be a requestto confirm if current calibration values are up to date. The requestargument could be the current calibration values, and the requestargument could be the up to date calibration values.
Request and Wait for Reply: Arequestevent where the event generator waits for the module to process the request and return the request processing results. This provides synchronous request and reply functionality.
An additional DQMH Arguments Window will appear for the Reply Payload arguments.
Round Trip: A request and wait for reply eventand a broadcastevent where the Reply Payload and the Broadcast Argument are the same typedef. The request and wait for reply event has an input to determine whether the code should wait or not for the reply. In the case where the code doesn't wait for the reply, these events are asynchronous but may be logically related (i.e., Do SomethingandDid Something). In the case where the code does wait for the reply, the broadcast provides the opportunity of notifying other VIs, registered to listen to the broadcast, when another VI has called the request and is waiting for a reply. This is particularly useful in TestStand projects where the TestStand step needs to wait for the reply and we might want to use the API Tester as a sniffer and still see the reply reported there via the broadcast event.
Note that DQMH versions before 4.1, created the Round Trip differently, in those versions the Round trip was a combination of a request and a broadcast where both events shared the same argument typedef. Based on feedback from the DQMH community and Dealcor team's own experience, we decided to change the round trip to be now the combination of a request and wait for reply and a broadcast.
5. Specify the name of the new event (in the case of the Round Trip option, specify the name for the request and the name for the broadcast).
6. Add controls to the Arguments window. These values will be the arguments sent along with the event when it fires. Use a descriptive label for each control.
There is no need to wrap the arguments with a cluster in that window. The utility will take the controls in the Arguments window and add them to an Arguments typedef cluster. If you wish to receive all the arguments as a single cluster in the event loop, when the event fires, you may choose to wrap the arguments in a cluster. Examples include an x,y point, or a left, right, top, bottom values for a rectangle etc.
For Request and Wait for Reply events, a notifier reference does not need to be added in the Arguments window. The Create New DQMH Event utility will create the notifier and its typedef cluster payload automatically.
If the event is being created for a cloneable module, there is no need to add the Module ID control. The Create New DQMH Event utility will add the Module ID control to the Arguments typedef cluster automatically.
Existing typedefs can be added to the Arguments window.
If a new typedef is created in the process of adding controls to the Arguments window, you will be prompted to save the typedef before the event can be created.
At least one control has to be added to the Arguments window. This will make it easier to modify the code if the developer changes his mind and an argument is needed in the future. At that point a typedef argument cluster will be available for the developer to add other arguments.
(Optional) Enter a description for the event. This description will be included as the VI documentation for the VIs that this tool created to fire the event created.
Click OK to create the new event(s). The new event VI(s) will be selected in the project explorer window after creation is complete.
TheDQMH Module Main.vi and Tester VI might be broken. The developer has to complete several actions to complete the creation of this code, all of which are identified with #CodeNeeded bookmarks that can be explored with the Bookmark Manager window. DQMH 3.0 adds automatic wiring of event structure frames when used in LabVIEW 2016 or later. DQMH 4.2 adds automatic wiring of a test button on the API Tester if on step 4 above, the check box for this is checked.
The developer needs to complete the following actions:
Add a new front panel control to test the new requestevent.
DQMH 4.2 adds automatic wiring of a test button on the API Tester if this option was selected at event creation time.
Open the block diagram, which should be showing the newly added event frame with the new request VI inside. Right-click on the event structure, select Edit Events Handled by This Case, and select the control added in the previous step.
DQMH 4.2 will take care of this step automatically if the developer selected this option at event creation time.
By default, all the inputs of the request VI are required. Wire appropriate inputs to the request VI.
The Tester VI should no longer be broken (assuming it was not broken before the new event was added).
Open the block diagram, which should be showing the newly added event frame in the EHL and the newly added case frame in the MHL.
Right-click the event structure, selectEdit Events Handled by This Case, and select the newly created request that should be listed under Dynamic>><Module Name> Request Events.
Wire the event data (<arguments label(s)>) to the Bundle function in the event frame.
Add necessary code to the <request name> frame in the MHL case structure.
Open the block diagram, which should be showing the newly added event frame with the #CodeNeeded bookmark. Right-click the event structure, select Edit Events Handled by This Case, and select the newly created broadcast that should be listed under Dynamic>><Module Name> Broadcast Events.
Add code to process the event data sent by the broadcast event.
The Tester VI should no longer be broken (assuming it was not broken before the new event was added).
Add a new front panel control to test the new request event.
Open the block diagram, which should be showing the newly added event frame with the new request VI inside. Right-click the event structure, select Edit Events Handled by This Case, and select the control added in the previous step.
By default, all the inputs of the request VI are required. Wire appropriate inputs to the request VI.
Process the reply payload output from the new request VI.
If the payload argument needs to be changed, open the new request VI and right-click the Reply Payload indicator to open its typedef and edit it accordingly.
The Tester VI should no longer be broken (assuming it was not broken before the new event was added).
Open the block diagram, which should be showing the newly added event frame in the EHL and the newly added case frame in the MHL.
Right-click the event structure, select Edit Events Handled by This Case, and select the newly created request that should be listed under Dynamic>><Module Name> Request Events.
Wire the event data (<arguments label(s)>) to the Bundle function in the event frame. Take special care to wire the Wait Notifier event node output to the Bundle function that the utility added.
Add necessary code to the <request name> frame in the MHL case structure.
Wire the proper reply to the Send Notification function.
Note: The renamed DQMH Event VI will include a note in its documentation indicating “This VI was renamed by the DQMH Rename Event utility. Make sure the VI Description is updated to reflect the new event name, then delete this comment”. Also, none of the arguments nor MHL cases will be renamed. This is a security measure, because other code might be enqueuing to that case in the MHL loop.
Open the block diagram and find the event frame configured for this request (It might no longer be listed and instead say something like “Unknown Event (0x0)”).
Right-click the event structure and select Delete This Event Case.
Find the associated <request name> in the MHL case structure, right-click on the case structure, and select Delete This Case.
If prompted to save the request VI and its argument, select Don’t Save.
Open the block diagram and find the event frame configured for this broadcast. (It might no longer be listed and instead say something like “Unknown Event (0x0)”.)
Right-click the event structure and selectDelete This Event Case.
If prompted to save the broadcast VI and its argument, select Don’t Save.
Specify the new type of event, for now, the only option is to convert from a Request to a Request and Wait for Reply event.
Note that any custom code within the Event VI will be overwritten. Ensure you have copied any custom code from this VI before clicking OK. The Event VI is the VI named after the request event that you chose to convert.
Also note that a new frame will be added to the Message Handling Loop of the module Main VI for the specified event. The Module Main VI will be broken until you remove the old frame. This is doen so you can copy any code you want to preserve from the old frame to the new frame.
Click OK and the specified event will be converted to the new type.
Open the block diagram and find the event frame configured for this request.
Verify that the request event is now a request and wait for reply event and has a Wait for Notifier and a Wait for Reply node and they are both wired to the bundle message data.
There are now two cases associated with <request name> in the MHL case structure, one will have a #Code_Review_Todo tag indicating that the Delacor tools converted this request into a request and wait for reply and that you need to copy any custom code from this case to the new case. Once you have moved any custom case, right-click on the case structure, and select Delete This Case.
Go to the new case associated with <request name> in the MHL case structure and verify that the error argument is wired and that the code behaves as expected.
Right click on the reply argument cluster and open the associated typedef. Edit the <request name>(Reply Payload)--cluster.ctl to include the arguments you want the request and wait for reply to return.
Save the reply payload cluster and complete the code within the MHL case.
Videos demonstrating the following steps and other examples are available at: bit.ly/DelacorQMH
Go to Tools>Delacor>DQMH>Module>Rename DQMH Module….
Select the DQMH Module you wish to rename. This drop down menu will only list valid DQMH modules found within the project.
Enter the new name for the module.
Click the OK button and wait for the module to be renamed.
Right-click Renamed Module.lvlib>>Properties>>General Settings>>Edit Icon and edit the Icon Text>>Line 1 text to make the header reflect the new module’s name. Make any other changes like color and click OK when done.
Click the OK button on the Library Properties window, and when prompted to apply the new icon to all the VIs in the library, click Yes. Accept saving all VIs when prompted.
Run the Test Renamed Module API.vi and observe how all the places where used to have the old module’s name have the new one.
A Cloneable DQMH module can be executed in LabVIEW Real Time. The developer only has to drag the Cloneable DQMH Module to the desired target.
Note for DQMH 4.2 and earlier: Singleton DQMH Modules do not work in LabVIEW Real Time running in Linux operating systems. There is a bug in how VI Server works in Real Time for Linux resulting in the Ctrl Value Set invoke node used inside the Start Module.vi to not work. We decided to only support DQMH cloneable modules in LabVIEW Real Time.
DQMH 5.0 and later supports both Singleton and Cloneable modules in LabVIEW Real Time. DQMH 5.0 modifies how the DQMH modules are launched. DQMH now uses Start Asynchronous call instead of the Run VI Server Method.
However, the DQMH API Tester does not work as is in LabVIEW Real Time due to the use of Front Panel Controls events (for example value change). DQMH 4.0 introduced a new menu:
The video below is the same as the one in the DQMH in LabVIEW Real Time section. Here it starts at minute 5:24 where the video shows how to use the DQMH RT tester and keep it up to date.
We understand that there are DQMH modules that can execute either in "My Computer" or a Real Time target in a LabVIEW project. The new tool launched via Tools>Delacor>DQMH>Real-Time Tools>Create RT Tester... preserves the traditional DQMH Module API Tester and creates an additional DQMH Module API Tester for RT. From then on, anytime the DQMH scripting tools create a new event, they will add support for the new event in both the DQMH Module API Tester and the DQMH Module API Tester for RT.
The main differences in the DQMH Module API Tester for RT with respect to the traditional DQMH Module API Tester are:
DQMH Request Events are handled in the timeout event case of the event structure
DQMH Request Events are triggered via a button on the front panel of the DQMH Module API Tester for RT
The timeout event case of the event structure polls for changes on the buttons and determines which case to execute
DQMH Module API Tester for RT only works for Cloneable DQMH modules
Singleton DQMH Modules do not work in LabVIEW Real Time running in Linux operating systems. There is a bug in how VI Server works in Real Time for Linux resulting in the Ctrl Value Set invoke node used inside the Start Module.vi to not work. We decided to only support DQMH cloneable modules in LabVIEW Real Time.
DQMH Module API Tester for RT does not stop cloneable module instances when exiting the tester
We assumed that the DQMH API Tester for RT will be used as a sniffer only and as such, it should not stop the module instances unless explicitly requested via pressing the Stop Module instance button on the front panel
How to Create a DQMH API Tester for RT
Go to Tools>Delacor>DQMH>Real-Time Tools>Create RT Tester...
Select the DQMH module in your project that you would like to create a DQMH Module API Tester for RT for
Go to the project, the DQMH Module API Tester for RT should be below the DQMH Module API Tester
How to use a DQMH API Tester for RT
The DQMH API Tester for RT can be executed in three modes:
As a host VI: open the DQMH API Tester for RT directly from the project and run it. This will deploy the tester to the target and you will be able to interact with the front panel controls.
Via Operate>>Connect to Remote Panel... : This requires that your target has Remote Panel support software installed and that the Web Server is enabled on the target (right-click on target properties to enable the Web Server)
Via a web page installed in the www folder in the target computer. To create the web page, use Tools>>Web Publishing Tool... This also requires that your target has Remote Panel support software installed and that the Web Server is enabled on the target.
Note: If you want to use the DQMH API Tester for RT as a sniffer once your application has been built as a startup application that runs on your target, make sure the tester is added in the "always include" section of your build specification. As long as the web server is enabled on the target, you should be able to wake up the DQMH API Tester via a remote panel connection and use it as a sniffer.
DQMH 4.0 added a new productivity tool to create Unit Tests
The developer uses the Test Module API.vi to interact with the DQMH Public API and test it. This is very useful to verify that the DQMH module is working as expected. The developer can use the Test Module API.vi as a sniffer to verify that the module is working as expected when the application is running. While this is useful, it does not lend itself for automatic testing. If the developer wants to implement Test Driven Development (TDD), they would need to create their unit tests before they implement their Request events and Broadcast events.
This video shows how to create a DQMH Unit Test for an existing event.
Note: Developers do not need to be following TDD in order to use this feature. Developers could create Unit Tests for existing events by starting on step 3 on the list below.
The steps to introduce test driven development to DQMH are:
Create the Broadcastevent if necessary, save all, do not implement the code just yet.
Create new Unit Tests
Go to Tools>Delacor>DQMH>Testing Tools>New DQMH Unit Test…
Select DQMH module for which you wish to create the unit test.
Select the Request event you want to make a unit test for.
Click the OK button and the unit test will be created.
The New DQMH Unit Test adds the Unit Tests virtual folder to your project.
If this is the first Unit Test created for this Module, then the New DQMH Unit Test utility creates three VIs
<Module Name> setup.vi
<Module Name> teardown.vi
Test - <Module Name> - <Request Name> <number>.vi
If this is not the first Unit Test for this Module, then the New DQMH Unit Test utility creates only
Test - <Module Name> - <Request Name> <number>.vi
Note: There can be multiple unit tests for each Request event.
Implement the Unit Test by following the instructions given by the #CodeNeeded bookmarks on the newly created test.
The developer can choose their Unit Testing tool to run their new unit test. TheNew DQMH Unit Test utility is agnostic. Go to the help section for your tool
Right-click on the Test - <Module Name> - <Request Name> <number>.vi that the New DQMH Unit Test added to the Unit Tests virtual folder to your project.
Select Unit Tests>New Test
The Unit Test Framework creates a lvtest file for your new test.
On the Category section on the left, go to Setup/Teardown and configure this section to point to the setup and teardown VIs that the New DQMH Unit Test added to the Unit Tests virtual folder to your project.
On the Category section on the left, go to Test Cases and configure your test cases.
You can run the different test cases from this window by clicking on the green arrow on the top or you can click OK and run all your UTF tests from the tool bar.
You can find additional information here as to how to run your unit tests programmatically.
On the project tool bar click on the Right-click on the Add New Test Case button.
When prompted, save your new test case in the <Project>\Unit Tests\<DQMH Module Name> folder. Make sure your test case class includes the word Test in its name.
If you plan to have multiple test cases and only start and stop the DQMH module once, delete the setUp.vi and tearDown.vi and right click on the class and select New>VI for Override... and use globalSetUp.vi and globalTearDown.vi instead.
Place the <DQMH Module Name> setup.vi that the New DQMH Unit Test added to the Unit Tests virtual folder to your project inside the setUp or globalSetUp.vi.
Place the <DQMH Module Name> teardown.vi that the New DQMH Unit Test added to the Unit Tests virtual folder to your project inside the tearDown or globalTearDown.vi.
Right-click on testExample.vit and select New From Template. This will create the new unit test for your code. Replace the temp_VI_UnderTest.vi with the Test - <Module Name> - <Request Name> <number>.vi that the New DQMH Unit Test added to the Unit Tests virtual folder to your project.
Save your test class
Save your project
On the project tool bar click on Open VI Tester button
If your new test is not listed, click on the Reload test hierarchy button
Integrating DQMH Unit Tests with other unit test frameworks
The video below is the same as the one in the Creating DQMH Unit Tests section, except it starts at minute 4:44 where we describe the steps to create a DQMH Unit Test for other unit testing frameworks.
Create a new VI under the Unit Tests virtual folder to your project.
Add to that VI the <Module Name> setup.vi, Test - <Module Name> - <Request Name> <number>.vi and <Module Name> teardown.vi that the New DQMH Unit Test added to the Unit Tests virtual folder to your project. Wire them and save this VI.
Integrate this VI to your own unit test framework or just run this VI on its own to verify that your unit tests pass.
The Delacor Queued Message Handler (DQMH) template is based on the National Instruments Queued Message Handler Project Template (NI QMH) that ships with LabVIEW 2012 and later. 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.
Implementing communication between DQMH modules using events was 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/Broadcastevents, and (2) using the NI QMH as the basis for the modules instead of the JKI State Machine.
HSE Generic Networking for DQMH Modules: The DQMH GenNet client and server helper modules provide network connectivity for DQMH modules. The helper modules support both automated, transparent routing in Generic Networking Modules as well as manual extension to any generic DQMH module.
HSE Windows Application Template: A demo application based on the HSE flavor of DQMH modules with basic functionality for module loading and configuration, UI management and logging/debugging.
HSE DQMH Module Templates: These DQMH module templates contain add-ons and modifications for HSE default functionality
Zuehlke DQMH Project Explorer tool makes all the Delacor menu items available via right-click directly on the LabVIEW Project Explorer window
Moore Good Ideas Panel Manager in combination with their MGI Panel Manager - DQMH Panels package adds two new templates for creating modules that implement their panel interface
Under the copyright laws, this publication may not be reproduced or transmitted in any form, electronic or mechanical, including photocopying, recording, storing in an information retrieval system, or translating, in whole or in part, without the prior written consent of Delacor, LLC.
