How to sync AI and DI measurements (cDAQ)

[1984]

Hi community,

I have an NI 9174 cDAQ chassis with an AI and a DI module in it. I would like to acquire samples with both the modules at the same time (so they must be sync'ed) and represent the samples on an waveform graph to see when the digital signal goes high relative to the analog signal. Is there a straightforward way to do it?

Please point me to an appropriate example.

thanks!

[SkyWalka]

Which modules are you using with the 9174 chassis?  Sometimes synchronization depends on which clocks the modules use by default.  But here is a good example to start with:

https://decibel.ni.com/content/docs/DOC-12185

[1984]

Thanks for answering.

The AI is an NI 9225 while the DI is an NI 9421

I have attached the VI I use. Once the contacts are closed I would expect to see a digital rising edge and an analog falling edge. I see those, but there is an enormous (about 7-8ms) delay between them. The graphs on the VI shows the results of the last measurements so you will see that something is certainly wrong. the graph on the bottom shows what happens if I compensate the 38sample delay of the NI 9229.

What could be missed here?

thanks!

[SkyWalka]

I think the issue is related to triggering.  The tasks are setup to use the same clock, but not syncronized to start at the same time.  A start trigger should fix the 6-7 ms delay.  Figure 7 of this link shows implementation of a digital edge trigger:

http://www.ni.com/white-paper/11369/en/

[1984]

I have ran the VI again and realized that the skew between the DI and the AI signal is not 6-7ms but 60-70ms

I can compensate this by cutting signals from the DI input, but I would expect to do it in the right way.

I apprechiate the linked doc, but thats about PXI and I am not sure how applicable is to cDAQ. As we know the chassis (917x) and the modules (NI 9229 for AI, NI 9421 for DI) it should be obvious what am I supposed to use as a trigger line... Its certainly not obvious for me. I believe this part of the c-series modules are quite undocumented.

Any ideas?

[MarkGrot]

You are likely seeing the input delay from the 9225 which is 38.4/fs + 3us.  See page 20 in the 9225 manual.  This KB explains the issue:  Why Is My Data Delayed When Using DSA Devices?

[1984]

I am aware of the 38 sample delay and I compensate it by deleting the first 38 samples of the voltage samples.

The delay we see is lot higher (about 60ms). This is proven by checking the t0 parameter of the two waveforms. once I compensate for this the digital and analog signals are inline. So its really an internal delay. For my measurement I dont want to compensate it. Its not too much of a hassle, but I rather would like to collect the samples on the right way.

[MarkGrot]

I apologize--I hadn't looked at your VI before responding. 

Are you seeing an unexpected delay in the data or the waveform t0?  Or both?  Once you account for the 38 sample delay, if you were to only look at the y values of the waveforms (ignoring t0), are they what you expect or offset?  I'm fairly sure the issue is with how t0 is calculated for the two waveforms.  I can explain how that works in more detail but I want to see if I understand the issue first.

[1984]

The VI I have attached earlier compensates for the 38 samples delay. I have no problem at all with the collected data in terms of the values, although if I check the t0 of the waveforms then I see a huge difference which - for me - indicates that the signals are not sync'ed.

To confirm the delay between the samples pls check the VI I have attached to this comment. It uses measurement data I have recorded earlier. (LV2013)

[MarkGrot]

Right, what I'm saying is that the different t0s are not an indication of unsynchronized waveforms.  See this KB on waveform timestamps.  The waveform t0 is not a hardware timestamp of the start trigger for a task.  The first time you call read DAQmx takes the system time, the number of samples available, and your task's sample rate to calculate roughly when the task started.  This is being calculated independently for your two tasks so they end up with different t0s regardless of when they actually started.  If you're using waveform data from two synchronized tasks, you're best off just using the same t0 for all waveforms.

That's why I asked if you were having synchronization problems outside of the t0s, because they aren't accurate.