06-13-2023 05:07 PM
There are several training resources for learning DQMH, including the toolkit documentation, Tom McQuillan's videos, and so much more. With the availability of all this thorough content, it can sometimes be hard to figure out where to get started, and how deep down into DQMH you should go.
I present the following DQMH learning path, which in my opinion covers the minimum topics required to be conversant with day-to-day development and understanding of DQMH in real-world applications. This learning path will *not* cover the internal workings of the framework, as those complex topics are not necessary to *using* the DQMH Framework. Rather, this learning path is geared towards practical DQMH understanding by CLAD and CLD-level LabVIEW programmers.
Step 1: Introductory Video
Watch my Introduction to DQMH video (less than 60 minutes) to understand the motivation behind the design of DQMH, along with introductory demos describing basic constructs of the framework. This step is very important to complete prior to continuing with this learning path.
Step 2: Request and Wait for Reply Events
The DQMH shipping example illustrates some concepts that aren't covered in Step 1. First, open the example project here:
[LabVIEW 20xx]\examples\DQMH Consortium\DQMH Fundamentals - Thermal Chamber\DQMH Fundamentals - Thermal Chamber.lvproj
Open the following VI in the project: Thermal Chamber Controller with DUT.vi. On the block diagram, you will see two Request and Wait for Reply VIs... one for the thermal chamber, and one for the DUT:
Even though one of the benefits of DQMH is that it provides a way to implement asynchronous processes (discussed in detail during Step 1), there are times where you need to make a request to a DQMH module, and that request generates a response (or a "reply"). You could try to send a normal request, and then wait for a broadcast as a response, but in terms of using the Public API of a DQMH module, it is much more convenient for the request VI to include the response if the operation is truly synchronous, i.e. the calling code can't proceed without the response. So in the case of the example above:
Study the documentation on the diagram of the example VI for a full explanation. Use the Bookmark Manager to navigate various other DQMH-related comments within the example project. Also, check out this DQMH forum post that discusses the use of Request and Wait for Reply VIs in hardware APIs to return error information.
Step 3: Cloneable Modules
Open the following VI in the example project from Step 2: Thermal Chamber Controller with Multiple DUTs.vi. On the block diagram you will see some of the DQMH Request VIs being called within For Loops:
In this code, the DUT module is a cloneable module, which means that multiple instances of the DUT module can run at the same time. Those different instances are identified by their Module IDs, the integer wire generated by the Start Module VI. The For Loops are iterating over each created instance of the DUT and sending requests to those instances based on their Module IDs. Also notice that the Stop Module VI has a "-1" wired to it, which means that request is sent to all currently-running instances of the module.
Cloneable modules allow you to spawn multiple instances of a module, and then interact with those instances individually (by specifying a specific Module ID) or as a group (by specifying "-1" as the Module ID). Cloneable modules are useful for creating sophisticated UIs (like Tom's Chat Window), as well as implementing hardware APIs that allow spawning multiple instances of the same hardware (like the DUT in the shipping example above).
Step 4: Module Hierarchy and How to Start Modules
The DQMH Continuous Measurement and Logging (CML) sample project illustrates one core DQMH concept that isn't covered in Step 1. First, create a DQMH CML sample project here:
File > Create Project > DQMH Consortium > CML DQMH
Open the following VI in the project: Modules > CML UI.lvlib > Main.vi. This is the top-level VI of the CML application. Note the code in the upper-left of the Main VI diagram, which is a simple illustration of Module Hierarchy and How to Start Modules:
This pattern is very common in DQMH. If a DQMH Module needs to register for the broadcasts of other modules, and/or it needs to fire the requests of other modules, you'll want to make sure those other modules are actually running. The code construct in this image illustrates how to do this... start the other module(s), register for their events, then synchronize their events. This ensures that those other modules are running and initialized before the calling module's initialization is completed.
Step 5: Helper Loops
Helper Loops can be added to DQMH Main VIs to facilitate the execution of periodic operations independent of the EHL or MHL execution. Most Helper Loops are activated and deactivated via Private Events, which are like regular DQMH events, but they have been moved out of the Public API folder within the module so that they can only be called from within the module itself. Read the following article to learn more about Helper Loops and Private Events:
Hampel Software Engineering article on Helper Loops (despite the title, this article is not related to Actor Framework)
Step 6: DQMH Best Practices
The following article is maintained by the DQMH Consortium and lists best practices for DQMH development:
DQMH Consortium - DQMH Best Practices
Step 7: DQMH Do's and Dont's
The following article was written by Sam Taggart (DQMH Trusted Advisor) and contains excellent advice on DQMH development:
Sam Taggart - DQMH Do's and Don't's
Step 8: DQMH and HALs
It is highly likely as you continue your DQMH journey that you will encounter a situation where you need to either develop a hardware abstraction layer (HAL) with DQMH, or you need to study one that someone else has written. This article provides a good introduction to the topic of DQMH and HALs:
HAL in Your (D)QMH
As a supplement to this article you may also find it useful to watch the following video from NIWeek 2019 that goes into much greater detail on this topic:
HAL with LVOOP and DQMH (1 hour and 10 minutes)
Summary
There is a lot more to DQMH than what is discussed above. However, if you have gone through all the steps in this article, you have been introduced to most of the concepts that are likely to come up when working on regular DQMH development tasks.
06-13-2023 05:49 PM
Darren,
Thanks for the excellent suggestions on a DQMH learning path!
I would add that you could also visit the DQMH Consortium to see any training availability close to you or online at:
And I will add this post as a link in the replies to the post on what made DQMH click for people.
Thanks,
Fab
06-13-2023 08:28 PM
And there is a podcast too!
Hear from all of the DQMH Trusted advisors about how they approach their DQMH development:
DQMH® Podcast – Wired-In Software (wiredinsoftware.com.au)
06-13-2023 08:47 PM
Also, If you want to improve your DQMH Developer Experience, give it a try to Panther Dashboard for DQMH . It is an open source project to help DQMH developers find code easyly and call DQMH Scripting tools from buttons.