Two PCI 6602 Connected by RTSI, Unable to Synchronize Clocks

[Stumped]

Hi,

I have two PCI 6602 timer cards in the same PC connected by an RTSI bus cable.  I want to set up a pulse sequence on all 16 channels, but with a 4 second delay from the trigger to the pulses (as in the attached VI) pulses from different cards become desynchronized by 40us, which is unacceptable for my application.

I have tried using the method outlined in this thread, but to no avail.  Any help would be much appreciated!

Thanks!

[Chris_D]

There will be some delay between the master timebase and the exported signal that arrives on the second device. There are many factors that can come into play with this delay such as the type of wiring that you use, cable length, and outside noise.

You could try to have each 6602 use their own timebase and start generating at the same time using the arm start trigger. This is a tricky application because there are many things that can affect the delay.


Message Edited by Chris_D on 01-23-2008 05:37 PM

[balki]

You can synchronize your counters along the same lines as AI channels are synchronized in this example: C:\Program Files\National Instruments\LabVIEW 8.5\examples\DAQmx\Synchronization\Multi-Device.llb\Multi-Device Synch-Analog Input-Finite Acq-Ext Dig Start.vi

You should just have to change the voltage channels to counter channels and the start trigger to an arm start trigger.  Do you see your channels drifting after they've been running for a while?  Does it change as the program is running?

[Stumped]

Thanks for the replies!

Chris_D: Thanks for the explanation.  When I have each 6602 use its own timebase and send a signal to /Dev1/PFI0 and /Dev2/PFI0 simultaneously at t=0 to trigger the sequence,  by t=4sec channels that are on different  6602s are still desynchronized by an unacceptable amount.  So unless I am misunderstanding what you mean by "start generating at the same time using the arm start trigger" this won't do the trick.

balki: This example vi looks promising, but seems not to work because the 6602 does not support the RefClk.Src property?  Yes, the longer the "initial delay" property for the two pulses, the greater the drift.  And, no, the amount of drift does not change each time the program is run.  I get roughly 10us of drift per second of initial delay time.

[balki]

Attached is a VI of what I was talking about before.   The other menu selections in the VI show different synchronization schemes required by different DAQ board families.  You were right, you can't use RefClk in the situation, you have to share the master timebase, in this VI the "E Series, S Series" synchronization scheme.

Let me know if you are still seeing the drift when running this VI.

[Stumped]

Thanks, the vi works now, but I still see the drift.  I set up 20us (high time) pulses on both the master and slave device with no initial delay.  The pulses start off as simultaneous, but by end of the 1000 samples (~10 sec) there is an 80us difference between the starting times of the pulses on each channel 😕

[balki]

My bad.  As it shows in the NI-DAQmx help under NI-DAQmx Help->NI-DAQmx Device Considerations->Synchronization->Synchronizing E Series Devices:

#####################################################################################################

Counter Tasks

You cannot synchronize counter input applications performing period, frequency, pulse width or semi-period measurements in the same sense as analog input or output applications. These types of counter input applications cannot be programmed to make their measurements at the same time because the signals being measured themselves determine when the measurements are made, and there is no reason to set up multiple devices to measure the same signal. You also cannot use Start Triggers for counter input applications.

You can, however, ensure that all counters are using the same timebase for their input measurements by sharing the CI Counter Timebase signal. Program all devices to use the same signal (usually the 20MHzTimebase from one of the devices) as their CI Counter Timebase. More generally, one device can be queried for its CI Counter Timebase source and that terminal can be set as the source of the CI Counter Timebase for the other devices.

If you are synchronizing buffered counter input applications performing edge counting, you can do so by sharing the Sample Clock. The Sample Clock must be externally supplied to one of your devices. The other synchronized devices are programmed to use this device's CtrnGate signal as their Sample Clock, where n is the number of the counter.

If you are synchronizing pulse generation counter output applications, you can do so by sharing the CO Counter Timebase and Start Trigger signal. Program all devices to use the same signal (usually the 20MHzTimebase from one of the devices) as their CO Counter Timebase. More generally, one device can be queried for its CO Counter Timebase source and that terminal can be set as the source of the CO Counter Timebase for the other devices. Program all devices to use the same signal as their Digital Edge Start Trigger. This is typically the CtrnGate signal from one of the devices, where n is the number of the counter.

#####################################################################################################

I've updated my attachment to show how to do this.  You have to explicity set the rate and source to be the 20MHz timebase, because it will try to use the 80 MHz timebase by default (usually just used internal to a single board) but you can't export the 80 over RTSI.

Hopefully that makes your drift go away.  I set it up here and it all seemed to look fine.

Message Edited by balki on 01-30-2008 10:56 AM