When to use CHM vs QHM

[drjdpowell]

---

@Bob_Schor wrote:

---

@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

---

Message "priority" is duct tape, used to code around other weakness.  You've done a better work around, but only for Errors.    

BTW, another design weakness is handling errors in the wrong place.  Both your error-handling options are symptoms of this.  The better strategy is analogous to a chain of subVIs, which pass the error along to the end of the chain and then handle the error at the calling-code level.  SubVI chains never "continue as if nothing happened" nor trigger an immediate "orderly shutdown".  This is a much more common design problem in queued message handler designs, though, and the "JKI State Machine" (which I actually recommend) has it.

As an example, image a "message case" called "Read Communication settings from file", which throws a parsing error because there is something wrong with the file.  Should you Clear and continue as if nothing happened, or do an "orderly" shutdown?  The answer is you have no idea; at this low level you don't know if the error is fatal or not, nor what you need to do next, because you don't know why this "message" was sent.  Is this a fatal problem on program start?  Or the User accidentally selecting the wrong file, recovered by asking them to select again?  A low-level action like this "message" should never use either of you strategies; it should pass the error along to somewhere that does know what to do with it.

[Bob_Schor]

@drjdpowell:

I agree completely with your comment that one needs to "think what to do" (and design it into the code) when something "unexpected" happens.  My "example" was, indeed, simplistic, but meant to show that the lack of a "Queue at Opposite End" for Channel Wires did not (oh boy, forgive me for this) "preempt" preemtive Error Messages.

Bob Schor

[drjdpowell]

---

@Bob_Schor wrote:

@drjdpowell:

I agree completely with your comment that one needs to "think what to do" (and design it into the code) when something "unexpected" happens.  My "example" was, indeed, simplistic, but meant to show that the lack of a "Queue at Opposite End" for Channel Wires did not (oh boy, forgive me for this) "preempt" preemtive Error Messages.

Bob Schor

---

I think I'm not getting across how bad the "send messages to yourself" design is, nor the (not quite so bad) "clear or shutdown immediately" error-handling strategy.

Added later: a talk I gave on these issues a while ago: https://www.youtube.com/watch?v=pZ8w1AhDApE

[RavensFan]

From a philosophical point of view, is "send messages to yourself" really that bad?

In the real world, don't we all take notes with comments to tell ourselves to do something later on?  Isn't that actually sending a message to yourself?

[crossrulz]

---

@RavensFan wrote:

From a philosophical point of view, is "send messages to yourself" really that bad?

In the real world, don't we all take notes with comments to tell ourselves to do something later on?  Isn't that actually sending a message to yourself?

---

Yeah, but the real world doesn't work as a FIFO.  To correspond to the real world, you would need to use "Get Queue Status", look through the queued elements, and decide which one to use.  I'm not sure how you would then clear that item from the queue.

I've seen it plenty of issues/race conditions when "sending a message to yourself" and a QMH.  Yes, it is best to not do this.

[drjdpowell]

---

@RavensFan wrote:

From a philosophical point of view, is "send messages to yourself" really that bad?

In the real world, don't we all take notes with comments to tell ourselves to do something later on?  Isn't that actually sending a message to yourself?

---

Well, there is a difference between a complete task, and the subactions one does to complete a task.  For example, tomorrow morning I will both "make coffee" and "have a shower"; those are tasks.  Sub Actions include "go to kitchen", "get coffee grounds", "turn on coffee maker", "go to bathroom", "turn on shower", etc.  Sub actions need execution in teh right order; tasks do not.   I can make coffee and take a shower, in any order, but if I try to "go to kitchen", get coffee grounds", "go to bathroom", "turn on coffee maker"... I will get a fatal "no coffeemaker found in bathroom" error.

Also, you tell yourself to do something later because you intend to defer this task and complete other tasks first.  You can have reasons to do that, but I'll bet 99% of messages used in the QMH template are actually just sub-actions queued up, not actual deferred tasks.  Sub-actions are much more common than deferred tasks.

[RavensFan]

What you've written is technically correct, but you've taken a queued message handler and turned it into a similar sounding but different architecture known as a queued state machine.  I know there have been many threads on the topic, and a few recently.

If you those activities were actually done in a computer processor, it is the equivalent of thread switching.  The processor would have no physical issue turning on the shower in one step and turning on the coffee maker in the next step.  The "go to this room part" is never really a true state because the processor does it natively.

It is never inherently wrong by using a queue message handler to send a message to yourself as a reminder to fix the coffee the next morning.  But like any concept, it can be abused when you start overloading it with other concepts (like a queued state machine).  This is a lot like "local or global variables are bad, don't use them".  Of course you can use locals and globals, and of course you can send messages to yourself in a QMH.  But if you use them incorrectly, it will lead to problems like being stuck in the bathroom when you want to turn on the coffee maker.

[drjdpowell]

I think you are making my point.  The NI "QMH" template is a poorly-designed message handler.  Saying "oh, your using it as a QSM" is a bit cruel to the poor junior-level programmer who only used the template in the most intuitive way and is stuck trying to debug weird race conditions.  There are much better QMH designs that are easier to write solid code with, both for beginners and experts. 

[EthanTheHut]

OK now you guys have said something I finally understand. What is one of the better "QMH" template you speak of?

I am that beginner. 

[Bob_Schor]

IMHO, you want to use the simplest system that (a) does what you need it to do for you, (b) you understand, and know how to use, and (c) "fits" with your level of experience and skill.

Having said that, you could take a look at the Delacor Queued Message Handler, a.k.a. the DQMH.  Note that it may be a bit more than you need for right now, but think of it as the QMH on steroids ...

Bob Schor