PCIe-6321 DAQmx Python: Counter Channel With Array of Pulse Times

[whiz.eram0]

Hi Everyone,

I was trying to get my board to output pulses of fixed times (both high and low) that are set by an array.

I was able to get this working easily via software timing, but I need it to work with hardware timing and I have reached a roadblock to which I'm not sure whether there are limitations to the actual board that prevent me from doing this.

The current error I have is:

"DaqError: External sample clock source must be specified for this application.
Unspecified Property: DAQmx_SampClk_Src" 

Status Code: -200303

However, I would just like to use the onboard clock as my sample clock for this purpose instead of using an external one, and the documentation for this function says that the source property should be left blank to achieve this.

Documentation: https://nidaqmx-python.readthedocs.io/en/latest/timing.html See "cfg_samp_clk_timing" in particular.

Board: PCIe-6321

Is it just not possible to use the onboard sample clock for this process or does it seem likely that this can be worked around?

[Kevin_Price]

I can't help with the Python syntax, but I think you need to focus on using "Implicit" timing when you make your call to configure task timing.

-Kevin P

[whiz.eram0]

Hi! Thanks for the response. I understand that implicit timing works, but that would be using software timing for this task.

I need to be able to use hardware timing for this which is why I am specifying sample clock timing. I was just curious if that would be impossible for whatever reason.

Thanks!

[Kevin_Price · Accepted solution]

Implicit timing still *is* hardware timing.  In the case of a buffered pulse output, it means that you'll generate each buffered pulse 1 time in the order defined by the buffer.  The timing for when pulses happen is *implicit* in the timing parameters of the pulses themselves.  (Note: if this is a "continuous sampling" task, when the last pulse in the buffer is done it'll wrap around back to the first one again, and so on.)

Having read the original post again, there's another direction I think you could go if you really do indeed want sample clock timing instead.

I haven't done a whole lot of counter fiddling about in the last decade or so since the X-series boards came on the scene, but I *think* they do also support buffered pulse output based on a sample clock.  In that scenario, I would expect the operation to go like this:

1.  I'm actually not sure if the 1st pulse in the buffer starts generating immediately or whether it needs to wait to see a sample clock edge.

2. The 1st pulse repeats with the same timing parameters until the *next* sample clock edge, which advances the buffer to start generating pulses that match the 2nd pulse's timing.  And so on.

3.  If you're in the middle of a pulse when a sample clock edge happens (which will almost always be the case), I'd expect the pulse to finish with its own timing.  It wouldn't interrupt a pulse in order to start a different one.

4.  There's a rule in pulse generation that each set of pulse params must be used for at least 1 full pulse before you're allowed to write a different set.  I expect this carries over to sample-clock-based buffered output.  The sample clock needs to be enough *slower* than any of the individual pulses that this can't happen.

And finally after all that, there's another "catch" when it comes to counter tasks -- they can't derive a regular sample clock for themselves from the board's internal timebase.   You need to supply a sample clock from somewhere *external* to the task, like the error message said.

Typically I specify some other task's sample clock or another counter's pulse train output.  Your task will be able to use signals like those as a sample clock, it just can't derive one for itself from the internal timebase.

-Kevin P

[whiz.eram0]

Alright sounds good, thanks so much for the help!