LabVIEW
Expanding my Architecture Horizons
Since I started learning LabVIEW almost 3 years ago, I feel like I've both come a long way and, at the same time, not very far at all. I've gotten into the habit of using an architecture that, while easy to use and familiar to me, is starting to feel pretty limiting. My top-level VI is always a single producer-consumer, with maybe one more loop to detect barcode scans. I can press the "New Test" button to get into the test VI, which is also a PCQSM with a barcode scanning loop. Same with the "Add New Spec" button. Specifically, I've run into issues a couple times now where I want to poll a DAQ pretty quickly but I also need to poll/command the motor which slows down the DAQ polling. Because it's all happening in the consumer loop of my test VI.
What I want to start getting familiar with, is a multi-queue architecture where there is a cluster of queues: "UI to Controller, Controller to UI, DAQ to Controller, Controller to DAQ, DB to Controller, Controller to DB..." etc. The top-level VI essentially consists of a VI that inits all the queues, and brings the cluster of queues into a controller VI, UI VI, DAQ VI, DB VI, etc.
I've looked through the training resources and I did find a sample CLA exam (elevator) that is essentially what I want to start doing, but it's just a skeleton so it's hard to learn from it. It also puts the queues into an FGV and reads them in each component VI.
So I'm wondering if anyone has any good resources or example projects that use this, or has any input on any possible cons of this architecture, or an even better architecture that I should learn over this one. I really appreciate any input you all have. Essentially, I'm coding at a CLD level right now, and I really want to get the hang of coding at a CLA level.
@Kevin_Price wrote:
I'd recommend you read up on, and check out the project template for the Queued Message Handler. That's what I see in your first diagram - a central main Controller loop and several other distinct loops operating in parallel.
One other bit of advice based on your text: each loop should have just 1 queue on which it receives messages. This comes naturally for all the subservient loops, but all of them should respond back to the controller on one same queue. It's then up to your message ID's and your controller logic to manage this inflow and prevent chaos. (Expect to have a sizeable typedef'ed cluster passing through all your controller's message cases as storage for incoming data and "state of operation" info.)
We were pretty invested in our own customized variation of QMH before I learned of the DQMH, but the DQMH is likely an even better place to start from. I just can't speak to any particulars.
-Kevin P
About each loop having only 1 queue: once I started actually started making something small but functional I realized that as well. Can't have one loop pulling from multiple queues without things getting dirty.
I definitely want to look into DQMH as that looks pretty powerful, thanks for the advice!
@Gregory wrote:
One problem with that kind of architecture is that you need 2, if not all 5, components running in order to test and debug your application. I'd look into something like the Delacor QMH, or JKI state machine objects. Those use dynamic events to communicate which are more flexible. The event can registered for and acted upon by 4 event structures all in different components, or by none. This makes for an easy way to test components, and it's also very easy to handle events triggered by front panel actions or by dynamic events.
Yeah that could definitely cause a problem when I want to debug a single component at a time. I've kind of looked at DQMH and it looked like a lot, but very powerful. Only heard of JKI SMOs, haven't looked at them at all. I'll check them out too. Thanks!
@drjdpowell wrote:
There are several architectural frameworks that people have developed. DQMH is perhaps the most widely used one and is a good place for you to start. My own, "Messenger Library" is documented in a set of videos: https://youtube.com/playlist?list=PL5AulxutFbdjFzxb-Lr6HItKR_2sG2aFA
Awesome, I'll look at your library as well. I was also looking into Actor Framework and saw this diagram by MGI, looks very much like what I want to do but AF seems like a whole lot...
