Producer/Consumer pattern executes slow

[JEmmanuelH]

Hi all, as you'll see I'am pretty new at using the producer/consumer pattern.

I coded the block diagram shown below and it already does what it is suppossed to do, the only matter is that it executes very slow.

Any recomendation or idea about this?

I realised that it turned slow when I added the upper loop (Producer). At the beggining I was running it in a single loop (lower loop) and without the visa read part.

I'd appreciate every comment.

Best regards.

Emmanuel.

PS: Attached below the upper picture. Just in case.

[Bob_Schor]

Please do not attach a static picture of your code, instead attach the actual VI (a file whose extension is .vi).  Would you appreciate my asking you for help with a 1000-line uncommented piece of C++ or Matlab code?  Probably not.

With an actual VI, I can look closely at everything, see exactly what functions you are using, test the wires to be sure they are correctly connected, get Help on any function I don't understand, and even run your code to see why it is "slow".  Note that the idea of a P/C design is that the Producer is often "time-locked", so you take everything else that follows the Producer and move it to a Consumer so it can run in parallel and "share time" with the Producer, making the combination faster.  So if it is running "unnaturally" slow, there's probably a design flaw (that I can't see in your limited picture view).

Bob Schor

[JEmmanuelH]

You're right, it is very diffcult diagnosting a code looking from a single and poor view.

I continued looking for ways to improve it and found that decreasing the timeout constant at the beggining of the diagram (from 10000 ms to 1000 ms) it went notably faster.

Just documenting something and I'll upload the whole Project.

Thanks for the advice and the fast reply.

Emmanuel.

[wiebe@CARYA]

As a few side notes:

Why do you read the Boolean in the event structure, put it in a local, and then read the local? Why not use a wire instead of the local? It's not only ugly and avoidable, it's also wrong: the local is read at the beginning of the iteration. So a click can potentially be ignored for 20s, since each iteration takes potentially 10s.

Why the upper shift register in the lower loop? It does not do anything useful, and adds complexity.

Obviously, lots of bended\crossing wires that can be avoided. I know you (intend to) fix that when it's working, but *now* is the best time to do it.

Usually, you use P\C to remove the DAQ from the P loop. And now you put serial reads in it... The UI handling will now be stalled by serial communication. The C loop does not seem to do anything worth separating (but that might a future feature)? It makes more sense to me to put all DAQ in the C loop, and use the P loop for UI handling. You might need two P\C's: From UI (P1) to Serial (C1), and from Serial (P2) to the current C (C2).

[Yamaeda]

Your top loop will only fire when an event happens, so you'll only ever read from your VISA when you e.g. press Stop ...

/Y

[JEmmanuelH]

Thanks for replying, I'm Reading the boolean in that way because the event structure is one part of the state machine inside the consumer loop (Lower loop).

So, to keep Reading the visa, should I enclose everything inside the event structure?

With regard to the shift register in the lower loop, you're right, I've replaced it with a tunnel.

I'm attaching the most actual code, just in case.

Thanks for all.

Emmanuel.

[Bob_Schor]

Thanks for including the Project.  I can't find the Producer/Consumer code in there -- where is it?

Bob Schor

[JEmmanuelH]

It is in Project\UCS500\SCR_Execution_Burst.vi

[Bob_Schor]

Ah, thanks.  I must confess I don't understand what you are trying to do, but I think I know where you went "astray".  There are two Producer/Consumer Templates in LabVIEW, one for handling Events, one for handling DAQ.  Unfortunately, you chose the wrong one ("Events"), possibly because noone explained the idea of the P/C Design Pattern.

In a P/C design, there is generally a critical-time part for which you want to make an immediate response (i.e. you want to be "ready to roll").  The Producer is the time-critical part, and once it "fires", you hand off all subsequent processing via a Queue to a second routine that makes the "immediate response".

In an Event P/C Design, the Front Panel is the "time-critical" part -- when a Button is pressed, you want to immediately do something, but you also want to be able to respond to another button push, so you want to processing to be in another loop.  

More common is a P/C design for DAQ.  You have a loop that says "Get some Data" (either by a DAQmx Read or a VISA Read), but what do you do with the data?  Why, you put in on a Queue and send it to a Consumer Loop, allowing the Producer Loop to return to getting more data.  The Producer loop is "clocked" to the Data Rate (i.e. if you are sampling 100 samples at 1 KHz, then every 100/1000 = 0.1 seconds, data will appear.  You want to get it out of this loop (via the Queue) so that the Producer can wait for the next 100 samples, coming 0.1 seconds after the first.  It has the clock, so it runs at the Clock rate, with the Consumer just playing "catch-up".  Note that the Consumer needs to run at least as fast as the Producer, but any single Consumer loop can take a lot longer (i.e. to open files or other occasional time-consuming tasks) because the relevant data are buffered by the Queue.

So rethink what you are trying to do.  I don't think that instant response to button pushes is what is critical here -- think about what you want to do in the DAQ loop.

Bob Schor

[JÞB]

---

@JEmmanuelH wrote:

Thanks for replying, I'm Reading the boolean in that way because the event structure is one part of the state machine inside the consumer loop (Lower loop).

So, to keep Reading the visa, should I enclose everything inside the event structure?

With regard to the shift register in the lower loop, you're right, I've replaced it with a tunnel.

I'm attaching the most actual code, just in case.

Thanks for all.

Emmanuel.

---

I'll look at this later but, the event structure is part of the consumer.... that may be wrong!

Who is driving this thing?  If it is your app. F the user and events.  Or, perhaps you should respond to users and produce the desired system state