Timing Discrepancy When Syncing DAQmx and XNET Signals

Issue Details

Solution

This behavior is the result of a discrepancy between how the DAQmx and XNET drivers get their initial timestamps and assign them to waveform data. An XNET session takes its initial timestamp from the host OS when the session is created. In contrast, a DAQmx task takes its initial timestamp with the first collected data point. The skew between these two initial timestamps can make your data appear not to be synchronized, even though the two modules increment their notions of time off the same timebase (i.e., the onboard clock of the CompactDAQ chassis).

 
In this article, we will assume that we are using a DAQmx task as a master, and an NI-XNET task as a slave. (The same principles apply in the opposite configuration.) To properly correlate XNET and DAQmx data, you can use the XNET Read (State Time Start) VI to get the initial timestamp for the session. This is the time when the trigger was received from the master DAQmx task, and corresponds to when the DAQmx task started. By subtracting the timestamp of each XNET signal from the start timestamp, we can see exactly how much time has passed since the start trigger was received (i.e., how much time has passed since the DAQ task started). Using the DAQmx timestamp as our starting point, and calculating how much time has passed between the session start and the receipt of an XNET signal, we can correlate the DAQmx and XNET data.

Example

Say we configure our DAQmx task to be the master, and our XNET task to be the slave. We start the DAQmx task at t0 = 11:58:20.5. The DAQmx data would then look like:

DAQmx (t,V)

We know the XNET session starts at the same time as the DAQmx task, because we've configured it that way with a start trigger. But we also know that we're going to get different t0s from the different drivers. Say our XNET t0 is 11:57:00, our XNET data might then look like this:

XNET (t,V)
 

Because we used a start trigger to start the slave task, we know the XNET session started at the same time as the DAQmx task. It didn't really start a full minute before the DAQmx session. The difference in timestamps is due to the aforementioned difference in methodology for generating a timestamp. We also know that the two modules are running on the same timebase from the cDAQ chassis, so they share a sample clock. So, we throw out the XNET timestamp and just consider the time increments between each signal:

XNET (no timestamps) (t,V)
 

 
Finally, to correlate the XNET dataset with the DAQmx dataset, we add the DAQmx t0 to each XNET timestamp:

XNET (starting at DAQmx t0) (t,V)
 

Additional Information