Adjust Counter Delay on the fly using two Counters

[Electromecha]

Hi,

I'm using the technique described here by JohnP to implement an on the fly delayed output of a hardware counter relative to it's trigger.

http://forums.ni.com/t5/Multifunction-DAQ/Synching-AO-and-Counter-Output-arming-and-triggering-seque...

My system generates a hardware buffered regenerative analog output.  A continuous synch pulse is generated using Cntr0 on the same PCI-6221 and is triggered off of the AO.StartTrigger in order to synchronize the Cntr0 Pulse with each generation of the AO wavefrom.  Then Cntr1 is configured in retriggerable single sample high/low time mode and triggered off of the Cntr0.InternalOuput.  By changing the low time of Cntr1 I can effectively implement an adjustable on the fly delay on the ouput of Cntr1 relative to Cntr0 and hence relative to the AO waveform.

The technique works great for rational values of drive period, (i.e.  1.258 s), but when an irrational waveform period is commanded such as (0.59405940594059405940594059405941 s) the Cntr1 delayed pulse drifts relative to Cntr0.  Meaning if you start with a 0 second delay between the two counters, the output pulses are initially aligned but then Cntr1's output will rapidly drift such that the two counter outputs are no longer synchronized.

Clearly there is a rounding error occuring but I can't seem to correct it.  I changed the Cntr1 high/low mode from time in seconds to clock ticks thinking I'd have better resolution but still see the same drift with irrational drive periods.  I also suspect that by calling the Cntr1 property Cntr.RdyForNewVal in a loop the hardware determinism of my system is compromised.

Our current solution is to simply coherce the user commanded AO drive period to rational values.

I'm mainly wondering if this problem can be corrected or if it's just a limitation of the method using two counters to create an on the fly counter output delay.

Thanks,

Steve

[Frank-L]

Hello Steve,

I am having some trouble understanding what you mean by changing the drive period, as these were not values specified in the original code presented by John P. If you are able to provide your code below as well as the values that you have set up for sample rate, size, etc will help us to better understand and solve the problems. Thanks!

Frank L.

[Electromecha]

Frank,

Thanks for the reply.  Sorry to be confusing. 

The Period is the inverse of the output Frequency of Cntr0.  You're correct, with the DAQmx create channel VI, one specifies the output in Frequency of Hz, not in Period of seconds.  It just so happens that if the Period (or Frequency) of Cntr0 output is irrational (i.e. 0.59405940594059405940594059405941 s = 1.68333333333333333333333333333333 hz) then the Cntr1 offset (delay from Cntr0.InternalOutput implemented by adjusting low time on Cntr1) will drift relative to Cntr0.

My current workaround to coerce the frequency and hence period to rational numbers is sufficient.

Thanks for your help and time.

[John_P1]

Hi Steve,

How are you measuring the drift?  I wouldn't expect ctr1 to drift relative to the output of ctr0, but I would expect ctr0 to drift relative to your Analog Output.

The counter output uses a divide-down of one of the internal timebases (100 kHz, 20 MHz, or 80 MHz), so if your desired frequency cannot be derived from one of these clocks it will be coerced.  The AO also uses a divide-down of the internal timebases, but it does not have the 80 MHz timebase available.  The original example fed the coerced AO sample clock rate into the counter task so there shouldn't have been any problems here.  If you're specifying the counter frequency directly, it might be coerced differently from the AO task.

Best Regards,

[Electromecha]

John,

I'm measuring the drift of the output signals (AO and Cntr1) on a daq board scanning at 5000 scans/s.

The information you provided is helpful, I wasn't aware of the divide-down on the internal timebases.  Yes, I am specifying the frequency directly to Cntr0 so this may be coerced differently than the AO. 

Where does one find these specifics on the board and various clocks?

I've attached some sample code that may be of help to future users of this technique.  The sample code outputs a continuous regenerative buffered Analog Output waveform (board hardware timed).  Cntr1 is then configured in Frequency mode and triggers off of the AO.StartTrigger in order to synch the two signals.  Then Cntr1 is configured in High/Low mode and triggered off of the Cntr0.InternalOutput.  By changing the Cntr1 low time, I'm able to get an on the fly delayed output of Cntr1 relative to Cntr0 and hence the AO.

If you have a daq board and you wire the AO and Cntr1 output signals into two analog input signals, you can see the drift when using irrational frequencies.  The sample code I provided only performs the output, so to see the signals you can simply create a continuous acquisition task in Max at 5Khz.

Thanks for you time and support.

[John_P1]

I didn't see where you're specifying the frequency of ctr0 in your code, the frequency terminal is unwired in the code you posted (it will default to 1 Hz):

My original code set ctr0 to pulse at the beginning of every cycle of the AO buffer.  To do this, I had to set the counter frequency to be equal to the (coerced) AO sample rate divided by the number of samples in the buffer.

Anyway, you can find more information about the clocks in the M Series user manual.  The Analog Output Timing section can be found on page 5-6, and the list of available signals to use with counters can be found on page 7-26.  In a counter output task, the output frequency is a divide-down of whatever signal is connected to the source (the driver will choose a timebase for you in most use cases).

Best Regards,

[Electromecha]

John,

Good catch, I lost the Frequency specification on Cntr0 when I created that subset of code.  Yes, I'm specifiying the the frequency of Cntr0 to be that of the AO frequency.  See image below.

I reattached the corrected code.  

Thanks for the info on the clocks.

Best Regards,

Steve