parallel execution of VIs

[Artem.SPb · Accepted solution]

---

rakesh@labview wrote:

Yes I have.

But the problem is I have to use two VIs

---

not like the truth.
try again

[rakesh@labview]

Hi,

   My problem is how to implement the producer consumer design pattern in 2 VIs.

One VI is producer and 2nd is consumer. How to implement this

[crossrulz · Accepted solution]

---

rakesh@labview wrote:

Hi,

   My problem is how to implement the producer consumer design pattern in 2 VIs.

One VI is producer and 2nd is consumer. How to implement this

---

You have a higher level VI that creates the queue.  You then pass this queue reference into your two VIs.  One of the VIs enqueues data.  The other VI dequeues the data.

[LVCoder · Accepted solution]

You can also create a named queue in both the vis to access the same queue. 

[Bob_Schor]

---

rakesh@labview wrote:

Hi,

   My problem is how to implement the producer consumer design pattern in 2 VIs.

One VI is producer and 2nd is consumer. How to implement this

---

Artem.SPb showed you how to do this.  He used a Frame (so you could "see" what is inside) and called it "1st VI".  That's the Producer.  The Frame called "2nd VI" is the Consumer.  Replace the Frames with Sub-VIs (having the same contents) and you'll have it.

One thing we ask (that you haven't done) is to see some of your code.  One reason is that this tells us what version of LabVIEW you are using, which means we can tailor our response to your Version (if appropriate).  It also gives us an idea how much LabVIEW experience you have, so we don't talk "over your head".

Bob Schor

[rakesh@labview]

Thanks a lot . Please find the attached VIs

[rakesh@labview]

Hi all

Thanks all. The producer consumer concept worked for me with named Queue.

I have one more requirement. Actually I want to acquire some data from Mutimeter, DAQ, oscilloscope etc, do some calculations and update the values in a Queue. Another VI has to save these data from Queue (each set)in text file. One more VI has to save these data in database also . That means  database saving should happen parallely in another VI

So I have to implement a 3 level program. Please tell a solution

[mcduff]

Just expand on what you have already done, ie, you need more loops and queues.

mcduff

[Bob_Schor]

I have several recommendations for your Design, with both the Producer and Consumer running as sub-VIs and the Main doing (almost) nothing except creating a Named Queue that it never uses.

• The Main, which has the "always visible" Front Panel, has no Controls, in particular, no Stop button.  So how did you plan to stop this routine?
• The Producer has a Stop Button, but ordinarily, sub-VIs do not "show" their Front Panel, and you can't easily "push" what you can't see.
• Using named Queues created independently sounds neat (I used it, myself, when I first learned about it), but it places the burden on "connecting the wires" on your spelling and memory skills.  Mis-spelling a Queue name can lead to a "tricky-to-find" error.  My recommendation is to (in one place only) create an unnamed Queue and run it "by wire" to any sub-VI that needs it.  An easy way to do this is the following:
  1. Right-click the output of your Obtain Queue function and Create Indicator.
  2. Disconnect the Indicator, right-click and Change to Control.
  3. Drag the Control from the Front Panel of your VI to the Front Panel of your sub-VI. 
  4. You now have your Queue In for your sub-VI.  Wire from Obtain Queue to sub-VI's Queue In.
• The above points lead me to suggest combining Main and Producer in the same VI (so Stop now is on the Main's Front Panel).  You wire the Queue from Obtain Queue directly into the Producer Loop, and branch the Queue wire before it enters the Producer Loop and wire it to the Queue In of the Consumer sub-VI.
• Pushing Stop will stop the Producer.  How do you stop the Consumer?  A good way that is reliable, safe, and relatively "inexpensive" is to use a "Sentinel", a data value that is ordinarily never sent.  Since most Producer/Consumer Queues involve Arrays of data, an empty Array would never ordinarily be sent.  Here's how to get the Producer (who "knows" to stop because it has the Stop button) to tell the Consumer to stop:
  1. Producer exits its loop and enqueues an Empty Array.  That is the last time it uses the Queue.  It does not release the Queue (as it doesn't know that the Consumer is done).
  2. The Consumer is modified to check if its dequeued item is an Empty Array.  If so, it knows it is done and can exit, and, furthermore, that it can Release the Queue (which is perfectly safe since the Producer has already said "I'm done").
  3. Otherwise, the Consumer "consumes" the non-empty Array.

Try this modification.  I think you'll like it.  Oh, one more thing -- it is very easy to create Icons (with the Icon Editor) for your sub-VIs.  I suggest a simple full-size Box in which you put a 2 or 3-line Identifier ("Prod", "Cons") so you'll know what you look at the Top Level VI what those otherwise-anonymous boxes (sub-VIs) are supposed to be doing.

Bob Schor

[rakesh@labview]

Hi Bob,

         The VIs that I have posted are just skeleton only. There are lot of other componets in it .I just posted to show how I am going to communicate between VIs parallely.