QMH, data queue, and multiple data sources.

[ThomasMK]

Hello.

I've used LabVIEW for several years now, but always stuck to simple architectures. Recently though I came to a conclusion that the complexity of the project I'm working on will require something more robust than simple while loops ;). So I decided to use a Queued Message Handler structure. More specifically, I based my code heavily on the sample project "Continuous Measurement and Logging" that uses QMH template (supplied with LabVIEW 2012).

The difference is that I'm using multiple subVIs for data sources, as they require different modes of communication (USB, COM, ModBUS). So if in the abovementioned sample project you have single "Acquisition Message Loop", I inserted multiple subVIs there, for each data source (e.g. DAQ, spectrometer, optical power meter, etc).
I defined my data queue (one large cluster for all data from all devices), and I thought I could enqueue acquired data in each of these subVIs into one Data Queue, but this doesn't work the way I expected. If I enqueue data in one of the message handler loops, then the other fields are empty (because another subVI is responsible to fill them with data), this way each element in data queue is only partially filled.
Should I implement multiple data queues? One for each hardware-specific message handling loop? Or is there another solution?
Thanks in advance.
Thomas

[crossrulz]

---

@ThomasMK wrote:

Should I implement multiple data queues? One for each hardware-specific message handling loop? Or is there another solution?

---

The simple answer here is to use multiple queues, one for each loop.  This allows specific commands to be sent to specific equipment.

An alternative is to use User Events, which work as a broadcasted queue.  This will deviate from the template quite a bit (changing from a queue and case structure to an Event Structure), but this can work very well.

But as always, which solution is better depends on your exact requirements.

[drjdpowell]

---

@ThomasMK wrote:

Should I implement multiple data queues? One for each hardware-specific message handling loop? Or is there another solution?
Thanks in advance.

---

You could eliminate the dedicated Data Queues altogether and send data via the Message Queues.  Messages can contain data in a Variant, so they can handle many different data types.

[James.M]

Take a look at the CLA practice exam solution here for the ATM Machine. This architecture uses an event structure loop and message handler (dequeue) loop for each "module" of the code. The event structure is only used to stop the module in some instances and used as a user interface in others. The message handler queues are manipulated using VIs that they call "API", which each enqueue a different message command. The API VIs force the developer to only use a specific datatype when enqueueing with a specific command.

You can use an architecture like the above example to create a very scaleable application. Each instrument can be its own "module" and is forced to have its own set of APIs. I've created multiple applications using a similar architecture, but with the added functionality of LVOOP. It can get a little confusing if you're not used to using a lot of subVIs, but it makes it much easier to alter your code and debug.

tl;dr: One queue for each "module" of your code, you can divy up your modules how you'd like. API VIs control the messages between modules.

[Bob_Schor]

As is usually the case, I'm in complete agreement with Crossrulz.  I recently completely redid a large LabVIEW RT project that collects data from multiple pieces of equipment while running a behavioral experiment requiring the delivery of specific (light and sound) stimuli at precise (millisecond) timing.  I use the QMH as my "controller", for Front Panel interactions with the Operator and "broad strokes" interaction between Host and Remote (for example, Host sends Remote a "Start Trial" Message, and Remote sends Host a "Finish Trial" Message at the beginning and end of a Trial).  Data flow within the Host (and within the Remote), for example collecting Analog streamed data from Network Streams and sending it to both the Disk and a (decimated) sample to a Chart display, is done with individual Producer/Consumer Queues (there are about a dozen Queues all together, counting both Host and Remote routines).

Bob Schor