Enqueuing Data from the same source to two different Queues

[Amr95]

I am using the Producer/consumer design pattern and I have a loop where Data is being read from sensors, I send this data through a queue to another acquisition loop and in the acquisition loop the data is being enqueued on the logging queue and gets logged in the logging loop.
Now I need to enqueue the data read from the sensors to apply FFT analysis on the signal in a third loop. But in the FFT analysis loop I'm only getting two or 3 samples not the whole data dequeued like in the acquisition loop. Is not possible to enqueue data from the same source on multiple queues? does the data get split or how can I imagine the data flow in that case?

[RavensFan]

Of course!

You obtain two queues.  You take the data from wherever you are getting it.  You split the wire, feeding the same data into the Enqueue Element that is connected to queue 1, and into the Enqueue Element that is connected to queue 2.

As for the problem you are seeing where you are only getting 2 or 3 points of data, you'd have to attach a VI so we can see what you did.

[crossrulz]

A queue is meant for 1 receiver.  If an element gets dequeued in loop 1 and then loop 2 tries to dequeue from the same queue, it will not get the next element in the queue.  In other words, once an element gets dequeued, it is gone from the queue.

If you want to have your data sent to multiple locations, you have 2 options:

1. Use a different queue for each consumer

2. Use User Events.  User Events put the data in each event structure's own event queue, so each consumer will get all of the data.

[johntrich1971]

It is hard to troubleshoot code that we cannot see and probe around in. You will get help much faster if you would post your code (or a minimal working example that shows the problem that you are having). It is certainly possible to send data to as many queues as necessary.

[rwunderl]

Without seeing your code, there is no way to know for sure what your issue really is. However, it sounds like you are enqueueing data at one location and then dequeueing the data at multiple locations. If this is the case, then the data in each destination will be somewhat randomly selected from the single queue. This is not a good thing at all.

Data can easily be enqueued on multiple queues that are bound for different destinations:

Just take care to never dequeue in more than one location per queue.

EDIT: of course people will immediately jump on me for saying this. There are many legitimate reasons for dequeueing in multiple places. But in your specific case, it sounds like you did not intend to do it.

Also consider using a Notifier for any loops that are for display only (as FFTs commonly are) to keep your UI more responsive and prevent a backlog of data building up in the queue (if the processing is CPU intensive). Use queues when you need lossless, contiguous data streams.

[crossrulz]

---

@rwunderl wrote:

EDIT: of course people will immediately jump on me for saying this. There are many legitimate reasons for dequeueing in multiple places. But in your specific case, it sounds like you did not intend to do it.

---

I'm not sure I would say "many", but you are correct in that there are reasons to allow a queue to be dequeued in multiple places.  These are typically to parallelize processing of data.  But it will also require a lot of care when bringing the analysis data back together since you cannot guarantee the order of the data coming out will be the same as the data going in.

[johntrich1971]

---

@crossrulz wrote:

---

@rwunderl wrote:

EDIT: of course people will immediately jump on me for saying this. There are many legitimate reasons for dequeueing in multiple places. But in your specific case, it sounds like you did not intend to do it.

---

I'm not sure I would say "many", but you are correct in that there are reasons to allow a queue to be dequeued in multiple places.  These are typically to parallelize processing of data.  But it will also require a lot of care when bringing the analysis data back together since you cannot guarantee the order of the data coming out will be the same as the data going in.

---

This is not something that I have used (mainly because of the issue with stitching the data back together), but thankfully have not really needed to do so.

[johntrich1971]

---

@rwunderl wrote:

Also consider using a Notifier for any loops that are for display only (as FFTs commonly are) to keep your UI more responsive and prevent a backlog of data building up in the queue (if the processing is CPU intensive). Use queues when you need lossless, contiguous data streams.

---

I sometimes have used a Preview Queue in one loop for UI response when I don't care if I lose data while only dequeuing in the other loop.

[crossrulz]

---

@johntrich1971 wrote:

---

@rwunderl wrote:

Also consider using a Notifier for any loops that are for display only (as FFTs commonly are) to keep your UI more responsive and prevent a backlog of data building up in the queue (if the processing is CPU intensive). Use queues when you need lossless, contiguous data streams.

---

I sometimes have used a Preview Queue in one loop for UI response when I don't care if I lose data while only dequeuing in the other loop.

---

If for a UI, I almost always use a User Event since my indicator updates and user interactions can then all be handled in a single loop (with an Event Structure).

[Amr95]

I actually didn't enqueue the Data on one queue, I enqueued the data on two queues so I can't explain this behaviour.

Here is the source of the Data where it gets enqueued on two queuesHere is the FFT SubVI where the data should get dequeued