LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Advantage of Using Cluster with Variant in Queue?

Solved!
Go to solution

Hi,

 

I'm working off the 'Continuous Acquisition and Logging' example with Queued Message Handler pattern.

 

As I'm editing things to fit my project I am trying to figure out why they have their queues as a cluster with a variant data type at the end. I am fairly certain I can make my queues either have numerics for data or type def'd enum for the states of each successive loop and be just fine. 

 

I haven't worked with this design pattern for very long and also have only ever developed LabVIEW applications by myself, for my own research (currently a 4th year PhD student). 

 

Is there a compelling reason to keep the queues using a cluster with a variant at the end instead of changing to single data type? I of course assume there is some good reason, but perhaps not one I need to worry about. I would like to simplify things for future students if possible.

 

Thanks for your insights,

Tom

0 Kudos
Message 1 of 5
(1,351 Views)

You use the variant when you don't know what data you will need to send and/or each message has different data types.  So the typical cluster is a String or Enum to state which message is being sent and then a Variant or String to hold the data for that message.

 

Personally, I use a string instead of the variant and use Flatten To String and Unflatten From String to convert the data back and forth.  For my general QMH library, I actually have a string for the command, a string for the data, and then an error queue reference for passing an error back from the message handler.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 2 of 5
(1,346 Views)

Per your signature, I'll skip the 'thank you'.

 

A clarification on the heavily used word of 'data': When I think of passing data, I am conditioned to think of numeric data that I'm collecting from my DAQ devices. And the state that I want each loop to be in ('Start', 'Do Something Useful', 'Stop') is the 'message'. 

So right now I'm separating the 'messages' from the 'data' in their own queues. Are you saying that it is typical (or maybe preferred?) to use a queue that contains both the 'message' and the 'data'? Or does "real-time" data being collected usually get its own queue? As opposed to data like logging settings or error messages.

 

-TSR

 

0 Kudos
Message 3 of 5
(1,315 Views)

Bundling a "state/command" and a variant is a method to give the programmer more flexibility.

 

For example, assume I have some indicators on the front panel like a plot, a few boolean indicators, a string indicator, and a numeric indicator.

 

In my program I have a loop that contains all of the indicators. To update an indicator I send a command "PlotUpdate" and with a Variant data payload that contains the plot data. For the String Indicator I send a command "StringUpdate" and with a Variant data payload that contains the string data. Here I am using ONE queue, user event, etc, to update multiple, different items. Having too many queues, user events, etc, can get cumbersome for the programmer in my opinion. Using a bundled payload it is easy to add more/different indicators to the front panel rather than having to create a separate queue for each one.

 

If you just want to send a command, then leave the variant data payload empty.

 

These are just generalizations and not written in stone suggestions. For some applications it makes sense to have specific queues.

 

mcduff

Message 4 of 5
(1,282 Views)
Solution
Accepted by topic author tsr26

@tsr26 wrote:

A clarification on the heavily used word of 'data': When I think of passing data, I am conditioned to think of numeric data that I'm collecting from my DAQ devices. And the state that I want each loop to be in ('Start', 'Do Something Useful', 'Stop') is the 'message'. 

So right now I'm separating the 'messages' from the 'data' in their own queues. Are you saying that it is typical (or maybe preferred?) to use a queue that contains both the 'message' and the 'data'? Or does "real-time" data being collected usually get its own queue? As opposed to data like logging settings or error messages.


What the QMH is dealing with is a message that contains the command (Start, Stop, Pause, Shut Down, etc.) and data associated with that command.  For example, you might have a "Collect" command with a double to state how long to collect data for.  Another message might be "Add Channel" with the data being the a string with the channel to add to a task.

 

Now the data coming from the QMH should be a separate queue.  For a DAQ, I tend to use a waveform for the data and that is all that is needed in the queue data.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 5 of 5
(1,276 Views)