Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

propagation delay NI cDAQ-9174

Highlighted

Hello,

I am using labview for data acquisition, the HW i am using are : 

-NI cDAQ-9174 CompactDAQ Chassis

-NI 9205 AI card

-NI 9401

The program i am using acquire two differential voltages at channel0 and channel1 with the 9205,

The 9401 is also used to acquire data from an encoder ( A+, B+, Z+), 

i want to acquire both data at the same,

My question is what is the propagation delay of each card ? is there a way to measure the propagation delay ? or a way to synchronize the acquisition of both data ?

0 Kudos
Message 1 of 6
(100 Views)
Highlighted

Honestly, I suspect you're asking the wrong question.

 

Propagation delay would probably only matter in a significant way if you were making software-timed on-demand queries to accumulate your measurements.

 

Much like the old joke:

Patient: "Doctor, it hurts when I bend like this.  What should I do?"

Doctor: "Don't bend like that."

 

My answer is: don't measure like that.  Instead, configure your devices to do buffered, hw-clocked acquisition.  This will sync the data reliably and easily, especially if you share a sample clock.  See this message I just linked to in another thread a few minutes ago.

 

 

-Kevin P

0 Kudos
Message 2 of 6
(48 Views)
Highlighted

Thanks Kevin for your feedback, i need to acquire two voltages from the 9205, the two voltage should be acquired at the same time, what will be the time difference if i use the same card, with this card we have only one ADC, do you recommend any card that has two ADC and where i can get the two voltages at the same time ?

thanks.

0 Kudos
Message 3 of 6
(29 Views)
Highlighted

So step 1 is to be sure you have realistic expectations and definition of "the same time."

 

In the non-ideal world in which we live, breathe, and make the best of things, we usually have to start by recognizing that perfection isn't feasible and then figuring out how much imperfection we're willing to live with.

 

Sorry for the side-trail but after nearly 20 years on these forums, I've seen a lot of things, especially from new posters.  Sometimes they start with demands for sub-microsecond precision and later settle for 10's of millisec variability.  Other times they approach a problem that *demands* sub-microsecond precision with a method that only offers 10's of millisec variability.   And all kinds of things nearby and in between.

 

Your 9205 device is spec'ed for 250 kHz *aggregate* sampling.  So that's 4 microsec between A/D conversions.  If you have 1 channel, you get a 250 kHz rate.  With 2 channels, you can get 125 kHz each, with 4 microsec between the A/D conversions of the 2 channels.

 

This time separation can be queried or controlled via a DAQmx Timing property for the "AI Convert Clock" Rate, and it will be precise and fixed.  So your first question to answer is, can you live with 4 microseconds skew when you can also *know* that it's 4 microsec exactly?

 

Most apps probably can, some few exceptions really can't.  I'm afraid I can't offer any great expertise in cDAQ modules to recommend.  But when evaluating the question, bear in mind any time delay or latency in your physical sensors.  The 4 microsec skew between channels may be a very small part of the overall timing imperfection.

 

 

-Kevin P

0 Kudos
Message 4 of 6
(23 Views)
Highlighted

to answer your question : no i cannot survive with 4us of delay between the two channels, both differential voltages should be acquired at the same time ( i know this does not exist), but at least with the minimum delay, ideally below 100ns, so i am checking  with card that offer simultanous sampling,

in the real application i measured higher than the 4us ( i measured around 7us of delay between both voltages)

0 Kudos
Message 5 of 6
(17 Views)
Highlighted

Based on long experience, I'm going to press you on this.

 

Why EXACTLY is a fixed, known # microseconds of skew unacceptable?  What phenomena are being measured and what sensors are used to capture it?  Do both things truly support a demand for 100's of kHz bandwidth?

 

Just making sure.  Again, long experience on threads that start with very high demands and end with satisfaction over self-grown solutions that aren't within 2 orders of magnitude of satisfying them.

 

 

-Kevin P

0 Kudos
Message 6 of 6
(13 Views)