Synchronization of Two Digital/Clock Pulse Waveforms

[Kevin Price]

Don't see the "enclosed image."
 
If both pulse trains are continuous, you'll only need 2 counter/timer channels.  I would suggest you consider an M-series board which gives you 2 counters plus a whole lot of additional future versatility.  A counter timer board would also work but is less versatile.
 
If either or both are finite, you'll need 3 or 4 counter/timer channels because a finite pulse train uses counters in pairs.  A 6601 counter board should work for your immediate needs, but a 6602 would be a better value if you can eventually use its additional capabilities.  You could also use 2 M-series boards connected with a RTSI cable.
 
Note that continuous pulse trains can have their freqs changed on-the-fly, while finite pulse trains will require a stop, reconfigure, and restart.
 
-Kevin P.

[ryan_d]

Hi Michael,


To synchronize your two pulse trains, set up a hardware start
trigger for both pulse tasks on the same PFI line. I?d check out the shipping
example that come with DAQmx (Help »
Find Examples?) located under Hardware
Input and Output » DAQmx.


As for the delay, you can set the delay in the Create
Virtual Channel VI.


Please post back if you have any questions. Have a great
day!Message Edited by ryan_d on 02-06-2008 06:02 PM

[stilly32]

Hi,
While staring the counters with a trigger to maintain synchronization is not a problem, changing them on the fly and keeping the phase\timing delay may pose a problem. Would you be changing the frequency or just the duty cycle? Basically all changes to the pulse specs that are done on the fly are software timed and not deterministic. So if you try to change both counters at the "same time" in SW, when they get updated in HW may be off and cause some skew. I'm not sure what your application is, but this may pose a problem for you. There should be a way around this - running your continuous pulse train generation, and creating a retriggerable single pulse on the second counter off of the leading edge of your first should give you what you need - you just may have to work with some settings. Do you need a pulse at that time, or just a rising edge? If you keep the frequency and vary the duty cycle, it shouldn't be in issue.
Hope this helps,
Andrew S

[Kevin Price]

I haven't used the USB boards, but I'm pretty sure the 1 MHz spec on the datasheet is in reference to the hardware-clockable digital port.  While it may not be immediately obvious, this spec is *distinct* from the timing resolution for counter / timers.  The counter timers are listed as being based on an 80 MHz timebase, just like the PCI M-series boards I'm familiar with.
 
In short, you should easily get absolute accuracy of <1 usec and repeatability that is far better than that.
 
Let's suppose your 1st pulsetrain is set at, say, the max of 2 kHz and will remain constant throughout a given test run.  Your 2nd pulse needs to be the same frequency as the 1st on any given run, but the delay may need to vary within the run.  Let's say you start with a 25 usec delay and later want to change that to a 100 usec delay.   I'll further suppose that only the rising edge of the 2nd pulse train really matters so the pulse width and the falling edge time can be chosen for convenience.
 
Here's how to do it:  As Andrew S. suggested, configure pulse train 2 as a retriggerable single pulse.  Let the rising edge of pulse train 1 be the trigger.  Configure pulse 2 in terms of low time and high time where low time is your initial desired delay of 25 usec.  Set your high time to a small usable value like 1 usec or 10 usec.  The lower you can set it, the more you can vary your low time (the delay) without wrapping across the next edge from pulse 1 and missing it.
 
Start pulse 2's task first so it's ready to be triggered when you first start pulse 1.  When you want to change your delay, simply write a new "low time" value to pulse 2's task.  Note: there's a chance that you'll need to also re-write the constant "high time" value at the same time in order to commit the change in the DAQmx driver.  I do know that for pulses defined as freq / duty cycle, you can't commit changes to duty cycle alone, you must also re-write the old freq value at the same time.
 
I don't have hw handy here to test, but this approach should work.  Note that if you can't change the pulse specs with DAQmx Write, you should be able to do it through a DAQmx Channel property node.
 
-Kevin P.