LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Synchronize two USB-6002 Acquisition devices

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

0 Kudos
Message 1 of 16
(2,435 Views)
  • If you only want to do one very simple task, nothing fancy, then feel free to use the Dreaded DAQ Assistant.  If, however, you want to do something even a little bit unusual, then spend a little time with the DAQmx Tutorials (which are pretty good, by the way).  I especially recommend that you do a Web search for "Learn 10 Functions in NI-DAQmx and Solve 80% of your Data Acquisition Applications" (or words to that effect).
  • Did you notice that PFI0 and PFI1 are both Inputs?  While it is a good idea to connect the two inputs, if you want to synchronize them, you need to wire these two inputs to a single output pulse.  Got anything on the USB-6002 capable of generating a digital pulse?  [Don't even think about doing this with the Dreaded DAQ Assistant!].
  • If you need to come back here for more help, please do us the courtesy of attaching your VI (or VIs, or a Zip of your entire Project) so we can see what you've done, and can provide more specific help.

Bob Schor

Message 2 of 16
(2,418 Views)

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.

Capture.PNG

Download All
0 Kudos
Message 3 of 16
(2,386 Views)

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW?
0 Kudos
Message 4 of 16
(2,379 Views)

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 ...

  • 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].
  • Make a simpler program, one that has only one device, and hence does not need to "synchronize".  Instead, think about how/if you can start the Task but have the A/D wait for a trigger.
  • What on your USB-6009 might be able to produce a trigger?

Bob Schor

0 Kudos
Message 5 of 16
(2,378 Views)

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

0 Kudos
Message 6 of 16
(2,376 Views)

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

 

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW?
0 Kudos
Message 7 of 16
(2,368 Views)

@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 http://www.ni.com/product-documentation/54461/en/).

 

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.)

0 Kudos
Message 8 of 16
(2,363 Views)

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:

Test Synch A to D.png

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

0 Kudos
Message 9 of 16
(2,337 Views)

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 😉

Message 10 of 16
(2,335 Views)