Adjust Counter Delay on the fly using two Counters

Question

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

Answer 1

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.
Attachments:
Delayed Counter Pulse.zip ‏137 KB