Synchronize 2 DAQ 6353 USB

[Virginia_Solomon]

In the past I used 2 NI DAQ 6353 PCIe boards synchronized by a RTSI cable and the setup I used to configure the RTSI in MAX. I used to control AI and AO from both cards.

I replaced the PCI boards with 2 USB 6353 boxes.

How can I ensure the synchronization in case of these 6353 USB boards? Can I use the same code of AO and AI channels for current USB 6353 boards as I used for my application when I had 6259 PCI cards?

Please provide me with schematics of physical connection for making sure the synchronization is ensured for the USB boards.

Thank you,

Virginia Solomon

[Nochenon233]

Hi Virginia,

USB devices don't have synchronization bus, but you could share sample clock to achieve same purpose, for more detail (including physical connection and coding) please refer to this link.

Regards

[Tepig]

Hello Virginia_solomon, you can establish the synchronization in the case of USB-6353s too,

but a code you developed may require a little modification.

On PCI board, the synchronization was established using RTSI connector but USB device doesn't have it.

You must make physical connection between two devices.

For example, let assume there are two USB devices named A and B,

<<HW>>

A/PFI0 (export sample clock) <--> B/PFI0 (wait for the clock signal)

<<SW>>

The most important thing is,

you must make hardware connection between two devices, share trigger or clock signal.

[Virginia_Solomon]

Thank Emboar for the answer.

Anyway the two USB boards (as well as in the past the 2 PCI cards 6353) they were synchronously triggered using the PFI0 port because I need all channels from the two boards to be triggered by a unique signal.

The essential thing is to have the acquired samples as well as the generated samples synchronous. So you said last sentence to share trigger (which already was planned to be shared) OR clock signal. It looks if I share only the PFI0 as trigger port does not imply my acquired samples  as well as the generated signal by AO channels being synchronous.

Should I share the clock also between the two cards? Be more specific. I would like this thing to be able to read it from NI documentation.

Virginia Solomon

[Kevin_Price]

Yes, absolutely share the clock.  Potentially, share *only* the clock and not a trigger.

If you only share a trigger, each device will make its own clock(s) from its own timebase.  The timebases are probably spec'ed to something like 50 parts per million.  Let's just suppose they differ from one another by 50 ppm which is 1 part in 20k.  Then for every 20k samples you take/generate, the two devices will have been skewed by 1 full sample.

With PCIe and a configured RTSI connection, DAQmx does a lot of the dirty work for you to share timing signals.  With USB, you'll have to do *all* the dirty work as Emboar already illustrated, including the need to physically wire from one USB device's PFI pin to the the other.

-Kevin P

[Tepig]

Thanks Kevin : )

Virginia, as Kevin explained, sharing trigger only is not enough for "Synchronization".

The measurement (or generation) start at the same time but because of jitter or clock accuracy, measurement (or generation) timing would have a gap.

By sharing clock, the measurement start at the same time and because common clock are used,

there is no timing gap.

[Virginia_Solomon]

All right, I may have here a question: the link I had it and the pictures attached were only for analog in.Is this routing clock from one board to the other valid even for analog out channels?

Don't forget that in my test I have few analog in channels which are synchronously triggered by a unique signal as analog output channels on PFI0. So for this reason for analog in I set PFI1 as the clock transfer from maser board to slave board. Should I set this clock even for analog out? Do you have similar example for analog out?

Thank you,

Virginia 

[Kevin_Price]

The routing should work the same way for AO tasks as it does for AI.   To make sure, you can go into MAX, select your device(s), and then look over the info in the "Device Routes" tab.  (The tabs are at the bottom of the right-side pane.)

I don't clearly understand the scenario you reference at the end of the last post, so not sure how to respond.

-Kevin P