07-24-2018 06:23 PM
Hello everyone,
I have two USB-6002 data acquisition devices and I want to synchronize them. What I have found so far is that I need to connect these two physically using PFI0, and PFI1. Therefore, I have connected PFI0 on one device to PFI1 on another device. I'm using DAQ Assistant for each of the devices and showing the outputs on two different waveform graphs. However, I cannot find how to synchronize them. I click on DAQ Assistant and go to properties and click set PFI0 as start trigger for one of the devices but I don't know how to give PFI1 output on one device to this PFI0 on the other device.
I would really appreciate if you can help me.
Best Regards,
Mahdi
07-24-2018 07:48 PM
Bob Schor
07-27-2018 03:28 PM - edited 07-27-2018 03:28 PM
Thank you very much Bob for your response.
I changed my program and I'm not using DAQ Assistant anymore. Based on the YouTube tutorial (https://www.youtube.com/watch?v=g_8jiKuKeDI&list=PLB968815D7BB78F9C&index=21) I attached PFI0 on one device to PFI0 on another device and did the same for PFI1. However, I keep getting an error that says "Requested sample clock source is invalid.". My program is attached to this post.
07-27-2018 04:28 PM
For many devices when viewing them in MAX (NI's Measurement & Automation Explorer), there is a tab for "Device Routes" found at the bottom of the window. I didn't get one just now for a *simulated* USB-6002, perhaps you have one for your real devices though?
If so, you can check to see which specific pins are *allowed* to be routed for use as an AI sample clock. On most of the desktop boards I typically use, I can use any PFI pin I choose. But I know there are some older or lower cost boards that are less flexible for routing. Chances are, there will be at least one specific PFI pin that's allowed to be used as a source for a sample clock signal. But maybe only that one.
-Kevin P
07-27-2018 04:33 PM
Much nicer. Unfortunately, my hardware is at work, and I'm at home for the weekend (hmm, I may have a myDAQ somewhere around here ...). You're getting closer ...
Bob Schor
07-27-2018 04:35 PM
Ah, I just saw Kevin Price's comment. I advise against using PFIx as the clock -- leave the Sample Clock alone, it is fine. Use it as the Trigger.
Bob Schor
07-27-2018 06:36 PM - edited 07-27-2018 06:38 PM
I'm going to disagree with Bob just a little bit.
What I see is that your upper task is meant to be the master. It's configured to export its sample clock and its start trigger to PFI pins 1,0. These are physically wired to the other device's PFI pins 1,0 to link them.
The lower task is meant to be a slave task which is configured to use the signals at PFI pins 1,0 as its sample clock and start trigger. You've properly set up the right dataflow sequencing to make sure the slave task starts first to be ready for the master task's signals when it starts just a little later. All this looks fine in theory, we just have to figure out which PFI pins your particular device allows you to use for this signal sharing.
So now, the timing signals. If you're only going to run your task for a short time, then I'd agree with Bob that it'd be sufficient to share *only* the trigger signal while letting each device generate its own sample clock.
Where my thoughts diverge is this: no matter *how* long you're going to run, it'd be sufficient to share *only* the sample clock. And unless you're only running for a pretty short time, it'll be *better*.
Each USB-6002 device has its own internal timebase with an accuracy spec of 100 parts per million. That's 1 in 10000 or 1 msec per 10 seconds.
If each board generates its own sample clock at your 1000 Hz rate, then samples you get from the two boards could be skewed by as much as 1 full sample (1 msec) for each 10 sec of acquisition time. The longer you run, the more the two datasets get skewed.
If you share a sample clock *signal*, you won't develop any of this growing skew. And a shared sample clock will serve to start the tasks' sampling simultaneously like a trigger would have. Even though you start the slave task first, it can't do any sampling until it gets the first sample clock signal from the master. So they're forced to start in sync and *stay* in sync.
-Kevin P
07-27-2018
07:11 PM
- last edited on
11-26-2024
05:00 PM
by
Content Cleaner
@Bob_Schor wrote:
You do realize, don't you, that PFI0 and PFI1 are inputs, don't you? Does it make sense to run a wire from an Input of one device to the corresponding Input of the second device? [Hint -- a two-letter answer].
Small clarification here Bob- PFI stands for "Programmable Function Interface". PFI lines are meant to be configurable as both inputs and outputs. Sharing triggers and clocks is one of the main tasks for PFI lines to accomplish (see https://www.ni.com/en/support/documentation/supplemental/18/features-and-differences-of-ni-multifunc...).
Sharing triggers vs. sharing clocks doesn't have a "right or wrong" answer, though I'd tend towards sharing clocks for the same reason Kevin mentioned. When you share triggers by themselves, you can have drift over any significant sampling period, but if it's a very noisy environment you could end up getting extra/skipped clock pulses.
Also, to address OP's question- you don't need to share BOTH a trigger AND a sample clock if you're just doing one task. Route Dev1/aisampleclock to the PFI pin on your master device and select PFIx as your sample clock source on your slave device. aisampleclock doesn't output anything if the AI isn't running; it just starts outputting when the task actually starts up (in my experience... I could be mistaken though and would love to be corrected if I'm wrong! There isn't much documentation on the aisampleclock source that I have seen.)
07-30-2018 10:41 AM
Kevin and Bert both make excellent points, and I appreciate their additional corrections of some of my mis-impressions.
I can "blame my background" a little for this -- my first "serious" LabVIEW Project involved running an Experiment under the control of a PXI chassis that had a single Timer unit providing all of the timing information for the various A/D, D/A, Digital I/O, and other boards in the chassis.
One question that I had (for myself) was the nature of using a PFI(nterface, not Input) line as a Trigger -- if you are doing Continuous A/D, do you need only one Trigger, or one Trigger per set-of-samples? So I wrote a little test, using a USB-6002 and USB-6009. The USB-6002 had a 1 channel continuous A/D task of 100 samples at 1 kHz, while the USB-6009 had a 3-channel continuous A/D task of 100 samples at 1 kHz. I wired PFI0 of both devices to the DO0 channel of the USB-6002, and used a "Go" Boolean Push Button to trigger a "Do Once" Event Loop to create a single pulse. A Stop Button was also added to stop the two A/D Loops. Here's the code:
When the Program starts, nothing appears to happen until the Go button in pushed. At that time, both loops start acquiring, the two Charts start filling, and everything keeps running until the Stop button is pushed. So a single Pulse will start two separate Continuous Acquisition signals in two separate Devices.
Bob Schor
07-30-2018 10:49 AM
Good info Bob. Did you configure the triggers somewhere other than in that code?
Also... when you wire clock sources across physical devices, make DARN sure you get a good digital ground run between the cards in addition to a shield line grounded at one of the ends. Ask me how I know this 😉