Is QMH obsolete? Am I wasteing my time?

[drjdpowell]

---

@joerg.hampel wrote:

---

But I will say this: Another great thing about DQMH is that you can actually implement these things if you'd like! 

---

An experiment, modifying the "Settings Editor" you showed.  Tested with your Tester, and works.

[FabiolaDelaCueva]

---

@drjdpowell wrote:

---

@joerg.hampel wrote:

---

But I will say this: Another great thing about DQMH is that you can actually implement these things if you'd like! 

---

An experiment, modifying the "Settings Editor" you showed.  Tested with your Tester, and works.

---

Dear Dr. James Powell,

It was about time you created your very own Dr James Powell DQMH module! It only took you 10 years or so 😉 

Now you can create your own DJP DQMH template and even distribute it as a VIPM package that depends on DQMH and your Messenger library. This is another way to introduce others to your way of programming.

This is a good example of how when we created DQMH it was more important for us to improve DX (Developer Experience) than being right, or being the only answer to everyone's problems out there.

I have successfully developed architectures with two loops, one loop, DQMH, NI QMH, TLB, TLB', the JKI State Machine, and others. The important thing is understanding how each architecture works, its pros, its cons, and what is the programming paradigm is for each. As Sam suggested, I went on how we took the NI QMH and made it better with DQMH in my presentation about the Decisions Behind the Design. Inserted below for your enjoyment and entertainment.

Happy wiring!

Fab

[drjdpowell]

Notes on my experiment:

• This require Messenger Library, but only for the "Action Stack" I am using for the subactions (handled at right).  One could easily copy these, as they are a very small pair of subVIs, breaking any Messenger Library dependance.
• I split the "Initialize" case into three, much clearer, parts, to show the fact that I can call multiple cases atomically.  Not shown is that I can also have one subaction "Call" another subaction and have that occur next (and atomically).  This is because I am using a private action stack, rather than the public message queue, to sequence my subactions.  
• This eliminates all the "repackage all the data from an Event into a matching Message" boilerplate, as the Event Structure has full access to the State Data cluster and can actually fully handle events
• No Helper loop in this example, but if you had one, you would use a User Event to talk to the Event Structure.
• I manually added an initializing User Event.  But to prevent any race condition, the actual DQMH subVI creating the Events for this Module should create this Event, and ensure the Initialization event is the very first Event sent to the Module.  

[CyGa]

Hi Dr Powell,

Very interesting rewrite!

Here are few questions that came to my mind looking at the block diagram upper :

1. Can't the JKI SM as a queue? I mean you fill a string with several actions. That string is parsed, and actions played one after the other... Looks like a QMH to me but with low control on the 'enqueued' messages

2. Isn't it prone to typos ? I've always reluctant at using a string-based Case because of that. Before using DQMH I was using enums just for that. Since the DQMH scripts the case creation for you, at the typo is identical everywhere and I can't accidentally fall in the default case.

3. How do I launch a new module or handle quick actions in that architecture? Do I have to wait until the SM loops finishes treating all the current SM steps?

PS: These are real questions, not any form of hidden criticism.

[drjdpowell]

---

@CyGa wrote:

1. Can't the JKI SM act as as a queue? I mean you fill a string with several actions. That string is parsed, and actions played one after the other... Looks like a QMH to me but with low control on the 'enqueued' messages

---

The "Action Stack" is actually the same as JKI's "State Queue" (I stole it from them).  One of my "Do's and Don'ts" for using the JKI was to always place on the front off the "Queue", so I redid the API to favour Stack use.  The difference comes up only when one adds actions to a non-empty Stack/Queue (which doesn't happen in my example, but uses this subVI:

---

@CyGa wrote:

2. Isn't it prone to typos ? I've always reluctant at using a string-based Case because of that. Before using DQMH I was using enums just for that. Since the DQMH scripts the case creation for you, at the typo is identical everywhere and I can't accidentally fall in the default case.

---

There is a special tool built in to LabVIEW called "Copy and Paste".  Also, the default case will give you an error causing you to fix your mistake.  The race condition bugs that the "NI QMH" template can easily generate are much worse, as they can be rare enough to not show up in testing.  Don't worry about spelling errors; they are a minor nuisance.  

---

@CyGa wrote:

3. How do I launch a new module or handle quick actions in that architecture? Do I have to wait until the SM loops finishes treating all the current SM steps?

---

That is not a State Machine; those are not States, they are actions.  And they are not "Steps"; they are really (usually fast) subactions of one Atomic event/message handling.  How to do long-running multi-step processes that can be altered/interrupted is a big subject, but it will always involve some kind of a "job queue" or "list of steps to do".  People try and use their message queues to do double-duty as job queues and that causes all sorts of problems.  

[CyGa]

Interesting !

I'll take a look at all that to better understand all the these concepts.

But quickly I can see that there are some Do's and Dont's even with this architecture ; and thanks for the 'copy and Paste', didn't know that feature 😉

[drjdpowell]

---

@CyGa wrote:

But quickly I can see that there are some Do's and Dont's even with this architecture ; and thanks for the 'copy and Paste', didn't know that feature 😉

---

Oh, there is no end of stuff to learn.  That's why I did not understand the "if we give them better tools, how will they learn anything" argument for keeping the flaws of the NI-QMH.  Give them simpler, better tools, and they can spend their learning on something more valuable.

[garthenar]

---

@billko wrote:

I hope more people comment on the topic.  I'd like you you to get a better sample size.

---

I.... My God. Things got busy on my end (school starting, chaos at work, etc.), I came back and there are 77 total posts.  I swore I wrote another post but I must have been so worn out that I just thought I did.

.@everyone

I apologize for not getting back here sooner. I'm currently reading through all 77 posts and continuing my research. I'm going to be discussing some of the concepts I've been/am/will be working on with my professors and adapting my plans according to my coursework.

I know @everyone doesn't work but I couldn't figure that out / find an answer

[styrum]

The main flaw of QMH ("command") pattern and all its derivatives including DQMH, Actor Framework, and all similar "queued state machine" patterns/architectures is the failure to separate notions of event/message, (re)action to event/message and state. Please look up what Mealy state machine is already and how it differs from Moore. Just make a separate queue for events/messages and don't read from it until the main(actions) queue is empty (Run-to-Completion principle). Then when you do get to reading from the events queue select the actions to be run as a reaction to that event depending not only on the event itself but also on the current state and enqueue those actions (their string names or enum values) into the main "handling" queue. You can also select/assign the next state right there or let some action change it. But state is not the same as actions! In a discrete event (and discrete state) system  State by its nature is some (set of) information (variables) depending on the value(s) of which the reaction/transition (actions to run and next state) may vary even for the same input (event, message) received.  You may also want to have yet another queue for external messages, which may or may not (unknown or non-public message, unauthorized sender) become events for the module in addition to the events it generates itself. Also note that the entire information about the behavior of your... module (when event E1 happens and we are in State S1 we want  to run actions A2, A4; when  event E2 happens and we are in state S3....) is just that, a bunch of structured information and, hence, can be stored in a data structure separate from the "code" itself.... 17 years ago, long before LVOOP, Statechart toolkit, let alone AF,  DQMH and all the JKI state machines I made LabHSM (labhsm.com) and EDQSM  (https://forums.ni.com/t5/Reference-Design-Content/Event-Driven-Queued-State-Machine-EDQSM/ta-p/38419...) I can't believe that in 2021 the community still clings to this single queued pattern in various forms long after its fundamental ... deficiencies have been explained so many times by so many people including Dr. Powell (drdjpowell) right here, on this thread (he did it before too, several times at least).

[styrum]

If somebody still doesn't understand the fundamental QMH flaw please play with the attached QMH project which is only a slight modification of the template that still ships with LabVIEW (2020)!