Producer/Consumer pattern executes slow

[wiebe@CARYA]

---

@Yamaeda wrote:

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

---

There's a time out in the event structure...

[JEmmanuelH]

Thanks for all the replies.

What I'm trying to do is getting every single data in the buffer because they are necessary to take some decisions. So yes, the critical part is the data. I started from the data P/C pattern. Should I go back to the original structure (with the case structure) and handle the front panel in a different loop?

I've tried moving the read section to the Timeout event handling of the event structure but it didn´t work as expected.

[Bob_Schor]

I'd like to recommend a very powerful tool (well, a Class of Tools -- feel free to substitute) that will probably help you gain clarity in what you need to do, and will certainly help us understand the issues.

Open Microsoft Word.  Write a 3-5 page Document describing What you want to do.  Do not worry about How to do it, but concentrate on the What.

It seems to me that a critical need is to "take data" and based on the incoming data, "make some decisions".  Describe what the data are, including how you plan to acquire them (A/D sampling, reading from a VISA device, other), the nature of the Data (an array of Dbls, a string that needs to be parsed, other), and the "time" nature of the data (which includes how often you sample and how many data points you take at each sampling time).

Describe what sort of decisions you need to make, and how much data you need to make it.  Do you need to look "backwards in time" to fit a straight line and see a trend?  Are you waiting to "cross a threshold"?  Do you need to sample until the Operator Pushes a Button?

Do the data need to be processed?  This can include saving them to disk, doing analysis on a point-by-point basis to make Decisions (see previous paragraph), etc.

Once you have the Big Picture of the central part of What you want to do, it's time to "put it in context".  What steps to you need to take before you start processing the Data?  What steps do you need to take when you make Data Decisions?  What steps do you need to take when you are done with the Data?

We haven't said anything about the Front Panel and Controls (other than the reference to "Push a Button").  Now would be a good time to describe the minimal set of Controls and Indicators, and how they fit in the Big Picture scheme you have documented.

So some ideas.  A Multi-Step "What" Design is often done with a State Machine or a Queued Message Handler (which is sort of like a State Machine that can get its States through a Queue, almost acting as a Consumer for a Producer somewhere, but don't worry about that yet).  An Event Loop structure for Front Panel Controls can generate a virtually-instantaeous response when you "push a button" or "set a path" -- if you have a QMH (Queued Message Handler) that can respond to a "New Path" message, you can simply send the message with Path to the QMH and it's done.  The QMH can also have "Initialize Devices", "Start Recording", "Take Another Point", "Found Something Interesting", "Finish This Run", etc. "States" (or Messages that it can process).

But before you start worrying about How you are going to put all this down (i.e. QMH, State Machine, Producer/Consumer, Event Loop), write the Documentation so you have a very clear idea of What you want to do.

It took me about two years to learn the virtue of Writing First (not that I hadn't heard the First Rule of Software Development, "Write the Documentation First").  Now I at least start coding and Documentation-Writing for major projects in close temporal proximity, with Time Out to write More Documentation whenever the code seems to be getting Out of Hand ...

Bob Schor

[JEmmanuelH]

Thanks for all, I really appreciate the advise. I'm working on that.

For the moment I only documented the Execution VI which is the one that I've been having problems with.

It looks like it is not possible attaching Word documents so I'm pasting the requirements here.

Execution Window (VI)

This VI should take a bunch of data (Concatenated strings) generated on the “Set” VI and send it once through the GPIB buffer using a VISA resource name found on the Initialization VI. The data should be available to be modified and sent during the execution.

The variables included in the concatenated string to be sent are:

-V, F, td, tr, Polarity (Could be 1 or 2 numeric values), Couplings (It is a numeric value and can be more than one number, so, is an array) and Test duration.

-Pause between tests. This is not to be sent. The Pause between tests value is also gotten from the Set VI. This value is only used in case that Polarity or Couplings include more than a value. The VI must wait the specified time before sending the next updated string.

-Approx test time. This is not to be sent. This is also gotten from the Set VI.

This VI should be reading the GPIB buffer at all time to get the sent device’s messages and make decisions in base of them. The expected messages are:

If the test button (physical) is not pressed (RR,11; is received), the VI should show a message saying that the button is not pressed.

When the test time has been completed (command RR,00; is received) the VI should send the same concatenated string but with the updated coupling or polarization value and so on until there are no more values (coupling or polarization). When there are no more values, the VI closes itself.

The front panel must have at least Indicators of the sent values: V, f, td and tr. It should indicate the approximate test time and the remaining time starting from the approximate test time and decreasing. As controls it must have a break and stop buttons. If the Break button is pressed, a dialog box should be shown giving the option of continuing or stopping. If the stop button is pressed, the command to stop is sent and the window is closed.

Thank you again.

Emmanuel.

[JÞB]

---

@Bob_Schor wrote:

I'd like to recommend a very powerful tool  "Write..."

Bob Schor

---

BRAVO!

How do you expect a developer to develop?  Developers need to read something!  I have an 8-Ball that I read now and then.  Sometimes, I have developed code reading someone else's mind, I would prefer to read a requirements document! (then I can justify my efforts and get PAID.)

Don't get me wrong, I love writing code in LabVIEW! But, getting paid is one of those "Bonus Features" that we all have learned to expect. 

[CFER_STS]

You have an event structure with a 100 ms timeout, but in the same loop, you have a VISA read that is waiting on 100 bytes.  Your loop will not iterate until 100 bytes are read, or until the VISA read times out, which you have configured as 10000 ms.

Perhaps a faster way to do this is to read all available bytes, and put those into a queue which you can batch process in the consumer loop, instead of trying to do that on the front end.  Then, if you have read >0 bytes, enqueue and send a 0 to the event timeout.  If bytes available is 0, do not enqueue, and send a 100 to the event timeout.  Set the VISA timeout way down to 25 ms or so - it only needs to be long enough to know whether there is data to read.  Worst case, your event structure will respond to front panel events within 100 ms, but that loop will nominally execute faster as long as there is data available.  You can increase the event timeout from zero to slow things down if you're getting a lot of empty reads.