DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

What made DQMH click for you?

For me, DQMH clicked about three days into my first project.

 

Broadcasts, singletons, cloneables... it all kind of went over my head to begin with. I'd read the documentation, talked through the theory with others, but there's no substitute for getting in there and doing it. Defining the project modules and the inter-module messages on paper started me off, integrating the associated module events started to make sense, but the real "aha" moment was the API testers. By being able to independently command a DQMH module to test individual functions, I finally saw how it all fit together.

 

Naturally, I was making all sorts of mistakes on that first project as I was working out the "rules", but the second DQMH project I was able to just get in there and do it.

 

As part of that first project, I even developed my own DQMH monitoring tool that gave me confidence that I had successfully picked up the DQMH concept. I added a broadcast message to the MHL of each module that contained the MHL message and message data, bundled it with a timestamp and module name and developed a standalone vi ("DQMH Monitor") that monitored the MHL broadcasts of all modules and listed them in a table. That way I could see how all the modules were responding to each other in the project (eg ensuring they all updated their data cluster if the system configuration was updated) and I immediately found two bugs that weren't apparent using the module API testers.

 

I don't profess to be an expert on DQMH, but the click for me came about by throwing myself in the deep end on a real project.

Message 11 of 23
(3,081 Views)

I was looking for a scalable and modular framework. I first came across DQMH through Tom's tutorials and got an understanding of how to work with it. In the meantime, I really appreciate the encapsulation as .lvlib in the modules. This way we can work on a project as a team via git - each in his own module - without influencing each other.

Message 12 of 23
(2,713 Views)

DQMH in Action has furthered my understanding a lot, huge Kudo to K_bull. Seeing something that was a good deal more than one clone and one singleton, that somebody actually uses, and seeing the general program flow of it, helped tremendously. In particular, the Application Initialise and Shutdown graphic was very telling. DQMH Best Practices and Simple DQMH Dos and Don'ts have also been good resources.

 

I would say the biggest thing I'm confused about at this point is best practices in terms of coupling. What module should be listening to what other modules' broadcasts, what module should start what other modules, if best practice between GUI and controller modules is to create a broadcast for every button press and value change, and the controller listens to those and carries out any actual actions, that kind of stuff. For example, I know it's okay to call "Initialize Motor.vi" (request for motor module to try to connect to motor) directly from my GUI module, but repeat that for enough actions and then my GUI module would quickly become the real controller.

 

In regards to what modules call what modules, I'm generally torn about whether Main should call Controller and then Controller calls everything else, or if Main just calls every other module as K_bull does. Sometimes you just gotta start somewhere, see how your architecture and communication schemes are in terms of "the big three" readability, scalability, and maintainability (reusability as well), and recognize that in general, making something the best it can be is an iterative process. And just for the record I'm starting out with the second way.

Redhawk
Test Engineer at Moog Inc.

Saying "Thanks that fixed it" or "Thanks that answers my question" and not giving a Kudo or Marked Solution, is like telling your waiter they did a great job and not leaving a tip. Please, tip your waiters.

Message 13 of 23
(2,662 Views)

@FireFist-Redhawk wrote:

Sometimes you just gotta start somewhere, see how your architecture and communication schemes are in terms of "the big three" readability, scalability, and maintainability (reusability as well), and recognize that in general, making something the best it can be is an iterative process. And just for the record I'm starting out with the second way.


I highly recommend using Antidoc for that. It makes it easy to visualize the dependencies.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
Message 14 of 23
(2,650 Views)

Hello

 

I'm looking for how the labview framework of DQMH works.

 

I found a video about a "Diagram sequence live" developed by Olivier Jourdan which allows to have a dynamic analysis of the code.

https://www.youtube.com/watch?v=b_tRtGRYvzg&ab_channel=LUGE%3ALabVIEWUserGroupRh%C3%B4ne-Alpes

 

Do you know if this tool will be implemented in a future version of DQMH?
Is there a next version of DQMH in the pipeline, planned for 2023?

 

Sébastien

0 Kudos
Message 15 of 23
(1,905 Views)

Hello Sébastien,

 

Yes, and yes 😁

 

No promises on when the different releases will happen, but we hope 2023 to be full of new features for DQMH users.


Olivier Jourdan

Wovalab founder | DQMH Consortium board member | LinkedIn |

Stop writing your LabVIEW code documentation, use Antidoc!
Message 16 of 23
(1,895 Views)

Great news

 

One more reason for me to use DQMH in my next development  🙂

 

Thanks Olivier

Message 17 of 23
(1,885 Views)

@Seb41  a écrit :

 

One more reason for me to use DQMH in my next development  🙂

 


I can't agree more 😁


Olivier Jourdan

Wovalab founder | DQMH Consortium board member | LinkedIn |

Stop writing your LabVIEW code documentation, use Antidoc!
0 Kudos
Message 18 of 23
(1,859 Views)

I wanted to add a link to this excellent post by Darren: 

https://forums.ni.com/t5/DQMH-Consortium-Toolkits/DQMH-Quick-Learning-Path/td-p/4310741

 

He has good suggestions for a DQMH learning path.

 

Happy wiring,

Fab

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?
0 Kudos
Message 19 of 23
(1,485 Views)

As I look back now (been using/learning DQMH since about spring 2023), I think this was my process:

  1. Watched several videos (too many to link all) demoing it from Fab and the tutorials from Tom M. Several times in fact. (This got me really interested in understanding how to use it on my projects). 
  2. Read the documentation (I even read/scanned the Style Guide through) and articles, (Do's and Don'ts article by Sam, and a Better Practices article) to try to get the vocabulary down (broadcasts, events, requests, singletons, cloneable, helper loops, "put to sleep", "Private requests", EHL, MHL, dependencies, inter-dependent, etc.) 
  3. Practice on my own with the CML example. To start, I just clicked and looked the block diagram over, probing a bit to watch what was happening. (I really like using the Testers as "sniffers" and to help understand the module's interaction with the outside world.)
  4. I had to read up more on helper loops which of course led me to Jörg's article. (Later I eventually learned how to use the 2nd type of HL because that was a bit more involved...)
  5. Started modeling my own program on paper, trying to pay attention to not make my modules too dependent on the others. I wanted to be able to reuse them in other projects. I think Sam's article and maybe a short video (I can't find now) inspired me to make a "tree" or pyramid type program where I have broadcasts go down the tree and requests go up.
  6. Using the CML example as my starting project, I began to start to add my own modules in the project. Now I was really "Learning by doing".  

Now I'm several (I think 🙂 ) successful projects in, and have written maybe a dozen of my own modules from scratch. I'd say the latest learning step was how to successfully use cloneable modules. This step this pushed me to learn how to start my cloneable modules in the EHL, using a "private request" called from the MHL.

So to recap, it was mostly spending hours and hours laying the groundwork (steps 1-4) and then start implementing it myself (steps 5-6). Additionally I found this discussion board pretty quickly which answered a lot of questions that came up as I stumbled through things.

 

I'm still learning and gaining confidence as I go. I'm so glad to have found DQMH because my projects would be a mess without the framework and organizational tools it provides.

Anyways, I'm pretty excited about DQMH. 

 

 

Message 20 of 23
(1,214 Views)