RTD module NI-9216: Task commit time

[alecote]

Good day! I have a cDAQ-9185 with the following four modules:

• 2 x NI-9220 (Voltage input module)
• 2 x NI-9216 (RTD input module)

I have an AI task that is meant to last 1s with a sampling rate of 1000 Hz and 1000 samples_per_channel. I am running into timing issues where starting and stopping the task adds so much overhead that it becomes too slow for my application. The full read() operation for that 1 second of data takes 5.6 seconds! My application requires switching between two different tasks, and as such I do not think that I can avoid that overhead.

Creating a simple AI task and calling a single task.read() is very slow when I include channels from the NI-9216 modules. I dug down by controlling the task state transitions myself and timing each step. I found that changing the ADC timing mode to high speed on the NI-9216 helped, but performance remains poor.

Is it normal for the task Start and Stop functions to be so slow for the NI-9216? Is it a hardware limitation or could it be a bug with nidaqmx-python? I am unfortunately not equipped to test using LabVIEW or the NI DAQmx driver directly.

See the test script attached.
nidaq speedtest single.py

Timing tests

(Note: Including delays from the network connection)

Task using all channels from the NI-9220 modules only:

Verify = 108ms
Reserve = 10ms
Commit = 110ms
Start = 39ms
Read = 12ms
Stop = 41ms

Task using a single channel from one NI-9216 module only, default ADC timing mode:

Verify = 95ms
Reserve = 7ms
Commit = 635ms <----- Huge overhead !
Start = 15ms
Read = 216ms <---- Default high-res mode takes 200ms for one sample
Stop = 237ms <----- Huge overhead !

Task using all channels from both NI-9216 modules, default ADC timing mode:

Verify = 125ms
Reserve = 9ms
Commit = 2247ms <----- Huge overhead !
Start = 14ms
Read = 1604ms <---- 200ms x 8 channels = 1600ms
Stop = 1652ms <----- Huge overhead ! as long as reading !

Task using all channels from both NI-9216 modules, using ADCTimingMode.HIGH_SPEED:

Verify = 92ms
Reserve = 12ms
Commit = 791ms <-----Still a large overhead !
Start = 18ms
Read = 25ms <---- 2.5ms x 8 channels = 20ms
Stop = 57ms

[bkeryan]

Hi @alecote,

I think this is due to how CompactDAQ allows you to mix fast and slow sample rate modules in the same task. See cDAQ-9185 User Manual >> AI Convert Clock Signal Behavior For Analog Input Modules >> Slow Sample Rate Modules.

Some C Series analog input modules are specifically designed for measuring signals that vary slowly, such as temperature. Because of their slow rate, it is not appropriate for these modules to constrain the AI Sample Clock to operate at or slower than their maximum rate. When using such a module in the cDAQ chassis, the maximum Sample Clock rate can run faster than the maximum rate for the module. When operating at a rate faster than these slow rate modules can support, the slow rate module returns the same point repeatedly, until a new conversion completes. In a hardware-timed task, the first point is acquired when the task is committed. The second point is acquired after the start trigger as shown in the following figure.

Figure 32. Sample Clock Timing Example

For example, if running an AI task at 1 kHz using a module with a maximum rate of 10 Hz, the slow module returns 100 samples of the first point, followed by 100 samples of the second point, etc. Other modules in the task will return 1,000 new data points per second, which is normal. When performing a single-point acquisition, no points are repeated. To avoid this behavior, use multiple AI timing engines, and assign slow sample rate modules to a task with a rate at or slower than their maximum rate.

According to the NI-9216 Specifications, the high-resolution ADC timing mode takes 1600 ms to acquire from all channels.

When you commit the task, DAQmx acquires a sample from the NI 9216 so that it can immediately return data when the task starts. I would expect it to do this for all NI 9216s in parallel, so I don't know why the time is significantly longer than 1600 ms, but I will note that it's less than 3200 ms.

Then, when you stop the task, the NI 9216 may be in the middle of a sample, and it may have to wait up to 1600 ms for that sample to complete.

BTW, the cDAQ-9185 has three analog input timing engines, so it can run three AI tasks at the same time. Perhaps you might get better results by putting the NI-9220s and NI-9216s in separate tasks?

[alecote]

Hi @bkeryan,

Thank you for your explanation!

Since you say DAQmx acquires a sample when I commit, I tried a few things with only the NI-9216:

1. If I do not specify task.timing.cfg_samp_clk_timing when setting the task, the read() function takes >1600ms.
2. If I specify task.timing.cfg_samp_clk_timing with a rate above the rate of the NI-9216, whether the mode is CONTINUOUS or FINITE, the read() function is instantaneous. If I set the rate equal to or lower than the rate of the device, that additional delay appears even for a single sample. If I understand correctly, this means that with the higher rate I am capturing that first sample measured during the commit and shaving off that 1600ms from the read() call.
3. In all cases, committing takes a while and stopping always takes >1600ms.

Thanks for the suggestion of using a separate task for the slower modules. It won't exactly solve my main problem, which is that starting a task involving an NI-9216 on high resolution mode and obtaining just one data point takes 3.9s for a single module and 4.1s for two modules. That is quite the overhead for a measurement that takes 1.6s! In contrast, a task involving only NI-9220 cards takes a total of 0.25s for a single module and 0.31s for two modules.

High speed mode is okay-ish if I oversample and average, although I would still like to get rid of the 500-900ms commit time in that mode. Do you know if that commit time is normal for NI-9216s? If it is, I might have to do as you suggest and dedicate a task that will continuously run in the background such that I only have to poll the same committed task.

Cheers