Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Synchronizing analog output and counter input in USB-6211(OEM) using Python

Solved!
Go to solution

Yeah, sorry, I didn't review closely enough to remember that you *did* mention the DAQmx warning already.

 

I scrutinized the code closer and confirmed some further things you did *right* (thus reducing the available suspects).   One was to make sure to set auto-start=False on the AO task (so it wouldn't start prematurely when you write data to it.  I think False should be the default anyway, but it's good to make sure by setting it explicitly).  The other is simply that you were careful to start the counter task *before* starting the AO task.  That's also very important.

 

I guess I'd start doing some desperate things that *shouldn't* be needed.  For example, put a fixed delay time between waiting for the AO task to be done and reading the counter samples.  Maybe also a fixed delay between starting the counter task and starting AO.  You could also try configuring the counter task for continuous sampling (though actual sampling should still stop after 450 AO sample clock cycles because it'll still be a finite task).

 

Sorry, there may be some simple thing about the Python API that I am just misinterpreting or failing to understand, but I'm just not seeing any other reasonable causes for suspicion.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 11 of 12
(416 Views)

Dear Kevin,

 

Thanks for your input. Currently, I strongly feel that there is some bug in the nidaqmx python module that implements period measurement.

 

I tried configuring the counter task for continuous sampling, and it again gave only 410 samples out of 450. Does this mean that the counter has missed some edges from the sample clock?

I still need to check with the fixed delay you have suggested.

 

Another thing I need to mention is that the actual code I am using is slightly different, wherein I am continuously collecting the data inside a loop during scanning, so that I can plot it live. Since I wanted to show you a simpler code, I wrote an alternative program to show here, where the whole counter data is collected only after the scan. I had verified that this code worked with edge counting, and since the only difference between the two code was the way I was collecting the counter data, I had not bothered to verify the same code for period measurement.

Unfortunately, when I tried running this code today, I found that the counter returns nothing after the scan is completed. It seems that once the scan is complete, the counter buffer is wiped clean. So, only when I am collecting the buffer data in a loop when the scan is going on, I get the 410 samples.

 

The actual code I am using is something like this:

 

from nidaqmx import stream_writers, Task

from nidaqmx.constants import AcquisitionType, TimeUnits

import numpy as np

 

taskxy = Task()

counter = Task()

taskxy.ao_channels.add_ao_voltage_chan('Dev1/ao0:1')

counter.ci_channels.add_ci_period_chan('Dev1/ctr0',units=TimeUnits.TICKS)

counter.channels.ci_period_term = '/Dev1/ao/SampleClock'

counter.channels.ci_ctr_timebase_src='/Dev1/PFI0'

 

scanrate = 100  

 

xarr = np.linspace(-3,3,50)

yarr = np.linspace(-3,3,9)

t = 10 # default timeout = 10 seconds
sample = getxyarray(xarr,yarr)  # this function returns the full 2xn array of points, to scan the whole X*Y area
sam_pc = np.shape(sample)[1]
total_time = sam_pc*len(sample)/scanrate
if t < total_time + 1:
    t = total_time + 2  # make sure that wait_until_done() works even when scanning takes more than 10 seconds
counter.timing.cfg_samp_clk_timing(scanrate, source="/Dev1/ao/SampleClock",sample_mode=AcquisitionType.FINITE,samps_per_chan=sam_pc)

taskxy.timing.cfg_samp_clk_timing(rate = scanrate, sample_mode = AcquisitionType.FINITE, samps_per_chan = sam_pc) 

writer = stream_writers.AnalogMultiChannelWriter(taskxy.out_stream,auto_start=False)   
writer.write_many_sample(sample,timeout=t)

counter.in_stream.read_all_avail_samp = True

counter.start()

taskxy.start()

data = -1*np.ones(sam_pc)   # counter data array having all values as -1 at the beginning

i = 0

while not taskxy.is_task_done():      # loop until the task is done

    sleep(0.5)

    buf_data = counter.read(number_of_samples_per_channel=READ_ALL_AVAILABLE)

    data[i,len(buf_data)] = buf_data

    i = i + len(buf_data)

    # code to plot the data as image

taskxy.stop()

counter.stop()

print(data)

taskxy.close()

counter.close()

 

So in this code, where the sampling is finite acquisition, I get the warning that not all samples were acquired. If I change it to continuous acquisition, I still get the same result, but without any warning.

 

As an alternative solution, I am now writing a step-scan code that can be used for long time scans, wherein I go to each point, make a single count measurement for the specified time period, and then move to the next point. 

0 Kudos
Message 12 of 12
(408 Views)