Error handling in QMH projects with multiple error sources

[joptimus]

---

@Sam_Sharp wrote:

Yes, you would end up having 5 queues. One for each instrument and one for your 'main' state machine. Your main state machine enqueues to the instruments for controlling them, and the instruments can enqueue to the main state machine for reporting errors, passing data etc.

---

I have to ask since I read up more on architectures today:

People seem to advise against multiple consumers on one queue (apparently to make sure the consumer gets all packets and doesn't miss one that is dequeued by another consumer). Is that really a problem?

I think having 4 queues (main state machine to consumers) + 4 queues back is not very efficient and clutters the block diagram.

I'm beginning to think I may have chosen the wrong architecture for my application...

Producer: different "programs" that not always use the same instruments. One may use 3 of 4, the other only 1 of 4

Consumer: different instruments that each have their own set of commands and communication parameters, currently bundled in clusters.

I know how to use variants to pass different data types via a queue. But how do I pass different clusters (Cluster A with 3 boolean, 1 enum, 3 numbers. Cluster B with 5 boolean, 1 enum, no numbers etc.)?

I have attached the parameters of two instruments as a screenshot.

[Sam_Sharp · Accepted solution]

I said you will have 5 queues, not 8. One for each QMH (i.e. main and 4 instruments)

Each queue only gets dequeued in one place but you can enqueue to the queues from anywhere in the application. To tidy things up on the block diagram, you can bundle the queue references into a cluster on the top level and then just unbundle the queue you need when you enqueue something. This is what happens in the QMH template projects.

There are situations where you want to dequeue in multiple places for a single enqueuer but it's quite rare - for example if you were trying to batch process data. Think of it like a queue at a bank - you have multiple counters but you everyone joins the same queue and when there is a counter free, you go to that one.

Your last comment isn't clear - you can use variants to pass any type of data (by flattening to a variant when you enqueue and unflattening when you dequeue) into a queue/subVI etc. If you want a more 'strictly-typed' queue (e.g. for streaming data), then just make the queue of that data type (e.g. a double). Again, if you look at the QMH examples, they normally use a string 'command' and a variant 'data' - you convert the variant to the data type that fits the command inside the case for that command.

[joptimus]

---

@Sam_Sharp wrote:

I said you will have 5 queues, not 8. One for each QMH (i.e. main and 4 instruments)

Each queue only gets dequeued in one place but you can enqueue to the queues from anywhere in the application. To tidy things up on the block diagram, you can bundle the queue references into a cluster on the top level and then just unbundle the queue you need when you enqueue something. This is what happens in the QMH template projects.

There are situations where you want to dequeue in multiple places for a single enqueuer but it's quite rare - for example if you were trying to batch process data. Think of it like a queue at a bank - you have multiple counters but you everyone joins the same queue and when there is a counter free, you go to that one.

Your last comment isn't clear - you can use variants to pass any type of data (by flattening to a variant when you enqueue and unflattening when you dequeue) into a queue/subVI etc. If you want a more 'strictly-typed' queue (e.g. for streaming data), then just make the queue of that data type (e.g. a double). Again, if you look at the QMH examples, they normally use a string 'command' and a variant 'data' - you convert the variant to the data type that fits the command inside the case for that command.

---

Then I understood you wrong. This is what it should be, then:

Each instrument has its own queue that is dequeued in the respective subvi only.

But in contrast, there only is one queue that transports errors back up to the main program. Each instrument can enqueue there but only the main program can dequeue.

My last comment was based on the (wrong) assumption I would have to use one single queue to send commands to all my instruments. Still (just to understand this), if you transport two different clusters (size and contents) in a single queue, how do you unflatten them and tell them apart? Both are clusters - the same data type - after all.

[RavensFan]

Technically, there is no such datatype as "cluster".  Each cluster is it's own datatype defined by what's in it.  That's why the wire breaks when you connect it from a control of one cluster of a given definition, to an indicator of one cluster with a different definition.

With variants, it can take in any kind of data type.  You can also send along another value such as an enum that can tell information about the data that was packed into a variant.  So you can queue up a cluster that contains an enum set for "Log Array" and a variant that you pack that array into.  The receiving end know its an arry based on teh enum you gave it.  So in a case structure tied to that enum, you can do a Variant to Data to get the array back out.  A different command might be "Log Boolean",  That enum goes into the cluster along with the boolean that gets turned into a variant.  The receiving end know its a boolean in there because of the command, so that event case runs and turns the variant back into a boolean.

A vary basic queued message handler consists of a cluster that is either enum and variant, or perhaps a string and a variant.  Some people prefer strings like the JKI state machine.  Some people such as myself prefer typedefed enums.

[joptimus]

Thanks you guys, that helped me alot!