LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Advanced LabVIEW training resources?

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.

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 1 of 8
(4,655 Views)

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?

 

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 2 of 8
(4,592 Views)

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

Message 3 of 8
(4,584 Views)

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.

 

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 4 of 8
(4,564 Views)

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.

0 Kudos
Message 5 of 8
(4,538 Views)

@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.



There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 6 of 8
(4,523 Views)

@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.

0 Kudos
Message 7 of 8
(4,517 Views)

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.  

0 Kudos
Message 8 of 8
(4,482 Views)