Easy Question? - Don't want subVI's to run in parallel.

[RJM2]

Just a quick question (I think).  I have multiple calls to different subvi's in a while loop (not in a sequence structure).  All of these subvi's communicate with a piece of equipment that can only process one communication at a time.  Is there any risk that these subvi's will be run in parallel?  Am I correct in assuming that the main VI is paused until a subvi completes, and only then will it process the next subvi?  Should I have a sequence structure to process them one at a time?

Thanks much,

Russ

[altenbach]

Just make sure the VI is not set to reentrant (this is the default, so you should be OK unless you changed the execution options). This will ensure that only one subVI call to it can execute at any given moment.

Of course if there is no data dependency, you cannot tell in which order they will be called in each iteration. Maybe that's OK?

You are incorrect to assume that the main VI will pause while the subVI executes. It can easily do other things, e.g. run a paralell loop. However, I cannot make another call to a non-reentrant subVI if that subVI is busy.

Message Edited by altenbach on 08-15-2006 05:06 PM

[unclebump]

You could look at loading each command into a queue. Sned this queue to a separate loop that does nothing but read items out and execute the commands.

Message Edited by unclebump on 08-15-2006 08:42 PM

[RJM2]

A command queue?  Could you elaborate?

Thanks,

Russ

[unclebump]

This kind of sounds like a producer/consumer architecture. One loop produces commands from multiple sources and passes these commands to a second loop with a queue. The second loop processes the commands when received.

Here are some links to check out.

http://zone.ni.com/devzone/conceptd.nsf/webmain/CD63FD0F746B17A686256F090065F572

http://sine.ni.com/apps/utf8/niepd_web_display.display_epd4?p_guid=B45EACE3E1E956A4E034080020E74861

http://zone.ni.com/devzone/conceptd.nsf/webmain/4C94C56FE0BBF5F686256A2C006C139C

http://zone.ni.com/devzone/conceptd.nsf/webmain/C54BADADD8BBDE4286256C5200533B80

http://zone.ni.com/devzone/conceptd.nsf/webmain/91cbfbd333e64aff86256d5500463b37

[JeffBoettcher]

I'd just like to clarify altenbach's response.  I think he was answering under the assumption that you had mulitple calls to the SAME subVI.  If this is the case, his response is correct.

The way I read it though, you have DIFFERENT subVIs that all interface with this instrument.  In this case, even if the subVIs are non-reentrant (default), one could begin execution, grab ahold of the instrument, and then a different one could start running before the first one finishes, which sounds like it could be problematic for you.

It sounds like you should just be serializing your subVIs, either with dataflow (just wiring error out of one to error in of the next, for example) or with a sequence structure.

[altenbach]

---

@Jeff B wrote:

I'd just like to clarify altenbach's response.  I think he was answering under the assumption that you had mulitple calls to the SAME subVI.  If this is the case, his response is correct.

---

Yes, my anwer specifically deals with different instances of the same subVI. Reading the original question again, this may, or may not, be the right answer. 😉

(If all the subVIs are very similar, one could combine them all into one and use e.g. an enum input to select the sub-function (e.g. read|write|reset). Now my advice will still work).

If they are different subVIs, dataflow is the way to go. Any well designed instrument VI has an error-in and error-out. Chaining them up in the desired order is all that's needed to enforce serialization. 😄

[RJM2]

Thanks much, all, for your responses.  Got it running, but am going to change the design to the "Producer/Consumer" model.

Russ