reading multiple circular buffers

[bigburnsgeoff]

I have developed a vi that uses a PXI 6602 for position measurement. Two of the counters (0 and 1) are allocated for "buffered position measurement" and a third counter (2) is allocated for "pulse train generation". Counters 0 & 1 measure the rotational position of two 36,000 line quadrature encoders. Counter 2 generates a pulse train which is used as the selected gate signal for the buffer. Thus a large volume of data points is stored as an array which is a record of the encoders movement. As both circular buffers use the same selected gate signal the position measurements are made synchronously. In addition all three counters are hardware triggered so that they start simultaneously.

The goal is to have a 2D array of all the b
uffered measurements for each encoder which should have the same number of data points in each, where each cell has a corresponding cell in the other array who's value was recorded at the same time.

Although the buffers record data synchronously they are not being read in a synchronous manner. Data seems to be recorded to the buffers prior to the counters being triggered (hence you can get a row or two of zero's), having stopped the acquisition the amount of data points is not always equal, and often the first values in the arrays start on a different row.

How can I make the read buffer statements work in a synchronous manner similarly to the way in which data is recorded to the buffer?

[Geneva L.]

I'm glad to see that you've followed the models of the examples. I couldn't find the Hardware Trigger (NI-TIO).vi in your attachment. I assume that it's just like the Counter Start Trigger VI that is used in the Generate Pulse Train - Start Trig example? Other than that, I wonder if the one encompassing while loop with the indexing enabled on the edges is contributing to the problem. Out of curiosity, try using separate while loops for each of the counters, since they don't really have any dependencies on each other except for the start trigger and signal at the gates. For testing, force the loops with the Read Buffer to execute once, and compare those values without enabling indexing on the loops. Do the values match up okay there? Also, for testing, wha
t if you do a smaller test with less points so that the arrays will be smaller, to see if that makes a difference. I noticed also that time limit has 1 second left as default. I'm not sure if you're changing that, but it would make a big difference. If the counter is unable to read all the points in counts to read within 1 second, it will just return the number available. I see that you have indicators for number read. How do those compare?

These are ideas to consider and try out.
Regards,
Geneva L.
Applications Engineer
National Instruments
http://www.ni.com/support

[Kevin_Price]

Basically in agreement w/ answer above, plus would add a few thoughts:
1. Suggest you add some data dependency in config area prior to main loop. Make sure both position counters are armed *before* starting your "acq. clock" (pulse train on CTR 2). As it stands now, can you be sure that the trigger condition doesn't occur, say, after programming one encoder & the pulse train generator but before programming the other?
2. Would further suggest not entering the loop until you verify that trigger condition has happened.
3. Would suggest building up each counter's total dataset with a 1D array rather than 2D.
4. I would recommend *against* using separate while loops for the counters. Though it may help short-term debugging, it'll make life more difficul
t in the long run. Once you get the basic functionality wrung out, there are some error-checking & error-prevention details that naturally want to be shared by both of these synchronized counters, and that'll be much simpler if they're running together in the same loop.

- Kevin P.