synchronizing two USB-6251 boards

[DAQ question]

I am attempting to synchronize two USB-6251 boards on one computer.  I use Matlab DAQ (not LabView).  I should be able to set the clocksource on one board to "externalclocksource" or "externalsamplectrl" and hook up the PFI2 from one to the other board and use that as the clock for both boards.

 For some reason, I'm not getting any signal out of the PFI2 channel and the synchronization is not working.  When the boards are running, should I be able to read the sample rate or clock source from the PFI2 channel?  Am I misunderstanding something?

Thanks!

[BrowningG]

Hello DAQ question,

Welcome to the NI Discussion Forums!  From your post it looks like you would like to synchronize two USB-6251 devices using their sample clocks.  This forum post involves some great information on how to get started with using DAQmx.  To perform sample clock synchronization, there are several steps to follow. 

1. Choose one device to be the master device and one to be the slave.  The master device will handle the timing and starting of both devices.

2. On the master device you will need to export your sample clock to a PFI line so that it can be wired to the slave device.  Use the function (from the DAQmx C Reference Help) DAQmxExportSignal.  This function allows for you to export a hardware signal to a PFI line that you specify.  You can then wire this PFI line to your slave device. 

3. On the slave device set the sample clock source to be the PFI line that has the master device’s sample clock attached to it. 

4. Start the slave task first, then the master task.  This will ensure that the slave task is waiting for the sample clock from the master device so they both start when the master starts.  If you start the master task first, the slave and the master will be clocking at the same time but the master task could have a few extra samples. 

I hope this helps, post back if you have any more questions.  Also, check out this tutorial for an explanation on how the different synchronization schemes work with M Series devices. 

[DAQ question]

Thank you for the suggestions.  I've read through all the material and attempted to use the suggestions and posted  in the links you sent. 
Unfortunately, I have not been able to get any of it to work.  I've been corresponding with a Matlab tech and their final word at the moment is that it is not possible to synchronize two boards using a board-generated clocksource. 

I would be so happy to hear that there is another way.

[BrowningG]

Hello DAQ question,

The term synchronization depends on how tightly synchronized you would like your two boards to be synchronized.  The simplest form of synchronization is to have to tasks running at the same rate that are both started at the same time.  Reference clock and sample clock synchronization provide a much tighter method to synchronize boards by sharing clocks and triggers.  For your USB devices, the tightest synchronization you can get would be to share a sample clock between the two devices.  One way is to export the sample clock from one board to be used as an external sample clock for the other board.  You could also try importing an external sample clock to both devices from a function generator or the onboard counters.  This way both devices would have the same external sample clock. 

For example, create a counter output task on one device.  This task will output pulses continuously on one of the PFI lines of the device.  Then, create the AI tasks for both boards that use an external sample clock.  You can then wire the PFI line that is outputting pulses to the sample clock input terminal you specify for both AI tasks.  This will provide sample clock synchronization. 

You could also just have both tasks run at the same rate and start them at the same time.  This will not be the tightest synchronization, but it is the simplest. 

[DAQ question]

Thank you for the suggestions. For this particular application, the samples must be precisely synchronized (starting the daq on the boards at the same time is not sufficiently synchronized; running a software trigger takes up an additional channel which forces me to sample at too low a rate on the other channels). 

The goal of sending a counter out on one of the PFI lines is precisely what I would like to do..and in principle it should work...but I can't get it to work in Matlab.   After reading through the links in this thread, I tried programming Matlab using the code posted when Matlab was not supporting NIDAQmx, and that code and those libraries no longer work (for me, anyway).  The Matlab techs I've been working with have told me that it is not possible to do this.  I'm finding it rather hard to give up on this one, because it should be very straightforward.  The problem is coming up with the code in Matlab to tell the NI board to send the clocksource out of the PFI line..  It's no problem telling Matlab to read a clocksource - the problem is telling the board to send a clocksource out of a PFI line.

[BrowningG]

Hello DAQ question,

If you want to program with the DAQmx API directly (which it looks like you do) you can use the DAQmx DLL and the required header file.  The required header file is found at <National Instruments>\NI-DAQ\DAQmx ANSI C Dev\Include\NIDAQmx.h.  The required DAQmx DLL can be found <WINDOWS>\system32\nicaiu.dll.  Then, you can use the NI-DAQmx C Reference Help for more information on each of the functions contained therein. 

Since you are using two USB device you need to export the sample clock to a PFI line to import it.  The function to use is DAQmxExportSignal().  This function routes the signal specified by signalID to the desired output terminal.  More information on each of these functions can be found in the DAQmx C Reference Help.  The format for the terminal name will be /Dev1/PFI0.  If the first slash is missing then you could get an error.  If your master device is Dev1 then you will route the AI sample clock to /Dev1/PFIx (where x is the desired PFI line) and your slave device (I assume Dev2) will use /Dev2/PFIy (where y is the input PFI line on Dev2).  This is how you send a clock signal from the master device to the slave.   

Message Edited by BrowningG on 08-21-2008 05:37 PM

[DAQ question]

Hello again,

So, first some good news --  Matlab 2008b now has the code to allow you to send a clocksource signal out from a board and receive it on the other.  This relieves some of the complicated aspects of trying to control the boards with both sets of software (NI and Matlab). 

However, I still have a question - and perhaps it reflects a fundamental lack of understanding about the process (although the links above have been very helpful).

If I set up the system with a master and slave board, synchronized with the clocksource signal coming from the PFI line on the master board and running to the PFI line on the slave board, there still is a time offset (0.2 ms) between the two boards.  

First, is this as good as it gets?

Second, if this doesn't seem good (it doesn't seem good to me), is it because of the trigger system I'm using?  Specifically, I am using a trigger to stop the DAQ and collect data PRIOR to the trigger.  So, I first stop the slave board and then the master board.  The time for each of these boards ends at zero and runs negative back to the start of the signal.  Doesn't this mean that all the hard work of synchronizing the boards via the clocksource is undone by the trigger not being simultaneous?  

Many many thanks for your help (and patience!).

[Paul_C.]

Hi DAQ Question,

Browning has moved on to another position and I will do my best to answer your questions.  The offset should be much less than 0.2ms.  The delay in this method is simply the propagation delay of the wire between the master and slave device and some propogation delay through some wiring inside the devices.  This can be aproximated by calculating the distance divided by the speed of light.  This is on the scale of nanoseconds.  A quick test to ensure things are working correctly would be to connect the same signal (such as a sine wave) to both DAQ cards and verifying that they appear at the same on both devices.  By sharing the sample clock to the slave and starting the slave first, you ensure that both the slave and master start at the same time and use the same sample clock to acquire samples.  This works because the slave sits and waits (after starting) for a sample clock edge to come before it will actually acquire data.  The sample clock edges aren't sent until the master starts.  The stop trigger is irrelevant unless you're comparing samples acquired on the master after the slave has stopped.  For these samples, there is no slave counterpart and thus they cannot be used.  If you compare the first sample of the master and the slave, they should be very close to the same (within accuracy, quantiziation, and nanosecond time delay error).  I'm not sure about the time scale of the signal or how you are using a "stop" trigger to stop the acquisition.   When you say stop trigger, are you referring to a reference trigger with entirely pretrigger data?  If so, my above answer still applys.  The pretrigger samples on the slave and master should be acquired at the same time if you're sharing the clock.  

I hope this helps,

Paul C.