Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Synchronization of 2 chassis cDAQ9174 and cDAQ9171

 

I can't tell from just a screenshot of part of the code for 1 of the 2 situations, but it *does* appear that you've made progress toward syncing, and may have solved it sufficiently for your needs.  And to think that less than a half hour earlier, you thought sync was unachievable without buying additional hardware!

 

Given your description, you may have gotten tripped up by a fairly common issue I've seen on the forums from people trying to sync tasks.  Even after properly configuring tasks to share sync'ed timing signals, not everyone realizes that it's *also* important to structure their "DAQmx Read" functions and signal processing to keep their data streams in sync too.

 

In your case, you've sequenced your tasks so that the one waiting for a trigger is started before the one that generates it.  That's the right strategy.  You're also reading the same fixed # of samples from each task in your loop, and the tasks are set up for the same sample rate.  This is also a good strategy to keep the data streams in sync.

 

The remaining quibble is that it appears the two tasks don't share a hardware timing signal for their sample clocks.  They appear to each generate their own internally.  Carefully reread msg 8 in this thread by Camilo and try his suggestion.  If your hardware supports it, it'll keep your tasks in sync for as long as you might need.  At least, sync to within the propagation time of the timebase clock signal.  In many practical applications, that's good enough.

 

 

-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 11 of 15
(896 Views)

I agree with Kevin. Both devices are currently generating their own clocks and they seem to be in phase probably by a fortunate coincidence, but if Windows does not cooperate, they won't be (we don't really have a way to ensure this with the current setup).

 

The trick is adding the extra items from my previous snippet into your code. The propagation delay Kevin mentioned will be there, but again, if you don't need ultra-tight synchronization, it should be alright. I will definitely play around with this when I get access to hardware (probably on Wednesday) and I will let you know what I can find.

 

Regards,

Camilo V.
National Instruments
0 Kudos
Message 12 of 15
(894 Views)

So I leave the programming attached.

Why is it not working for me? Could you correct the VI for me please?

0 Kudos
Message 13 of 15
(887 Views)

Hello,

 

Most seems alright, but I noticed something that should be corrected. The Timebase rate in your code is set to 13000000 Hz when it should be 13107200 Hz. DAQmx uses that value to estimate the actual sample rate (see attached VI) and by consequence, the dt from the waveform. I think your modules are actually in sync, but since that value is not correct, the X Axis values are wrong.

 

I was able to get my hands on hardware early today and came up with the attached VI. I tested it acquiring a 1 kHz square wave at 51.2 kS/s and the worst phase mismatch I got was of about 0.6 deg and there was no clock drift, the mismatch was quite constant (no movement before the fourth decimal point for me).

 

Phase Mismatch.PNG

 

 

You can keep the DAQmx Connect Terminals.vi where you have it. I just moved it to the right so I could read the source from a property instead of using a constant. I did the same with the Sample Clock » Timebase » Rate.

 

Try that out and let us know the outcome. We are getting closer! Smiley Happy

 

Regards,

Camilo V.
National Instruments
Message 14 of 15
(879 Views)

Dear Camilo,

 

Thank you so much for your help. It is working nice now.

0 Kudos
Message 15 of 15
(867 Views)