“asynchronous is best” they say. OK, but do you also need to maintain state on data you’ve requested & waiting for in addition to the internal

[Peter_B]

Thank you for such a helpful reply Darren 👍

Having yourself, a DQMH evangelist chime in, offers a thorough set of counterpoints.   The DQMH consortium might consider paying you for each pro-DQMH comment you write 😉

All the pros you list look solid to me.    One main one doesn't apply in my (small team's) case because we don't write code for other programmers to use.  One person is usually both the author and user of the code.   Thus a project with purely synchronous operations will have extra complexity for the developer in my case.   However the added advantages you listed out will very likely outweigh that extra complexity for medium to large projects, plus it always leaves the door open to run async operations if required in the future. 

Now I think more about this, even the project I thought might have had no async operations actually will now end up having some.   e.g. I might need to convert a blocking operation that waits 6 seconds for a valve to open or close (I know - it is  just slightly larger than the default 5s timeout !).  ,  into a non blocking operation that reports back once the valve has transitioned.  The "trivial" requirement change automatically needs a parallel timer to be triggered (requested) and for the timer to broadcast when the time has elapsed.

In summary,  I can now only envisage my simple quick (sub 1 day effort ?)/experimental/investigative LabVIEW code using a state machine or basic QMH.

Thanks again Darren !

[joerg.hampel]

@Peter_B wrote:

"If every message is a Request and Wait for Reply, then you aren't taking advantage of things being asynchronous and you probably shouldn't be using DQMH because it is adding complication for no real benefit."

---

Wow, that is insightful !   Since recently adopting DQMH, I naively thought it was reasonable to use DQMH for every medium to large sized LabVIEW project I was to undertake from here-on-in (yes I fell for the "everything's now looks like a nail" mindset).   I didn't even consider to avoid DQMH if the project had no async calls in it.  🙄

---

For the sake of posterity, I want to go on the books here and say that I like DQMH for being such a great hammer - we can make almost anything look like a nail. How great is that?

I believe it's fair to say that our team is extremely proficient using DQMH. We can solve (almost?) any requirement in an efficient and effective way. That is due to the fact that we focus our energy on this single tool. To me, that is a huge business advantage. I wrote about it here. I would *not* want my team to use different architectures and templates on the assumption that a problem is "too small for a proper DQMH module". That almost always turns out to be a false assumption in the end, anyhow. 

Darren listed many arguments in favor of using DQMH even if asynchronous processes are not required at the moment. For me, the most important one is consistency across all team members and projects. And even if a team doesn't usually exchange code or take over each others' projects, one can focus all energy on creating tools, processes and libraries around the same, single common denomintator, thus removing any ambiguity.

Oh, and as for paying for positive comments... we wouldn't really want to do that, now, would we? 😉

[Ozfarmboy]

---

@Darren wrote:

...

---

But then for almost every serial instrument I've worked with, I end up writing an instrument manager, and that manager is a DQMH module. Even if every single command to the instrument is command+response (i.e. synchronous operations), I'll still use a DQMH module. Why?

Because async operations are not the only benefit of DQMH. You get:

1. A tester VI to be able to test your code in isolation.

2. Scripting tools to take care of framework-level scaffolding code so you never have to touch it.

3. Code that starts when you tell it to start and stops when you tell it to stop.

4. Basic debugging tools like showing/hiding panels, showing diagrams, broadcasting errors, etc.

5. The ability to spawn multiple instances of the (cloneable) module.

...

On top of those innate benefits of DQMH, the use of a DQMH module to manage the instrument gives me the ability to add async functionality if necessary. A couple of real-world examples that I've encountered:

1. Helper loop to process streaming data from the instrument.

2. Managing the connection to the instrument, and trying reconnects if the reference goes bad... Reconnects that can be seamless to the end user (since the DQMH module is managing the connection).

3. Registering for broadcasts from other code... for example, a lower-level E-stop module that could broadcast out to all listeners to shut down instruments in an emergency situation.

And to add to Darren's reasons, I have written up a further 8 here: 8 Reasons for encapsulating your next LabVIEW device driver inside a DQMH® Module – Wired-In Softwar...

[Peter_B]

---

@joerg.hampel wrote:

I like DQMH for being such a great hammer - we can make almost anything look like a nail. How great is that?

I like that way of looking at it 🙂   

I think you, Darren and Chris have managed to convince me to remain a (new) convert to DQMH. You might have even convinced me to use it for even the smallest of projects. To that end as I was developing my latest project I kept in mind I would focus on learning DQMH and familiarising myself with the barest bones I needed to start something new (in this case specifically using the RPi as the target for this and other applications using the RPi) and then I branched off and coded for the specific project I need to deliver next at work.

Thanks Joerg !

[Peter_B]

Thank you Chris !

[Olivier-JOURDAN]

I can't agree more with @Darren.

Creating a DQMH module makes the test of your code way more straightforward than using a basic QMH. And it also makes it easier to add features. And it standardizes your code. And more and more.

Having "multiple parallel modules talking to each other" is definitely not the only situation where DQMH is a good fit.

You can use it for all your apps regardless of their sizes. If you encounter a situation that is not the right fit, remember you still can mix its use with other ways to communicate.