LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Question about Queues

Solved!
Go to solution

I have several State Machines that grab data from instruments and write it to Action engines (as a cluster of data, timestamp, state, etc.). I then use Action engines throughout my application to analyze and display that data. There are several "subapplications" such as calibration, monitoring etc. only one of which runs at a time.

 

Would it make sense to create named queues to pass my data around, instead of AEs? Flush the queue upon entry to subapplication, so you only have fresh data and then work on it.

0 Kudos
Message 1 of 9
(1,560 Views)
Solution
Accepted by AeroSoul

Both named queues and FGV are globals.

 

They can be convenient because they do their job, until they are inconvenient because they do their job.

 

So lets say you make a DUT test with globals. Everything's fine. Now you want to test two DUTs simultaneous... Big problem. All named resources need to be indexed, and so do the FGVs.

 

Let's extend this to modules... You have a library that expects a named queue. Now you want to use the library twice...

 

Name collisions are not as rare as you'd expect. I've seen one library using the callers name (minus .vi) collide with a library that used Main as a queue name...

 

A FGV can be used at all levels of the application, and will unless you're very careful with them. This couples everything very tightly to the FGV.

 

That wasn't the question though.

 

I would prefer named queues over FGV. Simply because with named queues you usually get the queue once, and pass the wire. So at least most of the code is by wire. A reference wire, but wire nonetheless. This makes the problem easier to fix.

 

But if you do that (init once, pass the wire), it's little more effort to simply use an unnamed queue and pass it.

 

Some are very happy with using FGV and named queues. In some situations scaling up just isn't a concern. I guess.

Message 2 of 9
(1,522 Views)
Solution
Accepted by AeroSoul

If you're planning to flush your queues regularly, it probably means that you don't actually want queue-like behavior.  Maybe a Notifier?  A Notifier is pretty analogous to an FGV, but with some useful event-like capabilities like signaling and timeouts.   Neither Notifiers or Queues are a suitable direct substitute for a function-rich Action Engine.

 

One very general thing to keep in mind if you move away from AE's and FGV's toward signaling methods like Queues and Notifiers:

    You'll want to start adopting a new mindset.  I think of it as the difference between pull and push.  With FGV's, I structured my code around the idea that *consumers* of data can just pull it from the FGV whenever they feel like it.  With Queues, I structure my code around the idea that *producers* of data should push it out to subscribers whenever there's a relevant data update.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 3 of 9
(1,496 Views)

Yeah i don't think Queues are exactly appropriate for what i'm doing, mostly because producer can be faster than consumer and then there'd be backup of old data, that's why i mentioned flushing.

 

I think i'll stay with AEs for now, thank you both.

0 Kudos
Message 4 of 9
(1,458 Views)

@AeroSoul wrote:

Yeah i don't think Queues are exactly appropriate for what i'm doing, mostly because producer can be faster than consumer and then there'd be backup of old data, that's why i mentioned flushing.

 

I think i'll stay with AEs for now, thank you both.


If you're only interested in the last element, queues can be used.

 

Use a single element queue.

 

Create the queue, but limit the size to 1.

 

Enqueue elements as always.

 

Either dequeue the element, or preview the element. Dequeue-ing will give a time out or the last element. Previewing will give the last element. Previewing also enables 1-many communication. If none of the consumers actually consume the element, it will simply be available to all consumers. 

0 Kudos
Message 5 of 9
(1,436 Views)

wiebe@CARYA wrote:

If you're only interested in the last element, queues can be used.

 

Use a single element queue.

 

Create the queue, but limit the size to 1.

 

Enqueue elements as always.

 

Either dequeue the element, or preview the element. Dequeue-ing will give a time out or the last element. Previewing will give the last element. Previewing also enables 1-many communication. If none of the consumers actually consume the element, it will simply be available to all consumers. 


Seems like you might as well just use a Notifier at that point.


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
0 Kudos
Message 6 of 9
(1,384 Views)

@crossrulz wrote:

wiebe@CARYA wrote:

If you're only interested in the last element, queues can be used.

 

Use a single element queue.

 

Create the queue, but limit the size to 1.

 

Enqueue elements as always.

 

Either dequeue the element, or preview the element. Dequeue-ing will give a time out or the last element. Previewing will give the last element. Previewing also enables 1-many communication. If none of the consumers actually consume the element, it will simply be available to all consumers. 


Seems like you might as well just use a Notifier at that point.


I understand queues better then notifiers. Probably just because I've used them more. So I'd go for a queue by default.

 

The 1-many functionality is neat though, so is the Wait on Notification From Multiple. That's hard to do with multiple queues. 

0 Kudos
Message 7 of 9
(1,379 Views)

@AeroSoul wrote:

Yeah i don't think Queues are exactly appropriate for what i'm doing, mostly because producer can be faster than consumer and then there'd be backup of old data, that's why i mentioned flushing.

 


Um... Yeah, that's kind of the point of using a Queue... 

 

FGV's and AE's <> Queues  

 

Is any one better than the other? Yes, No... Maybe..

 

It's really a matter of choosing the right tool for the job.

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 8 of 9
(1,359 Views)

@RTSLVU wrote:

@AeroSoul wrote:

Yeah i don't think Queues are exactly appropriate for what i'm doing, mostly because producer can be faster than consumer and then there'd be backup of old data, that's why i mentioned flushing.

 


Um... Yeah, that's kind of the point of using a Queue... 

 

FGV's and AE's <> Queues  

 

Is any one better than the other? Yes, No... Maybe..

 

It's really a matter of choosing the right tool for the job.


You can throw user events in the mix as well.

 

All these can 'solve' distribution of data.

 

I still prefer to prevent this altogether. My data lives in a class, and stays there. If the object is needed elsewhere, I send it with a user event or sometimes a queue.

0 Kudos
Message 9 of 9
(1,304 Views)