9401 returns fewer samples then clock edges.

[Tom_from_the_Lab]

I am using 2 NI-9401s in a cDAQ-9172. One is configured for input, continuous samples, falling edge. The other is output, continuous samples, rising edge and no regeneration. My clock is Counter0 producing 1024 cycles and is retriggerable. My goal is to send data to the DUT on the rising clock edge and read results on the falling. Everything seems to work (no errors) but when I loop the writes and reads the input will return 1023 samples the first read and 1025 on the second and so on. If I wire my number of sampled per channel from my counter into my number of samples per channel I timeout. Since I am reading one sample per falling edge shouldn't the numbers be the same? I have tries reducing my clock speed and changing number of samples and the results are the same. Why am I missing a sample?

Thanks in advance!

[MarkGrot · Accepted solution]

I can't say what is going on for sure without seeing your code, but I have a few ideas.

I assume you are starting both the input and output tasks prior to generating your first counter pulse.  If you aren't explicitly starting DI and DO prior to your sample clock, you can lose samples.  This probably isn't happening because you are getting more samples back later.

I assume that when you read 1023 and then 1025 samples that the first sample of the 1025 should be the last in the first set and that taken as a set of 2048 all points are correct.

If the last statement is true, then what you are seeing is a consequence of using continuous tasks.  Your input data is not being flushed back to the host at the 1024 sample count that you would like.  You'll get it eventually, but not until enough additional data has been generated.  

What causes your counter task to retrigger?  How often does this happen?  Do you know how many times it will happen?  It might be better to create finite tasks for 1024 samples, explicitly commit them, and start again immediately after stopping.  This will flush your data at the 1024 sample mark but will take additional time to rearm (which is why the frequency of your trigger is important).

The other alternative is to split your data after the fact, perhaps one retrigger cycle behind.

[Tom_from_the_Lab]

You are correct with the data not being flushed from the buffer on my terms. I have screen updates and a couple of loops running and something had to give. I switched to a finite number of samples, started and stopped all 3 tasks and it worked fine. There is a speed hit but this is a case where it's better to be right than fast.

Thanks for the response!