03-18-2021 03:40 PM
I have been programming LabVIEW for a number of years but there is a lot of things I still do not understand.
Judging by the descriptions the QMH and CMH design patterns would probably be a great starting point for my current project. But I can't get past that starting point. Nothing is documented or explained well enough for me to be able to modify the program template to fit my needs. I make one little change and the whole thing blows up. Leaving me with a bunch of broken wires and no clue as to how to fix it other than going back to the original template.
03-18-2021 07:59 PM
That's kind of a vague description, but I understand why. Care to try to describe what things you change to cause all those broken wires?
03-18-2021 08:32 PM
Personally I hate the QHM. I could never understand it completely. Seemed like a mishmash of things, queues, notifiers, user events, etc. (Never tried the CHM)
I would suggest the JKI state Machine which is a self-contained QMH. The "queue" is a string shift register that stores a sequences of commands. For me at least, it it much easier to visualize, debug, and understand this type of QMH.
Different JKI State Machines can be linked together via user events instead of queues. JKI did have free State Machine training during the pandemic, not sure if it is still available.
mcduff
03-18-2021 11:09 PM - edited 03-18-2021 11:11 PM
Yeah that was kind of vague I guess I don't know enough to even ask a good question.
I am having trouble controlling and passing information between parallel loops.
The examples and training for things like Notifiers, Queues, and Channels make it look simple but I can't scale them up to a working application.
Honestly I have been trying to figure these things out for years but I haven't used a Queue for anything other than a Producer/Consumer and I have never use a Notifier at all.
03-19-2021 03:48 AM
I, also, would strongly recommend the JKI design over the NI templates. I used the JKI for years before developing my own design (developed from the JKI), and I've used the NI templates in talks at conferences to illustrate common flaws in message handlers.
03-19-2021 07:51 AM
@mcduff wrote:
I would suggest the JKI state Machine which is a self-contained QMH. The "queue" is a string shift register that stores a sequences of commands. For me at least, it it much easier to visualize, debug, and understand this type of QMH.
Sorry, but I have to yell at you over semantics (I've been in this fight for a long time). The JKI State Machine is a form of a Queued State Machine (a single loop that enqueues the states it should run). A Queued Message Handler is a separate loop that just reacts to messages sent to it, very similar to a Producer/Consumer. And for those who care, the Actor Framework is an overly OOP centric version of a QMH.
03-19-2021 07:59 AM
@crossrulz wrote:
@mcduff wrote:
I would suggest the JKI state Machine which is a self-contained QMH. The "queue" is a string shift register that stores a sequences of commands. For me at least, it it much easier to visualize, debug, and understand this type of QMH.
Sorry, but I have to yell at you over semantics (I've been in this fight for a long time). The JKI State Machine is a form of a Queued State Machine (a single loop that enqueues the states it should run). A Queued Message Handler is a separate loop that just reacts to messages sent to it, very similar to a Producer/Consumer. And for those who care, the Actor Framework is an overly OOP centric version of a QMH.
No hassles. Thanks for the correction.
03-19-2021 03:27 PM
I would say a QMH is something that handles messages one by one from a queue. So the JKI, which can handle messages via its event structure, is a QMH. Also, you can use the "state queue" of the JKI as an execution stack, in which case it isn't acting as a Queued State Machine.