The overall running time taken for "single pulse" and "multi-pulses" generation for counter pulse train generation

[Morty.Chen]

Hi, I have a question regarding the overall time to finish the "pulse generation" application. When samps_per_chan == 1, it only taks half a period.

When samps_per_chan is larger than 1, it will take "samps_per_chan" cycles. Is this expected? I thought it would take "samps_per_chan-0.5" cycles since the first pusle doesn't have "low_period", regardless of the value of samps_per_chan.

I use the following code to measure the time consumption. （Device: USB-6361)

task_cnt = nidaqmx.Task()  task_cnt.co_channels.add_co_pulse_chan_freq(counter=f"/{target_device_name}/ctr0",
                                                units = FrequencyUnits.HZ,
                                                freq = 1)
task_cnt.timing.cfg_implicit_timing(sample_mode=AcquisitionType.FINITE, samps_per_chan=1) # It takes 0.5s
task_cnt.timing.cfg_implicit_timing(sample_mode=AcquisitionType.FINITE, samps_per_chan=2) # It takes 2s, why not "1.5s"!
task_cnt.timing.cfg_implicit_timing(sample_mode=AcquisitionType.FINITE, samps_per_chan=3) # It takes 3s, why not "2.5s"!

    
task_cnt.start()
start_s = time.perf_counter()
task_cnt.wait_until_done(10)
end_s = time.perf_counter()
print("{0} s passes<cnt done>".format((end_s - start_s)))

[Morty.Chen · Accepted solution]

I think the following diagram shows the timing of task done for counter pulse train generation.

[Kevin_Price]

No, I think the correct explanation is something a little different.

1. NI's counters define a pulse to start with their time in idle state and end with their time in pulse state.  Those are typically low and high respectively.

2. But there's another non-obvious and oft-overlooked detail about pulse generation that comes into play:  the very 1st pulse (which is also the *only* pulse when generating just 1) uses the 'initial delay' setting *instead of* the normal idle time.   

3. Further, the default value for initial delay is very very small , just 2 cycles of the timebase used to drive pulse timing.  Unless you use an external clock, this will likely be just 20-25 nanosec.

4. In your code you define your pulses in terms of frequency and duty cycle, but since you don't explicitly define the duty cycle, it uses the default of 0.5.  With a freq of 1 Hz, you can expect 0.5 seconds of idle time followed by 0.5 sec of pulse time for all pulses except the first one.  That one should have 20 nanosec idle time followed by 0.5 sec pulse time.  (20 nanosec b/c your X-series device has a 100 MHz timebase).

With all this in mind, the result I think you *should* see is more like:

Pulses     Time (sec)

   1                0.5   (technically, 0.50000002, but you can't resolve that with software time queries)

   2                1.5

   3                2.5

But apparently that's not what you *do* see.  This seems more like a problem (dare I say bug) in the way the driver determines "done-ness".   I remember running into a possibly-related anomaly many years ago regarding the DAQmx property "pulse done" (see partially-related thread).  This situation is different, but there's some precedent for quirks in how "done-ness" is determined.

    I also recall a more recent thread that seemed to indicate that attempts to query done-ness would consume considerably more time than expected.  Not on the scale of the 0.5 sec anomaly we're discussing, but again, another precedent for quirks.

So you're right that there's an anomaly here and you used good reasoning to try to figure it out, but some non-obvious things I know about counters makes me think there's a different explanation and possibly a bug (or at least a quirk, "bug" tends to be a dirty word to suggest) deep inside DAQmx.

Comments from anyone inside NI?

-Kevin P