Best architecture to stream multiple instruments in the background?

[Gregory]

This has all been very helpful. It worked well to make a "core" VI which was the actual FGV, and then wrappers to access the different cases of it.

Now, do I need a separate core (FGV) for each queue, or have people found better ways around it? I was thinking about saving the queues as an array (assuming all the message types are the same), then I could roll all of the "Init Queue" and "Release Queue" VIs into a single VI, but I would still need a wrapper with the index of the queue I want to access. Here is my current folder structure:

[crossrulz]

If they are all the same data type, you could just use a single AE with an array of queues.  I would then recommend using an enum on your wrapper VIs to tell the AE which queue to send the data one.

[drjdpowell]

---

@Gregory wrote:

It seems to work, but it gets a little cumbersome with 3, 4, or more instruments. Can you please suggest a more elegant way to do this, or is this a good way to do it?

---

If it is just the Queue wires you are worried about you can just bundle them in a (named-element) cluster, run the cluster wire into the main loop and down to the instrument loops, and use unbundle by name everywhere.

BTW> don't use "named" Queues unless you actually mean to access them by name elsewhere.

[Vasilich2004]

I made such program ~10 years ago ...

1. Create stream VI.

VI's inputs are stream info, Queue, command reference (pause, resume, quit). VI has 2 loops - event for command and loop for stream. If streams should work in parallel you must use reenterable VI (see VI property) and debugging is bad.

Active Engine works but it doesn't look good.

2. Main VI reads ini or xml file which has info about N streams, launches N stream VIs asynchronicly. Main VI also has controls to control stream VIs but it is your prefernce how to make User Interface.

Of course, you should be careful with sychronization, close Queues, etc.

[Gregory]

---

@drjdpowell wrote:

BTW> don't use "named" Queues unless you actually mean to access them by name elsewhere.

---

Why is it bad to name the queues?

[crossrulz]

---

gregoryj wrote:

Why is it bad to name the queues?

---

Actual situation that I recently saw: Do you know what happens when you try to create two queues with different types of data but use the same name?  One of them gets an error.  And if they are the same type, well this implies that you have two VIs trying to dequeue from the same queue which means you have no idea who will get what data.

So my rule is to never name your queues if you are passing the reference around.  Named queues are useful for getting the reference of a queue that another process is recieving data from, but I just prefer to use an Action Engine instead.

[Gregory]

I see, thank you all for the suggestions

[drjdpowell]

---

Why is it bad to name the queues?

---

It's also a readability issue.  If I see a name in your code I have to assume someone somewhere is also accessing the queue.  Without a name, I instantly can see everywhere it is used.