How to incorporate retriggering in a producer-consumer loop

[MK25]

Hello,

I have developed a VI that computes the auto-correlation function in real time using data from four counter and employing the producer consumer loop. I am using a PCIe-6612 National instrument counting board for this task. All the counters sample at the same rate and process data continuously depending on the number of repetition assigned. Once the total number of repetition is reached the processed files are saved. 

Now what I want to do to run the counting events in batches(every few repetition, process the data and save the files) until the total repetitions are reached. Will the retrigger event work in this regard? if so, how can I incorporate that in my VI? I also wanted to generate an external triggering pulse the instance the retriggering event start. Can you let me know the best possible way to accomplish that?

I am attaching my VI that I have developed so far.

Thanks

[MarcDub]

In addition of the producer-consumer pattern, you should look into the state machine pattern, for both your producer and consumer loops.

I would also try to put the repeated code into sub-VIs, to make the block diagram smaller, but most importantly to make it easier to understand. There is great value to make your code easier to understand, for other people who read your code but also and mostly for yourself.

You can retrigger by simply not clearing the task after your stop. Put all your configuration VIs (create task, sample clock, etc.) outside the loop. Include trigger configuration. Then, inside your loop, you simply start the task, acquire, then stop, and repeat.

A state machine would really help you to make your code easier to manage. First state would be initialize, then you can start looping acquire and process states, until you stop at what point you go to the Close process where you clear your tasks..

Hopefully that helps.

[Kevin_Price]

MarcDub had some good suggestions, here are some more thoughts:

[Editors note: original poster PM'ed me b/c I had helped out a bit with questions about this app last summer.  I suggested a public post to get more help and to benefit others.  Anyhow, if some of my comments have a "told ya so" vibe about them, it's because my long-ago suggestions about cleanup were ignored.]

1. Truly, the need for subvi's, wire straightening, and general tidying can't be overstated.  I participate here in my spare time and the time required to get down to a detailed understanding of code that looks like yours is just too much.   Generally when stuff looks like this, I don't bother trying to help in any detail -- I can offer more help faster in another thread.  I'm making a partial exception here since it's a followup to the old thread and the PM.

2. Most of your measurement counters are sequenced to start before the sample clock.  One is allowed to be simultaneous.  That's probably wrong, they likely should *all* start before.

3. Your measurement counter tasks just about *beg* to handled in For Loops.  Place a For Loop around the config chain for one of the counters, feed in the "physical channel" input as an autoindexing array, collect the task ref's as an autoindexing output array.  Delete all the other config chains that are now obsolete.  WOW!   Look at all the clutter that just went away!

4. Same kind of deal when you read data from the counters and assemble it for the queue.

5. No need to carry around all those individual error wires all over the place.  Use "Merge Errors" and carry one shared error wire among the array of tasks.

6. As you tidy things up, you'll get more useful help on your questions because it will become possible to communicate clearly about the code.  When code looks like yours does now, I find most of the time is spent trying to understand one another and identify what we're talking about rather than actually addressing the problem.

7.  The actual solution to your problem will probably turn out to be pretty straightforward.  The process of clearly understanding:

A. what you *think* you have right now

B. what you *actually* have right now based on the code

C. what you say you want in your own words

D. what we eventually figure out that you want in terms that we both understand the same way

... well, *that's* the part that makes me reluctant to put a lot of time in until after you've put some time in to make the code and your question as clear as you possibly can.

As a volunteer participant, I don't generally want to put more time into a problem than the original questioner.  In my PM I specifically suggested code tidying and a thorough writeup before posting here.  The writeup's pretty decent but the code remains unnecessarily difficult to follow.

-Kevin P