North Oakland County LabVIEW User Group

Showing results for 
Search instead for 
Did you mean: 

DQMH Framework 8/1/2018

Go to solution


Thanks for attending the group meeting today. Attached are the slides of the presentation.


Check out also the HAL example I mentioned written by Chris Roebuck here.





Luis CT
0 Kudos
Message 1 of 3
Accepted by topic author Luis_CT

Great presentation Luis!



Just a few comments after a quick dig through of the DQMH code:



The difference between the singleton vs clone-able modules at a high level I think is a slight performance/memory gain.  The clone-able modules have more extensive initialization code than the singleton and also differentiate between events meant for them versus other clones as seen here.  The singleton modules are also not re-entrant.cloneable.JPG


















Modules themselves do confirm back that they have started as a part of the framework however the one caveat is that this is done as a part of the module which means a user could conceivable remove this functionality if they did not know what it was for.start init.JPG


















Finally, commenting on the SMO vs Delacor question and specifically why SMO uses objects.  I believe this has to do with commonizing the framework APIs. You can start/stop any SMO with the same API calls, the use of opbject oriented programming makes this very easy.  DQMH appears to create unique APIs for each module.

multi start.JPG










I saw my father do some work on a car once as a kid and I asked him "How did you know how to do that?" He responded "I didn't, I had to figure it out."
Message 2 of 3



Thanks for sharing DQMH with your user group. You mentioned in an email to me that there were two questions that you would like for me to expand on, so here are my comments.


1) Difference between Singleton and Cloneable in terms of memory, efficiency and why DQMH has Singleton if it is possible to create a Cloneable with the Singleton behavior.


You can read more about the difference between Singleton and Cloneable in the DQMH Documentation.

The existence of the Singleton module is two-fold:

  • Simplicity: It is a lot easier to explain how DQMH modules work using the DQMH Singleton module. Managing the clone IDs add extra complexity to the code. If all the programmer wants is a module that is accessible in different parts of their program, they can call Start as many times as they want and they will always get the same instance.
  • For most applications, that is all is needed: We found that in the majority of applications using DQMH, programmers were using only Singleton modules with only a few instances requiring the Cloneable modules. When we discovered that programmers were getting into a situation where they would have wished the module was cloneable, we added the feature to be able to run Cloneable modules as singletons.  

Blackburnite also made some good observations on his post above regarding the differences. Blackburnite said "Modules themselves do confirm back that they have started as a part of the framework however the one caveat is that this is done as a part of the module which means a user could conceivable remove this functionality if they did not know what it was for."


There are several things in the that could cause the module to not behave as expected, however, we expect that LabVIEW programmers will be using the DQMH API Tester to launch and test their code. The scripting tools even encourage the programmer to keep their DQMH API Tester up to date. A DQMH out of the box does three things very well: "Starts when we tell it to start and reports back immediately, reports errors to DQMH API Tester (or stops in error if running as a stand-alone), stops graciously and immediately". If the DQMH module stops doing any of those three things, then it is something the programmer just did. Running the DQMH API Tester after each new event has been created or new features have been implemented will ensure that the programmer would know immediately that they removed something they shouldn't have removed. 


2. Why DQMH is not LVOOP based? 


We decided to limit the LVOOP to be done inside the DQMH module. Our main objective was to make DQMH accessible to teams with different levels of proficiency. This includes teams where some programmers are not familiar and do not want to become familiar with LVOOP. This allows the programmers who do want to use LVOOP and are comfortable with LVOOP to use it inside the module itself and provide a public API that does not contain any LVOOP at all. 

For other ways to combine LVOOP and DQMH, check out the HAL post at the Delacor blog. Also, I gave a presentation at NI Week with some other tips and tricks for DQMH projects and there is a section (tip 5) where I describe other ways LVOOP can be used with DQMH. 

DQMH also has a feature where LabVIEW programmers can create their own DQMH Module Templates and still take advantage of the DQMH scripting tools, the shipping example of a module template replaces the local data with an object.


It was never our intention to have everyone use DQMH. We understand that every team is unique and have their own needs. If the entire team is comfortable with LVOOP and work most of their time in LabVIEW, then Actor Framework might be a better option for that team. If a team has their own framework and it works for them but they would like to add some automation for the repetitive tasks as we have done, we would be more than happy to help them get there.


If you want to discuss DQMH more, please visit the DQMH forum.




I'm Organizing the GLA Summit!

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
Message 3 of 3