queue stop

[Javo20200]

Hello, I have a problem keeping this consumer producer stable, I am simulating the acquisition of 4 channels but I have errors at the time of stopping the queue, I also have problems with the flow of the data. I enclose the VI. I've already tried some methods found on the net but can't get it to work

[GerdW]

Hi Javo,

---

@Javo20200 wrote:

Hello, I have a problem keeping this consumer producer stable, I am simulating the acquisition of 4 channels but I have errors at the time of stopping the queue, I also have problems with the flow of the data. I enclose the VI. I've already tried some methods found on the net but can't get it to work

---

Which error do you get?

Which data flow problems do you have?

Which "methods" did you try?

What exactly "can't you get to work"?

On your VI:

• Why do you need ExpressVIs (FromDDT) to create a cluster of arrays of one element each? Why not use BuildArray nodes?
• Why don't you cleanup your wires?
• Why do you need to duplicate code? Why not use one subVIs multiple times or in a loop?
• Why do you use InsertIntoArray when you want to build an array by appending elements? Have you heard of BuildArray before?
• Do you really need to execute the consumer at (desired) 250Hz and filter growing waveforms again and again? Especially when you use the filtering result only once AFTER the loop???

[Bob_Schor]

You missed the "idea" of the Producer/Consumer loop.  The Producer enqueues "data to be processed" (in this case, written to disk).  The Consumer should run "as fast as the data arrives" (that is, with no time delays, as it will be "clocked" by the Producer sending it data) and should do the minimum necessary, in this case, writing a TDMS record.  The opening and closing of the TDMS file should be done before and after the Consumer Loop (i.e. Open TDMS, send Refnum into Consumer which just does the write, and close Refnum when Consumer exits).

You also don't want to "Kill the Consumer" by destroying the Queue in the Producer!  Why cause an error in the Consumer?  Better is to have the Producer, when it exits, send a "Sentinel", a "This is the last thing I'm going to send you" message (such as an Empty Array or a Cluster of NaN's) and let the Consumer test each entry for this Sentinel (which should take a fraction of a microsecond) -- if it finds it, it simple exits, and destroys the Queue when it has exited, otherwise it processes the "good data".

It is much easier to read LabVIEW code when wires run horizontally as much as possible, and the Block Diagram and Front Panel fit on a Laptop screen.  Most of the time, "hiding the messy details" in sub-VIs is a great help ...

Bob Schor

[altenbach]

---

@Javo20200 wrote:

Hello, I have a problem keeping this consumer producer stable, I am simulating the acquisition of 4 channels but I have errors at the time of stopping the queue, I also have problems with the flow of the data. I enclose the VI. I've already tried some methods found on the net but can't get it to work

---

There are many things seriously wrong here, and I recommend to start with a few basic tutorials. Many issues have already been mentioned, but I can guarantees that setting a stop button to "switch until released" is probably the worst option. Setting it to false via a value property node located 20 screens to the left still does not guarantee that it executes before the main code. Use dataflow to determine execution order! Use latch action! (You don't need local variables for it!)

Here is a quick skeleton of your two main loops. Of course the entire thing should be wrapped into a proper state machine where acquisition can be restarted or things saved without stopping the VI.

Even your front panel has overlapping Elements scattered over many (many!) screens!

[Bob_Schor]

Try this:

1. Open LabVIEW.
2. Click "File", "New ..." (that's the second entry), and (under "From Template", "Frameworks", "Design Patterns", "Producer/Consumer Design Pattern (Data)".
3. Study this VI.

Note that I don't agree with the way this example stops the program, namely by having the Producer destroy the Queue, causing the Consumer to "error out".  I, personally, would use a Stream Channel Wire in place of the Queue -- it provides a built-in "Sentinel" routine whereby the Producer can tell the Consumer "This is the last item I am sending you" (and can also tell it "This is not really data, it is an End-of-Data flag"), and the Producer just exits its loop after that.  The Consumer, when it gets the data, looks at those two flags -- the "End-of-Data" flag gets wired to the "Stop" Control, and the "This is valid data" flag is wired to a Case statement inside the Consumer that "consumes" (whatever that means) in the True case, and does nothing in the False case.

Bob Schor