When to use CHM vs QHM

[EthanTheHut]

I have just finished Core 2 and I am excited about using message handlers with producer consumer loops.  I want to know why I would use a QMH instead of a CMH. They both seem to do the same thing. If you look at the documentation in the templates, they both have the exact same text with the exception of when they use QHM or CHM. 

I think I understand the difference (for the most part) but I want to know the advantages of one over another. In the lesson it talked about the ability to broadcast in the CHM vs not being able to do that in the QHM. Not sure exactly what that means. 

[drjdpowell]

What does CMH stand for?  I am not familiar with the term.

[EthanTheHut]

Channeled Message Handler (CMH)  Queued Message Handler (QMH)

There is a NI template for both CMH and QMH

Sorry I kept typing MH backwards, lol

[Bob_Schor · Accepted solution]

I have been using (and may have invented the name CMH) since LabVIEW 2016 (and I'm pretty sure before that Template was invented).  It is probably the most heavily-used design pattern in my current code portfolio.  I have found a few places where Channel Wires "go awry" (for some reason, they don't play well, for me, in the myRIO Software Toolkit), so I also fall back on the QMH (but without the template).

For me, the advantage of the CMH over the QMH is mainly in the clarity of the mnemonics -- data flows (to the right) out of Channel Writers, and comes in (on the left) to Channel Readers.  This encourages you to place the "Next Message" VI near the right (output) edge of the CMH Loop and "show" the data flowing out, and maybe around to come back in on the input side for the next pass through the Message-handling Loop.  I also have taken advantage of branching the Message Channel Wire.

Bob Schor

P.S. -- if you like the CMH, and know the Producer/Consumer Design Pattern, please use the Stream Channel Wire to send data from Producer to Consumer.  Its "last element?" and "valid element?" terminals provide a clean (and logical) way to implement a Sentinel to allow the Producer (who knows what data are coming in, and when the data stream has stopped) to tell the Consumer that no more data are coming, while leaving the commuunication channel intact (meaning not "releasing the Queue").  The Producer simply sends "last element?" = True (often with Valid Element = False) and exits.  The Consumer simply wires "last element" to its Stop indicator (and possibly uses "Valid element" to process, or not, the last, possibly null, data element) and exit in its turn, knowing that the Producer won't be sending more data.

BS

[EthanTheHut]

Thank you for the detailed response and the continued learning it contains!  

[Bob_Schor]

Always a pleasure to discuss Channel Wires ...

Bob Schor

[drjdpowell]

---

@Bob_Schor wrote:

For me, the advantage of the CMH over the QMH is mainly in the clarity of the mnemonics -- data flows (to the right) out of Channel Writers, and comes in (on the left) to Channel Readers.  This encourages you to place the "Next Message" VI near the right (output) edge of the CMH Loop and "show" the data flowing out, and maybe around to come back in on the input side for the next pass through the Message-handling Loop. 

---

Ah, so CMH is just the NI QMH template with channel wires.  Clarity and easy reading of code is always a major plus.  I actually strongly dislike the NI QMH design, for reasons that channel wires make more obvious.  I can clearly see the "Next Message" actions (and errors, I see) fed back into the incoming message channel (perhaps the largest flaw in the design), in a way that is much less clear in the original Queue-based template.

[EthanTheHut]

Can you explain what you mean by  "Next Message" actions (and errors, I see) fed back into the incoming message channel?

[drjdpowell]

---

@EthanTheHut wrote:

Can you explain what you mean by  "Next Message" actions (and errors, I see) fed back into the incoming message channel?

---

I mean like the "Update Display" message shown in your image.  Even though they include a warning to do all Initialization in that case, they immediately break their own rule and do update display via a message placed on the back of the Queue, meaning some other message (or several) could be handled ahead of it.  If "Update Display" does something that those other messages need, then that is a race-condition bug.

[Bob_Schor]

---

@drjdpowell wrote:

---

@EthanTheHut wrote:

Can you explain what you mean by  "Next Message" actions (and errors, I see) fed back into the incoming message channel?

---

I mean like the "Update Display" message shown in your image.  Even though they include a warning to do all Initialization in that case, they immediately break their own rule and do update display via a message placed on the back of the Queue, meaning some other message (or several) could be handled ahead of it.  If "Update Display" does something that those other messages need, then that is a race-condition bug.

---

I remember specifically asking how to register a "priority Message" (like an Error) using a Channel Wire, and was told it was designed to forbid this.  So I found a work-around that allows me to (a) trap Errors that occur in any particular "Message Case", (b) pass this (along with the intended "Next Case") to an "Error Received" Message Case, (c) decide if this is a "Clear Error, log, and continue as if nothing happened" (or "non-fatal" Error), or (d) Clear Error, log, and start the orderly shutdown of the Program or Code Section.  Not too difficult, and so much more orderly ...

Bob "Channel Wire Enthusiast" Schor