Different Edge Count results for DI/SampleClock and DO/SampleClock

[Morty.Chen]

Hi, I have a question regards the different Edge Count Result for DI/SampleClock and DO/SampleClock Counts. (Device: USB-6361)

For the following code snippets, samps_per_chan for AO and DO are both set to 10. However, the edge counts results for DO/SampleClock is 11 which is one more than the result for AO/SampleClock.

Could anyone help me and explain this kind of results?

task_ao = nidaqmx.Task("Task_Analog_Output")
task_ao.ao_channels.add_ao_voltage_chan(f"/{dev_name}/ao0", min_val=-2.0, max_val=2.0, units=VoltageUnits.VOLTS)
task_ao.triggers.start_trigger.cfg_dig_edge_start_trig(f"/{dev_name}/Ctr0InternalOutput", trigger_edge=Edge.RISING)
task_ao.triggers.start_trigger.retriggerable = False
task_ao.timing.cfg_samp_clk_timing(ao_sampling_rate,
sample_mode=nidaqmx.constants.AcquisitionType.FINITE,
samps_per_chan=10
)

task_do = nidaqmx.Task("Task_digital_output")
task_do.do_channels.add_do_chan(f"/{dev_name}/port0/line0:1", line_grouping=LineGrouping.CHAN_FOR_ALL_LINES)
task_do.timing.cfg_samp_clk_timing(rate=ao_sampling_rate,
                                       sample_mode=nidaqmx.constants.AcquisitionType.FINITE,
                                       samps_per_chan=10
                                       ) #  source="/Dev1/100KHzTimebase")

task_do.triggers.start_trigger.cfg_dig_edge_start_trig(f"/{dev_name}/Ctr0InternalOutput", trigger_edge=Edge.RISING)
task_do.triggers.start_trigger.retriggerable = False # If retriggerable is True, not task done


    task_edge_cnt1 = nidaqmx.Task("Task_Edge_ao_Cnt")
    task_edge_cnt_chn1 = task_edge_cnt1.ci_channels.add_ci_count_edges_chan(counter=f"{dev_name}/ctr1")
    task_edge_cnt2 = nidaqmx.Task("Task_Edge_do_Cnt")
    task_edge_cnt_chn2 = task_edge_cnt2.ci_channels.add_ci_count_edges_chan(counter=f"{dev_name}/ctr3")

    task_edge_cnt_chn1.ci_count_edges_term = "/Dev1/ao/SampleClock"
    task_edge_cnt_chn2.ci_count_edges_term = "/Dev1/do/SampleClock"
    print("CI information:")
    print("ci_count_edges_term", task_edge_cnt_chn1.ci_count_edges_term) # default: /Dev1/PFI3
    print("ci_count_edges_term", task_edge_cnt_chn2.ci_count_edges_term)  # default: /Dev1/PFI3

    task_edge_cnt1.start()
    task_edge_cnt2.start()
    task_do.start()
    task_ao.start()


        print("edges cnt1 ao returned value is ", task_edge_cnt1.read()) // return 10
        print("edges cnt2 do returned value is ", task_edge_cnt2.read()) // return 11

[Kevin_Price]

I'm surprised by this, but it looks like you've configured things appropriately to make the result valid. 

Sorry, I don't have hardware to test with, and this kind of subtlety isn't the sort of thing simulated devices are meant to check out.  Also, I only program in LabVIEW and am no help with specific text API syntax.  Further, while LabVIEW makes my following suggestion about parallel execution very simple, I don't know what you would need to do in your language.

I would operate the Ctr0 pulse train task, which you use as an external sample clock, in parallel with the code you show here.  I would similarly set up Ctr1 and Ctr3 (which count sample clocks) in a different piece of parallel code. 

1. Start up the code for Ctr1 & Ctr3. 
2. Do *NOT* start the code for Ctr0.
3. In debug mode, start stepping through the AO & DO code while monitoring the Ctr1 & Ctr3 values. Even after executing both of their Starts, both counts should still be 0 because you haven't started up Ctr0 yet to supply a sample clock.  
4. Only then should you go ahead and start the Ctr0 task
5. Continue stepping through the AO & DO code until you clear the tasks.

Hopefully, this will let you see where the extra DO sample clock count happens.  Is it during the config?  Does it happen at Start (even in the absence of an actual sample clock signal)?  Or does it happen during clean up?

-Kevin P

[Morty.Chen]

Hi Kevin Price:

Thanks for your replay.

Actually, I also route "do/SampleClock" and "ao/SampleClock" to PFI ports and then use oscilloscope to check the waveform. Both have identical 10 pulses. I have oscilloscope to do some experiments. Maybe I will try route other signals to help figure out what's going on. Do you have any suggestions?

[Morty.Chen · Accepted solution]

Hi, Kevin Price:

Digital Output Task will generate a "Sample Clock" pulse (1->0->1) when it goes to TASK_COMMIT state. Thus, if I starts the task edge cnt after the following statement, edge count result will change to 10 as well.

It's still a mystery why a sample clock pulse will be generated for DO task upon transitioning to "TASK_COMMIT" . 

task_do.control(nidaqmx.constants.TaskMode.TASK_COMMIT)

[Kevin_Price]

That's a surprising result I don't recall hearing about before.  Thanks for posting what you found!  And glad you have a workaround available.

This seems like unexpected behavior to me -- wonder if it's some kind of bug or whether there's a different explanation (maybe related to latching output states during the commit?).  Hopefully someone from NI comes along with clarification...

-Kevin P