queue handling inside a wrapper

[mstoeger]

Dear all,

I'd like to know, if it is possible to "wrap" queue functions inside a VI, that is someting like this "Action Engine" (antipattern probabely?) or store the Queue-Reference inside a FG. In this way it should be more easy to place it in different places/loops and the effort of wiring should be reduced.

Unfortunately, my example does not work ...

All ideas are welcome!

Thank you

Martin

queue.vi

main_queue.vi

[crossrulz]

I do this all the time. You can check out here and here for examples. I was unable to open your VIs (I'm using 8.6), but attached should be an idea of what you want. I use this VI to communicate between threads. One thread reacts to what the other thread sends. But I have several commands that could be sent. So this VI is used to open the queue, send commands, simply get the reference, and close the queue.

Monitor Queue.vi

[mstoeger]

I'll take a look at these sources, here again my problemcase in LV8.6 version --> thank you

Martin

main_queue.vi

queue.vi

[Mark Smith]

I'll take a look at these sources, here again my problemcase in LV8.6 version --> thank you

Martin

main_queue.vi

queue.vi

the problem is that the queue.vi blocks in the read mode (since nothing is on the queue) and it gets a request to read first and there's nothing on the queue. Add a timeout to the read function that's not -1 (wait forever). But I'm not seeing the advantage of this to a standard FGV. If I want to share queues between threads/loops, I use named queues and just get references by name to the queue when I need access. I'm sure there's some overhead, but typically I need to get the ref once and then read many times as some other operation puts data on the queue so the overhead is negligible. If I just wanted to share data between many threads (rather than "stream" data) I'd just use a FGV or a class that behaves like a "by ref"and get the data through an accessor.

Mark

[mstoeger]

The advantage - in my opinion - is:

- queue used as a command-construct does not "lose" elements (a FGV could be more often filled then read-out)

- in this way I hope to get the ability to place the VI on different loops/threads and for example get even multiple previews of queue elements (I haven't done this in the previous attached example).

Well, I think queues are widely usable ....

[Mark Smith]

The advantage - in my opinion - is:

- queue used as a command-construct does not "lose" elements (a FGV could be more often filled then read-out)

- in this way I hope to get the ability to place the VI on different loops/threads and for example get even multiple previews of queue elements (I haven't done this in the previous attached example).

Well, I think queues are widely usable ....

Don't get me wrong - I think queues are one of the most useful and efficient of LabVIEW's data sharing mechanisms. But it still sounds to me like your use case is better suited to a simple collection (a LabVIEW array) rather than a queue. A FGV with an array could hold any number of elements (never gets full till you run out of memory), you could easily "preview" the elements (they are always available, all you have to do is iterate through the array), you can retrieve a single value by index, and you can search or sort the collection. You can do the same thing with a queue but I just don't see the reason for the added complexity.

Mark

[crossrulz]

Maybe the example mstoeger gave is a bad one for this function. In the way I use these functions, my diagrams are a lot cleaner because I don't have to pass the queue reference everywhere (to several loops, into subVIs, through structures, etc.). I only have one reader of the queue. Notice that I do not use my FGV to read the queue, only get the reference. The benefit here over the FGV holding an array is that the reader will just sit there and use no CPU time. With a single reader I could have commands that come from many different sources (user interface, reactions to outside sources, etc.), often not even on the same diagram (different TestStand calls) or many subVIs down. Yes, I could obtain the queue reference by name, but that is a pain to keep track of my queue's name, obtain the queue, send a quick command, and "close" the reference (not destroy since another thread still has it open). My company had a VI that did that and I eventually said "Why not just keep the reference here?" Hence the FGV given above. I noticed a good performance boost, no hard data on it, but I could definitely tell.

[Mark Smith]

Maybe the example mstoeger gave is a bad one for this function. In the way I use these functions, my diagrams are a lot cleaner because I don't have to pass the queue reference everywhere (to several loops, into subVIs, through structures, etc.). I only have one reader of the queue. Notice that I do not use my FGV to read the queue, only get the reference. The benefit here over the FGV holding an array is that the reader will just sit there and use no CPU time. With a single reader I could have commands that come from many different sources (user interface, reactions to outside sources, etc.), often not even on the same diagram (different TestStand calls) or many subVIs down. Yes, I could obtain the queue reference by name, but that is a pain to keep track of my queue's name, obtain the queue, send a quick command, and "close" the reference (not destroy since another thread still has it open). My company had a VI that did that and I eventually said "Why not just keep the reference here?" Hence the FGV given above. I noticed a good performance boost, no hard data on it, but I could definitely tell.

LabVIEW gives us lots of tools that we can use where appropriate. I typically use named queues because I don't often have the same use case you describe where I would open a ref and then enqueue a single argument and then close. More typically, I'll have a VI that will run asynchronously and either produce or consume data. I get the ref to the named queue when the VI starts and then close it when the VI exits. There's a little overhead but it's negligible in the grand scheme of things. I can see where if you just need to grab a quick queue ref and then put a single arg on the queue your method makes sense because there's less overhead per enqueue operation.

Mark

[crossrulz]

LabVIEW gives us lots of tools that we can use where appropriate.

That is the name of the game: which tool is appropriate where? For the application you described, I would probably do something similar as you. By no means is there a single "good" way nor is there a silver bullet for every application (no matter how much we want there to be).

So to answer mstoeger's original question, yes you can save a queue reference in a FGV and it does work well. Is it really want you want to do? Well, that's for you to decide based on your application needs. My experience has been that queues work best with only one reader/consumer. Following that methodology, I would not put your Dequeue Element inside of you FGV if that is the route you want to take.

[ASTDan]

That is the name of the game: which tool is appropriate where? For the application you described, I would probably do something similar as you. By no means is there a single "good" way nor is there a silver bullet for every application (no matter how much we want there to be).

So to answer mstoeger's original question, yes you can save a queue reference in a FGV and it does work well. Is it really want you want to do? Well, that's for you to decide based on your application needs. My experience has been that queues work best with only one reader/consumer. Following that methodology, I would not put your Dequeue Element inside of you FGV if that is the route you want to take.

I put all my queue functions inside a FGV accept the Dequeue.

Edited March 4, 2010 by ASTDan

[mstoeger]

Well, after all what I have read about the theme, I come to following conclusions:

- my example does not work, because I open a reference in the read case, then the queue is blocked

- the timeout of "read from queue" could be set to >1, but then the consumer loop will be executed frequently, even if no element is enqueued

- this could be done also with a FGV that does not store a reference of a queue but the data itself in an array

If the home-brewed solution has the same performance as the prepared element "queue", I don't know.

Thank you all for your interest! If new realization appears - let me know!

Martin