LabVIEW
Is QMH obsolete? Am I wasteing my time?
Solved!
@RTSLVU wrote:
Unlike Queues, Channel Wires follow the standard Data Flow paradigm (Input on the left and output on the right).
Channel wires also break the standard data flow paradigm. Their whole purpose is to transmit data from one loop to another while both loops are still running. You may have a visual connection, but a well written messaging application will have visual cues that could be followed as easily as wires which are running backward on the screen. That's just my take on it.
@RTSLVU wrote:
Also With Channel Wires I don't have to pass the Queue around with shift (NOT bleep) registers and pass it through every single state of my state machine whether I am operating on the Queue or not. If I need to read or write a Channel in that state I do it, if I don't then I can ignore the Channel Wire in that state.
Why would you have to pass the queue around with shift registers? The queue reference doesn't change. I create all of my queues prior to entering the main loops. They do tend to be on a single shift register since they're generally saved in an object with other stuff that may change in the loop, but if the queues were the only thing of interest there is no need for a shift register.
@drjdpowell wrote:
Just a note to any new LabVIEW programmers reading, but I personally would very strongly advise against ever using the NI "QMH"/"Producer Consumer"/"Continuous Measurement and Logging" templates. I would advise against even looking at them. The "JKI State Machine" is a much better design to be introduced to.
I would even (more weakly) warn against the DQMH, due to its use of the NI QMH design internally. Though with the DQMH one can divide a complex application into multiple simpler DQMH modules, which limits the possible problems.
I don't disagree with this. Honestly I'm not even sure what the NI shipping examples look like.
Why would you have to pass the queue around with shift registers? The queue reference doesn't change. I create all of my queues prior to entering the main loops. They do tend to be on a single shift register since they're generally saved in an object with other stuff that may change in the loop, but if the queues were the only thing of interest there is no need for a shift register.
Honestly I have asked myself that same question. But anytime I posted some code like this without those Shift Registers people would come out of the woodwork to tell me I MUST put Shift Registers on the Queue in my loops.
@RTSLVU wrote:
Why would you have to pass the queue around with shift registers? The queue reference doesn't change. I create all of my queues prior to entering the main loops. They do tend to be on a single shift register since they're generally saved in an object with other stuff that may change in the loop, but if the queues were the only thing of interest there is no need for a shift register.
Honestly I have asked myself that same question. But anytime I posted some code like this without those Shift Registers people would come out of the woodwork to tell me I MUST put Shift Registers on the Queue in my loops.
Not sure who was saying this, but in your simple example there is absolutely no need for the shift register. Try it and you will see that it works just fine.
Save your queue references in an action engine/global/whatever and you don't really need queue reference wires anywhere except going from your action engine/global/whatever to the queue functions. (As long as you actually update the action engine/global/whatever after you create it, but before you actually use it.)
I guess shift registers were left over from the shipping examples. I used to keep them in a shift register a long time ago, then I found out it just didn't matter.
Also to consider, and not at all trivial, is that with the plain vanilla QMH, you will greatly increase the chances that some knowledgeable in LabVIEW, especially formally trained, will instantly recognize the pattern and can concentrate on what you coded, not how you coded it.
