"Queued Message Handler" loops for asynchronous digital I/O from one piece of hardware

[Carmen92126]

With 2015 LV Base (no PID toolkit available) I would like to make a VI to both control and measure a process and save all data to a file. 

I plan to use the "Queued Message Handler" template. 

My newbie understanding is that I can just add loops for any new parallel process (we might have up to 10). 

But what about coordinating hardware resources? We'll use a USB-6210 for digital I/O and voltage in along with a cDAQ for thermocouple. 

Can different loops access the same hardware simultaneously? 

We can read all temps at the same time, but digital relay on/off timing for cooling, heating and circuit load is asynchronous.

How do we structure a single piece of hardware with four digital outs to switch on and off as dictated by control algorithm? 

Below are options A and B. Loops 3 and 4 are the variants. 

Option A

Loop 0, be the coordinator of all other loops. (producer)

Loop 1, read tempertures (cDAQ)

Loop 2, read Fluke, Keithley, and vacuum valve (VISA)

Loop 3, open/close cooling relay (6210 digital out)

Loop 4, open/close load relay (6210 digital out)

Loop 5, measure voltage (6210 analog in)

Loop 6, etc. 

Option B

Loop 0, be the coordinator of all other loops. (producer)

Loop 1, read tempertures (cDAQ)

Loop 2, read Fluke, Keithley, and vacuum valve (VISA)

Loop 3, open/close relays for cooling and load; read voltage (6210 digital out, analog in)

Loop 4, etc. 

[Kevin_Price · Accepted solution]

---

@Carmen92126 wrote:

Can different loops access the same hardware simultaneously? 

Yes, sometimes.  Generally if all the i/o is going to be accessed via software-timed on-demand tasks, you are free to have multiple simultaneous tasks, each interacting with a distinct subset of available channels.  Your application sounds like one of these situations to me.  Note however that most of my experience is with desktop boards, and sometimes USB boards have additional limitations. 

Provided your board allows for it, I would prefer option A where you have a distinct message handler loop for each logical grouping of device interaction.  I would also suggest you think of Loop 0 as more of a *consumer* than a producer.  (It's also a coordinator).

I've been using a modified QMH approach quite a bit lately and would recommend that you try to avoid having loops 1-N communicate with one another directly.  Let loop 0 coordinate them, receive all their data, and make all the high level decisions.

The QMH template is structured to provide the option for any loop to talk to any other loop, but I've found that debugging and extension are simpler by keeping the communication hierarchical.  A result of this approach is that loop 0 becomes the "main brain" and will usually need to carry a large cluster of "state variable" information about the system.

Some essential concepts to distinguish a Queued Message Handler from a Queued State Machine:

- In a QSM, a case and its code define a state.  States are what get queued up.  A QSM will tend to linger within a state (or loop around to the same state repeatedly).

- In a QMH, action messages get queued up.  Code for a message will execute quickly.  A QMH will tend to linger at the Dequeue function, waiting for a message to act on.  Data is what defines the operating state, usually held in a typedef'ed cluster and stored in a shift register.

-Kevin P

[Carmen92126]

Thanks Kevin!