I had only focused on the config and setup previously, now I notice that the dt you calculate is actually your loop iteration rate. This is often *not* equal to the hardware sample rate.
When you set up a task with a sample clock, there will also be a task buffer. The driver moves data from the device into the buffer according to the hardware sample rate. In order to keep up and prevent a buffer overflow, your app will need to read from the buffer at the same average rate. But you can do this in different ways.
Suppose the task is set for a 75 Hz sample rate. You could try to read 1 sample at a time at 75 Hz, or 5 samples at a time at 15 Hz, or 25 samples at a time at 3 Hz. Etc. Any of these choices will read from the buffer at an average rate of 75 samples per sec.
In your code you call "DAQtask.read()" with no arguments to specify how many samples to read. I really don't know what the default behavior of that function will be. I see several other functions in the API (particularly under nidaqmx.task.in_stream and nidaqmx.stream_readers) that would let you specify the # samples more explicitly.
For further diagnosis there should also be a way to query the task for the hardware sample rate, but I have no familiarity with the syntax.
All that being said, you seem to have gotten a much faster *iteration* rate with the predefined MAX task than when you tried to configure it explicitly. While it seems most likely this is due to a faster hardware sample rate, it's also possible that your iteration rate changed because the MAX task configuration had implications for the behavior of the no-argument "read()" function.
Hopefully someone else joins in that knows more about your particular device and the python DAQmx API.
-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.
