Open bkeryan opened 6 months ago
FYI, DAQmx_Val_GroupByScanNumber
does not have this data squashing/shifting behavior.
With DAQmx_Val_GroupByScanNumber
, the original array would be:
[1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
Truncating the number of samples would not move any of the samples.
NumPy can use this data format without transposing the array indices if you specify Fortran-contiguous order instead of C-contiguous order, but nidaqmx-python doesn't currently support this.
When
DAQmxReadAnalogF64
withDAQmx_Val_GroupByChannel
returns fewer samples than requested, it squashes the valid samples together at the beginning of the buffer. The way thatnidaqmx.Task.read
handles short reads doesn't take this into account, so it may return samples that have been overwritten.Test case (from
tests/component/test_task_read_ai.py
, under development):Result (lib and grpc fail the same way, because the underlying interpreters have consistent behavior here):
NI IO Trace shows:
![image](https://github.com/ni/nidaqmx-python/assets/17914399/145fc232-a638-45f8-981c-cf77b11bd6a5)
The original array was [1,1,1,1,1,0,0,0,0,0,2,2,2,2,2,0,0,0,0,0,3,3,3,3,3,0,0,0,0,0] then it was squashed to [1,1,1,1,1,2,2,2,2,2,3,3,3,3,3,x,x,x,x,x,x,x,x,x,x,x,x,x,x,x] When this happened, the old 2s were overwritten with 3s.
This test case passes if you increase the number of samples to acquire because a larger read buffer prevents the old/new sample positions from overlapping.