Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Getting empty data when setting for continuous acquisition (DAQmx and python)

Hi,

 

I have successfully set up an acquisition of data using python DAQmx library (https://nidaqmx-python.readthedocs.io/en/latest/) using a FINITE number of samples, using:

 

self.capturetask = nidaqmx.Task()
self.capturetask.ai_channels.add_ai_voltage_chan("PXI1Slot2/ai16")
self.capturetask.timing.cfg_samp_clk_timing(self.sample_rate)
self.capturetask.start()
data = self.capturetask.read(nidaqmx.constants.READ_ALL_AVAILABLE)
self.capturetask.stop()
self.capturetask.close()

However, now I want to set the capture to continue continuously, do a series of operations on the system and then after everything is done, I want to stop capture and retrieve all the data captured in the meantime. So I tried with this code:

 

self.capturetask = nidaqmx.Task()
self.capturetask.ai_channels.add_ai_voltage_chan("PXI1Slot2/ai16")
# NOW JUST CHANGED sample_mode to CONTINUOUS
self.capturetask.timing.cfg_samp_clk_timing(self.sample_rate, sample_mode = AcquisitionType.CONTINUOUS)
self.capturetask.start()
data = self.capturetask.read(nidaqmx.constants.READ_ALL_AVAILABLE)
self.capturetask.stop()
self.capturetask.close()

But I am always getting an empty list as a result (data) of the read function.

 

Am I forgetting something? I thought about triggers, but the first example worked without setting anything related to triggers.

 

0 Kudos
Message 1 of 3
(3,241 Views)

I know nothing about the python interface syntax, but here's some general thoughts based on a lot of LabVIEW DAQmx programming.

 

I'm guessing that either too much or too little time passes between starting the task and reading the data.  There are some special differences between finite acquisition tasks and continuous acquisition tasks that aren't apparent on the surface.  Three of note:

 

1.  the standard setting of acquisition buffer size is generally *obeyed* for finite tasks and *ignored* for continuous tasks.  Continuous tasks do their own buffer size calculation based on the sample rate.

   I see nothing in the code you posted that tries to set any particular buffer size, so this is probably not *presently* the key issue, but it may rear its head later.

 

2.  the Read behavior when you ask to READ_ALL_AVAILABLE differs greatly.  For Finite tasks, it will wait for the entire buffer to fill up and then return the entire data set to you all at once.   For Continuous tasks, it won't wait at all and will give you however many or few sample have been taken so far (without having been previously read).  If you read too soon, there won't be any data there yet.

 

3. the background acquisition buffering differs too.  In a Finite task when the buffer fills up, the task stops trying to add more data to the buffer.  It just holds onto the full buffer of data until you come along and read it.   In a Continuous task, when the buffer fills up, it *wants* to put the next sample into the buffer position that's holding the first sample.  By default this is illegal so it will instead error out the task in the background.  When you come around later to read it, it will return the task error but no data at all.

    This could happen if there's too long a time between starting the task and trying to read data from it.

 

 

-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.
0 Kudos
Message 2 of 3
(3,214 Views)

I am facing the same problem. But when I give a fixed sampling rate in the read function, it gives the number of samples same as sampling rate, with continuous acquisition mode. I changed nothing else.

 

0 Kudos
Message 3 of 3
(2,542 Views)