Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Reducing the

 I have an application written in C++ that I've upgraded to work with two DAQ cards, but there's a phase delay of about 82 degrees at 3000 Hz, even though I sync the reference clocks and have configured the first DAQ card to trigger the second one when starting. I read that DAQmxSetTriggerSyncType can be used with X-Series cards to reduce the timing delay further, but it hasn't produced any noticeable affect on the phase delay.

 

Am I using the functions wrong, or is there anything else I can do to reduce the phase delay? I realize that there's only so much that can be done, but I'd like to improve it as much as I can.

 

I attatched the code used to configure each DAQ.

 

Thanks!

Caleb

 

(Graph of the phase difference between the two cards as a function of the frequency of an outputed sine wave signal)

Phase difference between the two cards.png

Download All
0 Kudos
Message 1 of 2
(3,803 Views)

It looks very much like you have a constant phase delay *time* that's largely if not entirely independent of frequency.  That's not a solution, but it should be a helpful clue.  It probably indicates that the delay is based on nice, consistent, hw-timed phenomena rather than a jittery sw-timed issue.

 

I only program in LabVIEW so I don't totally follow your attached code.  It does appear that you have both AI and AO tasks involved, and that you're predominantly relying on the Sync-related functions to synchronize the timing on the two boards.

 

I almost always use a very much simpler method to achieve less theoretically perfect but rarely insufficient sync.  I simply share the sample clock itself (this depends on a physical connection between the boards such as that provided by a RTSI cable or a PXI chassis).   If AI is on Dev1 then you would configure the AO task on Dev2 to use "/Dev1/AISampleClock" (??? not sure of syntax with C++ API) as its sample clock.   Provided there's a physical signal path available (such as RTSI, or PXI backplane), DAQmx takes care of the signal routing details under the hood.

 

There will be some nanoseconds worth of signal propagation delay when you do things this way so it isn't *perfect*, but as Larry David might say, it's pretty, pretty good.

 

 

-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 2 of 2
(3,774 Views)