On 27/10/2021 14:06, Andrew wrote:
> Thank you Ian !
> But the result is no longer that simple :)
> Well I can imagine why the first sample in the buffer isn't valid
> - perhaps ADC needs some time for its initialization.
Perhaps doing a software read of the first channel in the list before
setting up the acquisition would fix that.
> With two channels everything is alright (except that first sample)
> and with different number repetitions of them in channel list (kind of
> 'scans' in previous sense)
> read() (seems to be) always returns the number of samples equal to
> the length of the channel list.
> With three or more channels read() almost always returns one additional
> (even for one 'scan').
> Sometimes read() does return the proper number of samples,
> but I couldn't find out any correlation with sampling rates, trigger
> repetitions, channel order etc.
> I can live with that, but would of course appreciate any suggestion to
> clarify the situation
The Comedi file "read" handler only blocks (except in non-blocking mode)
if no data is available the Comedi data buffer and then copies what is
available into the user's buffer. But it doesn't keep blocking to fill
up the user's buffer, so the "read" can return less than the requested
The device driver is responsible for making data available in the Comedi
data buffer for the Comedi "read" handler to use. For most drivers
(including the ni_pcimio), data is only made available in the Comedi
data buffer during interrupt handling.
For the ni_pcimio driver, the CMDF_WAKE_EOS (or TRIG_WAKE_EOS) flag in
the acquisition command will have cause an interrupt to be generated at
the end of a scan, otherwise it will happen when the FIFO is half full
or at the end of acquisition.
CMDF_WAKE_EOS probably won't do much in your case if the acquisition
consists of a single scan (comprised of several mini scans!).