Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

How to get the _real_ AI channels scanning order and time delays between them in the NI_DAQmx? (NI-6321, 6351, 6115)

How to get the _real_ AI channels scanning order and time delays between them?

 

I’ve tried NI-6351 and NI-6115 1Chan AO and 2Chan AI. I am very interested in the channels scanning order and time delays between them. I need to align the channels by shifting time of one channel by a delay time.

I’ve tested NI-6351, 2 AI Channels, RSI, the same range +-10V at 50-500 kS/s per channel, connected to the same source – an external function generator running at 10 kHz, 8V amplitude (sin., train. and square).

I found that in that range for neighboring channels like 1,2 or 5,6 time delay is exactly 0.5dt, i.e. 1 mks for 500 kS/s. For not neighboring channels like 5,14 time delay was bigger.

Trying 3 neighboring channels, like 1,2,3 or 5,6,7 at 100-200 kS/s I found that:

the second channel in the list is scanned first, next the first channel scanned with 1/3dt delay and finally the third one with 1/3dt delay. I am confused very much.

 

Does anybody know how to know before the measurement what will be the scanning order and time delays using AI measurements settings – kS/s per channel and the channel list?

 

As I understand, it was possible to specify such parameters in the NI-DAQ but not in the NI_DAQmx, right?

 

The NI-6351 has a multiplexer, the NI-6115 has 4 independent AI channels, but I see time delay on both boards. Is it possible to configure NI-6115 in such a way that there is no delay between channels?

 

My program is based on “Multi-Function-Synch AI-AO.vi” LabView example program.

 

 

I am using now LV8.2 and LV2011, NI-DAQmx 9.0.2 and 9.5.1, WinXP and Win7 32 bits.

 

 

P.S. I measure the magnetic hysteresis loop on bulk samples, ribbons and films. I found that the time delay between channels start to contribute considerably to the BH area and the coercivity for magnetizing frequencies above 1 kHz.

0 Kudos
Message 1 of 8
(4,336 Views)

I'm surprised by your observations about the scanning order, where 3 neighboring channels would scan in the order 2-1-3.  Dunno what to tell you there, but as far as I've known, we should be able to expect the scan order to match the order that the channels were in when they were included in the task.

 

Can you describe the delay you see with the simultaneous-sampling 6115?   Are you making separate tasks (if that's even possible -- not sure if that board has the capability) for each of the channels?

 

-Kevin P

 

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 2 of 8
(4,321 Views)

Kevin,

 

One task for AI N channels and one for AO.
Today I simplified everything as much as possible approaching the initial example I started with so that there is only AI N channels. It is called "DAQCard_time_delay_test.vi" and should be attached to this message. One can see all channels vs time, XY graph for any pair of channel specified or save measurements. I added the subprogram "ASubVI_L2_Timeshift.vi" that shifts any channel by time from 0 to 1dt, where dt = 1/sampling_frequency.

You just connect any external sin/trian generator to all your channels, specify it's frequency (i use 10kHz) and run the program. Adjusting "Time shift" of the channels 1 (or 2 for three channels) you will get a perfect line in XY graph at time shift equal to real delay time. So, this small rogram is good for testing time delays.

Sorry I could not get 2,1,3 order today like it was yesterday - today it is correct - 1,2,3. So I have to look in my more complex program for sources of that behavior.

I tested the 6115 card two weeks ago. I will be able to do it again in two weeks approximately - it is in another country.

Last time time delay for 6115 was approxiamtely 10 times lower in microseconds than for 6351 but it was approximately the same in dt units since the sampling frequencies were 5M and 500kHz correspondingly.

It seems that the NI-DAQmx does not know that the 6115 card has fully independent AI channels and sets the conversion order and time delays in the same way as for multiplexed 6351 card. So it is necessary to let the driver know that 6115 has no multiplexer. In the old traditional NI-DAQ it was possible to set all delays in the measurement settings. I need to know how to do it in the NI-DAQmx

0 Kudos
Message 3 of 8
(4,311 Views)

I don't have similar hardware and was only able to fiddle a bit with simulated devices.  A few thoughts & observations:

 

1.  The logic in the time-shift subvi seems a bit weird.   It loops over all the channels but only has an effect on the selected one.  Why not just index the selected channel from the array of waveforms?

   Also, the fractional sample interval shift also seems to anchor the first value to remain unchanged -- this will create discontinuities when you process the data in chunks.  The algorithm otherwise appears to do a linear weighted average to interpolate between actual sample points, essentially shifting in the negative time direction. 

 

2. Using *simulated devices* only, I observed that the t0 value in each channel's individual waveform behaved like this:

6115 (simultaneous sampling): t0 values were the same for all channels

6259 (multiplexed sampling): t0 values varied to account for the convert clock timing used for multiplexing

 

Since the "time-shift" vi has some issues anyway, I'd recommend that you do the time-shifting by manipulating the t0 value of the waveform rather than by interpolating the actual sampled Y data.  However, I'm not sure there's any shifting to do if you do your AI with the 6115.  A single task on a simultaneous sampling board should produce t0 values that are equal for all samples.  I verified this with a simulated device and would expect the same with a real board.  If somehow that isn't the case, a possible workaround might be to assign all waveform t0's to be equal to t0 of waveform index # 0.

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 4 of 8
(4,300 Views)

>>Why not just index the selected channel from the array of waveforms?

I intend to use this subVI later to shift N-1 channels by using an array of shifts for each channel.

>> this will create discontinuities when you process the data in chunks.

In my more complex program I acquire data in chunks. In each iteration I also apply averaging if needed,  append the resulting waveform to the big one and only then shift channnels. It works nicely.

>> I'd recommend that you do the time-shifting by manipulating the t0 value of the waveform

There is one more issue - I discovered that the time stamp from the AI read has 10 mks resolution. It is not enough for me. Also, it is not practical if you need to process later your channels - I measure the field at different distances and then extraplate it to the surface. I will need to shift all channels anyway.

What do you mean by "Using *simulated devices*"?

0 Kudos
Message 5 of 8
(4,295 Views)

There is one more issue - I discovered that the time stamp from the AI read has 10 mks resolution...

 

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 6 of 8
(4,238 Views)

There is one more issue - I discovered that the time stamp from the AI read has 10 mks resolution...

 

(Oops, sorry about that last empty message, accidentally bumped "Enter" when aiming for "Shift". )

 

To be honest, I've rarely counted on the timing information in a waveform acquisition.  A lot of things I've

done used clocking & timing schemes that depended on external signals such that DAQmx *couldn't*

know the correct values for t0 and/or dt.  In those cases, the value(s) would definitely be incorrect and

I grew accustomed to simply not trusting the timing info found in waveforms.  Instead, I've developed a

habit of generally handling timing information on my own.

 

Maybe that's what you need to do here too?   What kind of resolution do you want/need?  Why?

 

 

As to "simulated devices", that's a feature in MAX (Measurement & Automation Explorere).  You can

create a simulated device which will allow you to (somewhat) test your DAQmx data acq code.  It's

useful for discovering general syntax or board-capability errors.  But it generally won't let you test out

complicated timing or triggering schemes, or complex data content.

 

-Kevin P

 

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 7 of 8
(4,235 Views)

It was my mistake to start working with waveformes. I happened when I moved from LV6 to LV8 - before I worked with arrays. Waveforms brought me a lot of troubles. Some day I have to rewrite the main program and subVIs to work with arrays. For 6531 card I need up to 1 mks time resolution (fmax AIN = 1MHz), for 6115 - 0.1 mks.

0 Kudos
Message 8 of 8
(4,224 Views)