Parallel reentrant execution with queues

[PatrickMiller]

I have a vi which I created that works as a standalone way to control a device over CAN. I'd like to use multiple instances of this vi using preallocated reentrancy but whenever I try to launch multiple instances of this VI it almost always runs serially. If I do try to launch the vi while another is running they behave either as mirror images or fail to finish. 

I'm curious if there are some simple caveats which i'm missing that need to be addressed for this to function properly.

• My first assumption is that since the SubVI's are using queues, when multiple instances are called there is some sort of cross referencing of the queues. 
• Will functional global variables inside of this reentrant VI work through multiple clones?

[drjdpowell]

---

@PatrickMiller wrote:

I'm curious if there are some simple caveats which i'm missing...

---

Probably, but you haven't shown any code so it's impossible to tell.  Will functional globals work across clones?  Certainly.  Will the do what you think they should do?  I don't know.  The Queues will do whatever you have configured them to do, but that isn't necessarily what you want them to do.

[johntrich1971]

---

I'm curious if there are some simple caveats which i'm missing that need to be addressed for this to function properly.

---

As drjdpowell said it is impossible to tell without seeing your code. 

I have a vi which I created that works as a standalone way to control a device over CAN. I'd like to use multiple instances of this vi using preallocated reentrancy but whenever I try to launch multiple instances of this VI it almost always runs serially. If I do try to launch the vi while another is running they behave either as mirror images or fail to finish. 

---

While your subvi is set to be reentrant it may be calling non-reentrant subvis which could tend to serialize the operation.

---

• My first assumption is that since the SubVI's are using queues, when multiple instances are called there is some sort of cross referencing of the queues. 

---

If you need for each subvi to have its own queues then you need to create unique queue names. Otherwise you will be writing to/reading from the same queues in each instance of the subvi.

---

• Will functional global variables inside of this reentrant VI work through multiple clones?

---

This depends on what you mean by will functional global variables work. If you're wanting to have separate FGVs for each clone then no, it will not work. However, if you want to have an FGV that can be read/written by all clones then yes it will work. Remember, though, that the FGV can only be accessed by one clone at a time so if you're doing a lot of FGV it will reduce the parallel behavior of your subvi.

[PatrickMiller]

Thank you for the quick response, attached is a zip of the program. I've tried to remove any queues for now and just get back to a basic program. The main program is just trying to launch the 3 instances and the subVI inside is the one that i'm using reentrancy for. 

It looks like you've already answered one of the problems, i'd like to have each clone utilize a separate FGV.  

In regards to using the queues and having seperate names, could I just have the queues unnamed? Would LabVIEW then create its own unique generic name that is separate for all 3 clones?

[johntrich1971 · Accepted solution]

First of all I would organize this in a LabVIEW project.

There are ways that you can get the effect of the FGV. You could, for instance, move the code outside of the FGV vi that retains the value (thus it's really not an FGV but a subvi). Then you could use a feedback node or shift register in the clone to retain the data and pass it into the FGV subvi. You could also keep the data in arrays inside the FGV - there's lots of ways you could do this.

As for the queues, as long as they're just internal to the clone then unnamed queues should be OK.

[Ben]

DVRs (Data Value References) can be used like an Action Engine (or FGV) that we can "point at".

When you launch each clone, pass it a DVR that it can point at.

The caller can then keep track of each DVR and interact with the clone in a manner similar to an Action Engine by selecting which DVR.

Example:

I needed to create GUI that could control about 200 widgets running in a factory which I connected to via TCP for each widget.

I spun-up 200 clones and defined a DVR that each clone would keep updated.

When it was time to switch from looking at one widget to another, I switched the DVR ref and I was now looking at another widget.

For what it is worth,

Ben 

[PatrickMiller]

Thank you for the help on this. I've removed the FGV data retaining shift registers and just included those in an array shift register outside of this subvi for the 3 parallel instances and this worked. I've also removed the names of the queues and kept them internal and this also seemed to work as well.

I'll have to look into the DVR because now i'd like to update current status of each parallel instance as it runs. I was able to update status indicators by using a reference input to the subvi and then changing the property node inside of each parallel instance.