Continuous sampling sync between PCI-6601 and PCI-6251

[Toddimus]

Hi, first post here.

So I have a current data acquisition setup already working well using a PCI-6251 card.  I am using the ai/sampleclock as the source for all of the digital input, and counter input sample clocks.  I've got the timing set up as continuous samples, sample rate 1000 to 10000 adjustable, and I'm getting great data with the setup.  Now I want to add another card, the PCI-6601 to have access to four more counters.  I want to use the same continuous samples setup, and use the same sample clock between the devices (6251 ai sample clock).  I realize that I'll need to use the RTSI signals routes, but I can't seem to get them to work.  I always get an error that says I can't use sample clock timing for counters.  Thing is, I've been using sample clock for counters for a long time with great success!  What gives?  Can somebody chime in and let me know what I'm missing?

Configuration will be the following:
6251
Counter 0: Edge count with direction
Counter 1: Period (to measure velocity of counter 0)
8 Digital inputs
16 Analog inputs

6601
Counter 0: Edge count with direction
Counter 1: Period (to measure velocity of counter 0)
Counter 2: Edge count with direction
Counter 3: Period (to measure velocity of counter 2)

Thanks!

[Kevin_Price]

For "period measurement", you'll probably need to use the "Implicit (Counter)" version of DAQmx Timing.  The "sampling" instants for period measurement occur on the edges of the signal to be measured, and NOT on the edges of some other regular sampling interval.  That's why the "Sample Clock" version isn't allowed.

If you really need to sync up all the sampling instants, you can either:

A. Derive velocity from your Edge Count buffers.  Fairly easy to implement, fairly poor resolution and noise characteristics in most cases.

B. Derive period timestamps from a cumulative sum of the periods, then interpolate a velocity value at the times the other signals were sampled.

Also, be aware that the 6601 only has 1 DMA channel available for buffered sampling.  3 of your tasks would need to be configured to use DataTransferMode = Interrupts.  Your max sampling rate will be system-dependent.  You can probably get into the several kHz realm if you're careful, but won't likely acheive 10's of kHz.

-Kevin P.

[Toddimus]

Kevin,
Thanks for the reply.  I had already implemented a velocity measurement using your method A, and you're absolutely right, it has poor resolution.  This is the reason I'm trying something else.  I like your idea for method B.  It took me a minute to figure out how I'd implement it, but I think I understand now.  Do you have any examples of this method?  I'm sure I can figure it out, but a template to go by would be even better.  Don't worry about it if you don't already have one made that you can just copy and send.

I understand the reasoning behind the implicit timing method, but I was hoping the hardware could "remember" the last period and give it to me when I sampled it at the ai sample clock rate.  I'll give method B a try unless there's another idea.

Should I still be able to use the 6251 ai sample clock to sample the position counters on the 6601 (via the RTSI cable)?
Maybe it would be good to change around the ordering of the channels and put the period measurements on the 6251 counters.  The 6251 does have DMA access for both counters, doesn't it? 

I was about to post this and I had an idea...  What if I measured the position using my ai sample clock on one counter, and measure the same position using another counter with the implicit timing.  On yet a third counter, I could measure the period of the signal.  The second position counter would give me a synchronization between the sample time and the period measurement of the third counter.  It seems somewhat wasteful of channels, but I think it might get me what I want.

Thanks again
-Todd

[Kevin_Price]

1. No examples right on me.  I coulda sworn I posted a screenshot about it but couldn't find it.  Here's a thread where I described a bit of detail in the last paragraph.  I know I've seen others post examples about interpolation or "lookup tables" that may help as well.

2. Re: sample on edges vs. "remember" most recent peroid and store it when there's a new sample clock edge.

   I've thought about this a few times too.  I *do* think that the current behavior is the best default choice, but I also agree that there are times it'd be more handy to sync a recent "remembered" period to a system-wide common sample clock.  I'm not sure if the board hardware could readily accomodate that kind of change or whether it would only require changes in the driver layer.  Maybe you could submit it as a product suggestion?

3.  Yes, the 6251 AI clock can be shared to the 6601 over RTSI.

4. The M-series boards have DMA available for both counters.

5. Your idea with 3 counters -- I'm not 100% sure I'm following exactly how that scheme might work.  I'm left with the impression that you won't really buy yourself anything over using 2 counters and software intepolation, but maybe I just don't understand the scheme fully.

-Kevin P.