@Matt_AM wrote:
So if the convert rate is faster than the samplings rate, is that just continually updating whatever is in the (assumed) buffer (or whatever you want to call the "holding till told to pass the data" spot is called) of the card so when the sampling rate triggers, it dumps the AtoD buffer to the sampling buffer?
The device will have a smallish on-board FIFO. A/D conversion values first get written into this FIFO. Soon after, they will be delivered from the device FIFO up to the task buffer that resides in PC memory. Then they'll be delivered to you when you call DAQmx Read, which retrieves them from the task buffer. I don't know the exact rules for how and when data gets moved from FIFO to task buffer though. It isn't necessarily once per full sample of all channels in the task.
Is the Convert Clock the one that writes the values to the on board FIFO buffer or is that the sampling rate? I would assume that the sampling rate takes the A/D data (set by the convert rate) and stores that to the FIFO buffer. I understand that you don't know the exact rules, but I figured I'd ask. Worst case is an "I'm not sure" answer.
New question, how would the convert clock work based on order analysis? Ive done some order analysis stuff before and I always thought it was kinda weird to set the rate for a task that isn't being clocked off of a clock.
I have only passing familiarity with order analysis. But I'd say that the convert clock would only affect phase characterization, not amplitude. And it could be complicated if the sample rate varies while the convert clock remains fixed because the fixed convert clock time interval would then represent a variable phase offset within the sample.
As to defining the sample rate, two things:
- in the call to DAQmx Timing, make a reasonable estimate of the actual max sample rate
- in your analysis, convert to the units "per revolution" instead of "per second". Your quad encoder gives you 20k samples/rev.
Regarding the samp/rev vs samp/s, the 8333 samp/s is me trying to give a "this is how fast we are sampling in the time domain, so I believe the 333 kHz convert clock is fine, although faster than is required" When doing the actual analysis, we are using the samp/rev then converting to the freq domain for analysis.
EDIT:
it just seems weird to me that the quad and edge counter tasks are clocked off of PXI_TRIG2 and not PXI_TRIG4. Maybe that was the original designers work around to solve that problem? To boil it down, I don't understand what the ai/SampleClock is in this situation.
PXI_TRIG4 shows pulses whenever your FPGA is powered and your encoder has motion. But PXI_TRIG2 will only be passing them along during the time when the AI task is actively sampling.
Awesome, that is what I was thinking would happen, I just did a poor job of explaining it. Thank you for the clarification!
You are correct that the quad and edge count tasks are started before the SCXI Ai task. Basically everything in the code set it's start trigger to the SCXI Ai Task so once that starts, everything else starts as well.
By sequencing the starts that way, your sampling is in sync for all tasks. If the AI were started first and then the encoder tasks were each started sometime later, their first (and then all subsequent) samples would be offset from one another, i.e., NOT in sync.
Correct. If I am doing stuff that needs to be in sync, I will clock everything off of a generate "faux clock" and start the faux clock last after all my other tasks have been started waiting for the clock. Follow up question regarding the way I typically sync stuff, since I am starting my clock last, is there any reason I need to have the same start trigger? I would assume no and a start trigger would be more aligned to things at different sampling rates (say microphones sampling at 48 kHz and a torque reading at 1 kHz starting at the same time).
