From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Synchronizing 3 PXI-4472 boards

Hello,
After reading some of the knowledge base notes, we're still having trouble trying to synchronize three boards.
Please see the attached.

I'd greatly appreciate if anyone sees the problem. Could it be that we're setting the trigger routing before the STAR clock routing?

Thanks in advance for your help,
Hunter
0 Kudos
Message 1 of 13
(3,216 Views)
Hunter,

I took a look at your VI. While it used to take some tinkering to get this going using the older "Traditional" DAQ driver (as you know), NI-DAQmx 7.4 has made multi-device DSA synchronization almost trivial in a single chassis. If you're using LabVIEW 7.0 or 7.1 I highly recommend that you download DAQ 7.4 (linked below). I've attached a screenshot of an example VI that implements synchronization, internal 4mA excitation, and AC coupling across three boards. As you can see, all of the devices can be included in a single DAQmx task. As long as one of the devices is in slot 2 of your chassis (the only slot capable of driving the star trigger), this will do the trick. The example screenshot also configures all 24 channels from the boards with the same parameters -- but could be easily modified such that each individual input could be configured independantly. If you're using LabVIEW 6.1 or earlier you'll have to stick with Traditional DAQ.

I highly recommend updating to DAQ 7.4 (as long as you have LabVIEW 7+). If this is not an option, please let me know.

Click Here to Find the Latest DAQ Driver


Best Regards,
Alan L
Applications Engineer
National Instruments
0 Kudos
Message 2 of 13
(3,200 Views)
Sure appreciate your note, Alan.

Definitely sounds like using new driver is the way to go, in the long run. At this point, however, we're in a time crunch and we really need to stay with tradional stuff for our current efforts.

We've been using this acquisition algorithm for a while, and I only started to question this synchronization when I was looking at a big waveform data file that was recorded on channels across all 3 boards. We're using these waveforms to do a new analysis where synchronization is important. I just happened to check the t0 times for each of the recorded channels. While all of the channels on each board have the same t0, there are differences between boards!!! See the attached .JPG.

So, is this really a synchronization problem or am I making something out of nothing?

Look forward to hearing from you,
Hunter
0 Kudos
Message 3 of 13
(3,193 Views)
Hunter,

Thanks for the screenshot! The good news is that what you are experiencing is perfectly normal. The reason for this skew is that you must use a PXI-Trig line (or RTSI as it's referred to in Traditional DAQ) to start each board. The PXI Trig lines are wired in series from slot to slot, so there will be a time delay between each board as the pulse propagates down the line (resulting in a t0 difference). This is not a significant source of error, however, because every subsequent sample conversion is controlled by the Star Trigger which, as you know, has equal trace lengths between slot 2 and all of the other devices (unless you're using an 18-slot chassis). Even with the star trigger, the first board will make its conversion several nanoseconds before the others since it is the source of the pulse -- but given that the 4472 only samples at a rate up to 102.4KS/s, several nanoseconds is negligible.

You've done everything correctly.

Please let me know if you have any further questions!

Thanks again,
Alan L
Applications
Message 4 of 13
(3,180 Views)
Hello, Alan

Well, I'm sure glad that we had this discussion!!! Thanks so much for clearly things up.

I guess to avoid future confusion, I ought to set all the t0's to one value before I save the waveform file.

Will I encounter the same t0 difference when I upgrade to DAQmx 7.4 someday?

All the best,
Hunter
0 Kudos
Message 5 of 13
(3,163 Views)
Hunter,

I'm glad to hear that I've helped to clear up any confusion!

One last thing, though -- I don't recommend changing the t0's of the other boards. As I mentioned, there really is a delay in the start times between each board and t0 should reflect this correctly. While that means that your master, and one of the other boards, will have a few samples earlier than the last, each sample which corresponds to the same time (t0 + offset) was actually taken simultaneously.


Thanks again!

Regards,
Alan
Message 6 of 13
(3,151 Views)
Ohh....I'm glad you cleared that up as well.

So, if I'm interested in doing analysis on the same data points at a particular time, I could simply do the following:
1. Find the board with the lastest t0
2. For the waveforms on boards with earlier t0's, truncate these earlier samples.

Is that correct? Any suggestions on the best way to do this?
I really have to be analyzing the same points in time during my post-processing analysis of the waveform data file.

Thanks for your continued help.
Hunter
0 Kudos
Message 7 of 13
(3,147 Views)
Hunter,

I've done some additional digging to verify. In fact, the t0 being returned in the waveform is a software approximation (our scopes / high-speed digitizers actually return hardware timestamps). In actuality, thankfully, all of the datapoints returned by all three 4472s are in-sync with one another. This means that you can just use the t0 from the master if you want an absolute time associated with all of the data -- though most analysis doesn't require it. To make a long story short, you won't have to truncate any samples.

I apologize for any confusion -- please let me know if you have any further questions!


Thanks again,
Alan
Message 8 of 13
(3,137 Views)

@Alan_L wrote:
I've attached a screenshot of an example VI that implements synchronization, internal 4mA excitation, and AC coupling across three boards. As you can see, all of the devices can be included in a single DAQmx task. As long as one of the devices is in slot 2 of your chassis (the only slot capable of driving the star trigger), this will do the trick. 

Reviving this thread - is this still valid in 2023? I have trouble adding two NI-4472, which are now considered legacy hardware, to one DAQmx task. I simply followed the provided screenshot, I connected one of the modules to 2nd slot while the other is in slot 7 and I get the error -89136 (route cannot be satisfied because the hardware doesn't support it) on DAQmx Start Task: 

Property: SampClk.Timebase.Src

Source Device: PXI1Slot2

Source Terminal: SampleClockTimebase

I have never run into synchronisation problems so far..

0 Kudos
Message 9 of 13
(710 Views)

I don't use the 44xx series of boards, but have you tried routing the SampleClock itself, rather than the SampleClockTimebase used to derive it?

 

 

-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? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 10 of 13
(701 Views)