Generic question about QMH and DQMH

[1984]

Hi,

I understand the concept of QMH and - I guess - I have reasonable understanding of the DQMH design patterns. I used them in many "inherited" projects but scalability, readability and maintainability was always something I had a hard time with and I'm very much discouraged to use them in my projects

To be more specific take look at the Continuous Measurement and Log example coming with labview and also with DQMH. This block diagram look absolutely doesnt look scalable, nor readable to me. Actually it looks very cluttered and hard to expand. The actual area where the code happens (in the event structure and in the case structure is so small relative to the screen that I have really hard time to squeeze in code. Of course I can make them somewhat bigger but by then I risk readability in a way that the VI goes larger than ideal. Not to mention that messaging itself breaks the dataflow and from that point debugging these modules who send and receive messages back and forth could be quite tricky.

I did many projects just by to good old state machine with some minor tricks which for me was actually a lot readable. I guess I never wrote a very big labview application but I wrote tons of complete manufacturing solutions (UI + DAQ + machine control + logging + User management + safety etc etc) and they worked very well.

Now on the other hand I assume that I miss something big by avoiding to use these design patterns, so I'd love to understand how smarter people approach the problems I mentioned above. (or if they are considered problems at all)

Thx!

EDIT: I have just noticed a somewhat similar post right below mine (https://forums.ni.com/t5/LabVIEW/Is-QMH-obsolete-Am-I-wasteing-my-time/td-p/4169277/). I believe though that my questions is a bit more generic, so if you have anything to add (besides what you have added already to the topic above) then please do.

[Olivier-JOURDAN]

Hi there,

Can I ask you how many hours have you spent coding with DQMH (or another framework you never used before)?

From my own experience, it takes some time to adapt when you are used to a specific way to develop. In my case, I needed to develop a small app for 80~100 hours to be comfortable moving from using an internal framework for 17 years to DQMH.

I can say now that DQMH is readable even if you have different developers on your project.

About your specific structure sizes concern, you add most of your code in the MHL (the loop that contains the case structure) most of the time. It's straightforward to make it bigger (and you can create a template with a bigger one to avoid making this each time you create a new module).

Concerning messaging that breaks the data flow, I would say that it's hard to avoid if you want scalability (and reusability) in medium to large apps.

DQMH comes with tools that help you dealing with that.

[drjdpowell]

I'm the big hater on NI's design of a QMH, from over in that other thread you link to.   But I'm a big proponent of queued-message-handlers as a design pattern (just not that awful one).  And any way of dividing a larger app into a set of smaller semi-independant "modules" is a way to get scalability.  You might think that leads to poor debuggability, but that is only if you forget the "semi-independent" bit.  In an app with 10+ modules, I will be doing most debugging on one module at a time; often, just running a module independently of all others (the DQMH has this capability via its "testers").  

The "very cluttered and hard to expand" bit in your image is a workaround of a design flaw in the NI-QMH, where there is no way to atomically perform several "messages" in a row without possible race conditions, so they have to do all initialization logic in one case of the lower loop.  With other designs of queued-message-handlers, one can put logic in multiple cases, with each case quite simple ("initialize UI", "Connect to Instrument", "Read Config File", etc.).  I usually have at least 5-10 subcases in initialization.

You can combine a State Machine with a Message Handler in teh same loop, BTW; it's not either/or.

[RTSLVU]

Quite frankly I struggled with the QMH for years and finally abandoned it completely. It really makes absolutely no sense to me. The QMH template is so tightly coupled that even making (IMHO) minor changes, like trying to integrate MY instruments, causes the entire design pattern to fall apart, and I could never get it working again.

I never heard of the DQMH so I can't comment on it.

[billko]

It's Delacor's mightily expanded version of the QMH.

[pjroland1121]

the following comments are in regards to the DQMH (i tend to use it alot).

"The actual area where the code happens (in the event structure and in the case structure is so small relative to the screen that I have really hard time to squeeze in code." this is why subVIs exist.  If you find you need far too many of them, use a hierarchy of subVIs.

If you find the need to do alot of crazy UI updates at various times, pass an array of front panel control references into the Event Handling Structure so all subVIs can have access to the properties for each  (the label.text property lets you make sure you're setting the right one).

Ensure you use the toolkit functions to add/remove new events instead of trying to make them manually (speeds up development).

One of the primary advantages of DQMH over NI-QMH is the reusability of code modules and scalability of projects.  Example I can write a module for each power supply i use in all of my projects.  Need to use one in a new project/machine? just drop in the module and move on to the rest.

You can develop, test, and verify modules for new devices/hardware before event attempting integration into your main VI.  Further, each Module can be given access to data from other modules via dynamic registration of broadcast events (handy for simultaneous handling of a safety events requiring shutdown, siren/warning, logging, UI update, etc. for example).

this NIWeek video may help highlight some things further.  https://delacor.com/tips-and-tricks-for-a-successful-dqmh-based-project/

[1984]

Thanks for all the inputs, they were very useful.