I haven't used a cDAQ with embedded controller but have a lot of general experience with NI DAQ devices and DAQmx. Some stuff I know well, and where I don't, I'll point it out.
I would *expect* you to be able to use the 25 kHz pulse as a sample clock timebase for your 9215 module. But I've mainly worked with desktop and PXI devices which tend to support a great deal of flexibility for routing external signals to be used as specific internal functions such as a sample clock timebase.
I simply don't know whether your combo of devices has some specific limitations, so be sure to try each of the 4 possible DIO channels in case your routing options are limited. If it doesn't work for any of the 4 channels, please post your test code (back-saved if necessary to LV 2020 or earlier), and identify any errors or odd behavior.
RE: what looked "inconsistent" to me
You described the external signal as 25 kHz. Then your counter output screencap shows as being configured for 1000 low ticks and 1000 high ticks. The total period is 2000 ticks, resulting in a 25000/2000 = 12.5 Hz counter output.
But then your AI screencaps show this being used directly as a sample clock whose frequency you declare as 1 Hz.
This inconsistency made me unsure about your actual AI sample rate, which affects the advice about how many samples to read per iteration. If no more than 12.5 Hz, you're in the ballpark where reading 1 sample per iteration is probably acceptable, though I'd personally probably opt for something like 4 or 5.
And I'd also strongly recommend removing the msec timer in the AI loop. The request for samples from DAQmx Read will already set your loop timing without wasting CPU. And as a rule you shouldn't have 2 different mechanisms trying to control loop timing simultaneously.
1. I'm inclined to persuade you not to bother trying to capture that waveform because anything you might learn from it can be inferred in much simpler ways.
For starters, any half-decent capture of the clock waveform will require you to sample at a rate approaching or exceeding 10x the clock frequency so you get multiple samples during each high and low time. All that really does is prove that the clock signal is present and there are simpler ways to do that. Most simply, you can query the AI task for the total # samples acquired, knowing that you only get samples when the clock signal is working.
2. DI is software-timed primarily because you didn't call DAQmx Timing to set up any kind of hardware timing. This puts the task in "on-demand" timing mode where each call to DAQmx Read initiates a new reading with a fairly short but somewhat variable execution time. Hardware timing latches samples at precise times and accumulates them in buffers for later retrieval. The subsequent calls to DAQmx Read will again have fairly short and somewhat variable execution time, but the data samples returned from the buffering process will have been taken at extremely precise hardware-timed intervals.
The msec timer adds another important layer of software timing on the loop's iteration rate. This would likely to be the bigger source of timing variability between samples if you left your task in software-timed on-demand mode.
3. Yes, those tunnels are exactly the data dependency I meant.
-Kevin P
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
