DQMH Consortium Toolkits Discussions
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.
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.
@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.
