AI timing signals (USB-61620)

[Kevin_Price]

It would be a mistake to revert back to a software-based approach to monitor, notice, and react as a "triggering" method.

Instead, just collect or assemble your continuous data in blocks representing 16 motor revs.  The simplest first method could be to read 16000 samples at a time.  Then each chunk you read will be the next 16 revs of data, all correlated to position b/c you use the encoder as a sample clock, no gaps caused by software reaction time.

Two notes:

- you should probably explicitly set a larger-than-default buffer size.  I like having some slack so I'd probably set it at 100k in my call to DAQmx Timing.

- when using an external clock such as an encoder signal, you need to be mindful of handling the case where the clock stops and you never get all the expected samples.  DAQmx will get stuck waiting until you get a timeout error, so think carefully how long you want to set that timeout for

This approach can work even if you don't need or want all 16 motor revs worth of data.  You can always just ignore and toss away the portion of each 16 motor revs that you aren't interested in.  But stick with the method because it helps keep you in sync with the original Z-index trigger position.

-Kevin P

[Ammad156]

Understood. Few confusions though:

1) Even though im using the encoder signal as source for sampling clock, why does the samplic clock need sampling rate? Assuming I set the maximum sampling rate for my DAQ (250 KSa/s) with 16000 samples it corresponds to a signal of 64 ms. Changing the motor speed would change the encoder signal but keeping the rate and number of samples same the signal would still be 64ms. Does each 1000 sample corresponds to 1 rev with changing speed?

2) Does the buffer size that you mentioned adjusted by choosing the sampling rate?

Thanks for bearing with me.

[Kevin_Price]

1. When you call DAQmx Timing to configure an external clock (such as your encoder ch A), think of the value you enter for 'rate' as a convenient fiction.  Whether you tell it 250 KSa/s or 100 Sa/s partly won't matter because the actual rate just depends on the rate of the edges coming in from encoder ch A.  A sample will be taken at each edge, whatever the encoder speed may be or how it varies.

   So to answer your direct question, each 1000 samples will correspond to 1 rev, no matter the actual encoder speed, and no matter the fictional guess you wire in to DAQmx Timing.  The actual duration needed to take those 1000 samples will very much depend on the actual encoder speed and will not depend at all on the 'rate' value you declare.

2. But yes, there's a catch.  I'd still suggest wiring a reasonable estimate for 'rate' in the call to DAQmx Timing because DAQmx will still make use of it:

•  with an external clock, DAQmx will simply believe your rate.  So if you call DAQmx Read to get a waveform, it will know to populate the 'dt' field with 1/rate, whatever rate you declared.  In such cases, you should remember not to completely believe the dt value, but for the sake of live displays it can be useful if you're at least fairly close
• DAQmx also uses the sample rate to calculate a minimum buffer size.  (Which is why I also suggested you explicitly declare a nice big buffer size in the call to DAQmx Timing -- so it wouldn't have to matter if you made a good guess about the encoder rate). 

-Kevin P

[Ammad156]

Thanks Kevin for you continious help. I tested the program and its working perfectly!

Cheers,

Ammad.