DAQmxCreateAIVoltageChan - can the order of channel scan be controlled?

[pingpong]

Hi,

due to the crosstalk between channels I want to read a grounded channel in between two channels I want to measure: in my case channels ai1, ai2 and ai3 are the signals I want to measure and ai4 is shorted. I want to read ai1, ai2, then ai4 and finally ai3. In matlab, I can use the AcqNUpdates function and specify the order, e.g., :

[data, time, time0, tout] = ...
AcqNUpdates(...
'dev1/ai1, dev1/ai2, dev1/ai4, dev1/ai3',...
-.2,2,4000,35000,1);

This works very well and I eliminate the crosstalk.

Now when using DAQmxCreateAIVoltageChan, I call the function as many times as there are channels I want to measure, e.g.,

[err,dd1,dd2,dd3] = calllib('NI_DAQmx','DAQmxCreateAIVoltageChan',...
    uint32(taskhandle),'Dev1/ai1','',-1,-.2,.2,DAQmx_Val_Volts,'');

then repeat this for Dev1/ai2 and so on. I thought that I could do the same as in AcqNUpdates by simply ordering the calls to DAQmxCreateAIVoltageChan such that I first pass 'Dev1/ai1', then 'Dev1/ai2', then 'Dev1/ai4' and finally 'Dev1/ai3'. However, this gives me the same crosstalk behavior as in the case where I pass them in the Dev1/ai1:4 order, indicating that this approach does not alter the channel scanning order.

Is there a way to control the order in which the channels are scanned? I couldn't find an answer to this neither in C Reference Help nor at this board, but I appologize if the answer is obvious but I have missed it.

Thanks.

[David L.]

Hi Pingpong,

We are limited on support for MATLAB, but would like to find out more about what software and hardware you are using. Also, what is you application doing and what kind of signals are you reading? Thanks!

[pingpong]

Hi David,

we have an NI USB 6218 and NI-DAQmx 8.3. We are measuring three signals of different ranges - signals going into ai1 and ai3 are mV range, while the signal going into ai2 is a -2 to +2 V signal. We do not want to change the wiring. There is significant crosstalk seen on ai3 that changes according to changes in ai2. Although the V-range changes in ai2 result in mV changes in ai3, the effect is significant since the signal level in ai3 is low (mV), and this crosstalk results in shifts of the order of magnitude of the signal we are measuring. We did what is recommended in NI documentation for this issue - read a grounded (shorted) channel in between the channels you want to measure. The NI-DAQmx matlab interface (tools) comes with an easy to use AcqNUpdates command that lets us specify the order in which the channels are scanned. So we shorted ai4 and we read ai4 after ai2 and before ai3 - this works nicely. However, AcqNUpdates does not perform as fast as directly calling the corresponding C functions in continuous mode, which is why we wrote in matlab a new program that does the same as AcqNUpdates but much faster (and with much more flexibility than AcqNUpdates). However, it seems that we can not specify the channel order, as described in the first post. We are wondering how this can be done (so that we read ai1, ai2, ai4 then ai3). The problem is not really related to matlab but rather to the C function interface of NIDAQmx.

Thanks

[Tom_W_[DE]]

Hi pingpong-

Your single call to AcqNUpdates in the NI-DAQmx Tools for Matlab interface is creating all channels with the same voltage range.  You are specifying a -0.2..2V range which is coerced to a -2V..2V range that is then used for all channels.  You don't list all of your calls to DAQmxCreateAIVoltageChan, but I'll assume that you're setting the mV-range channels to -0.2V..0.2V and the V-range channels to -2V..2V.  This change in gain settings during scanning creates a step on the input of the device and is probably resulting in prolonged settling of the inputs (which manifests itself as ghosting in your signals).  So, NI-DAQmx is not reordering your channels when you call the Cpp interface directly, it's just that the situation is a bit different.

You have a few options to try.  First, if the accuracy of using all channels on the -2V..2V range (as in your Matlab Tools implementation) is acceptable then you could do the same when you call the Cpp interface directly.  This can be accomplished by a single call to DAQmxCreateAIVoltageChan with the same format for the scan order as in your Matlab Tools example and a range of -2V..2V.  Alternatively, if your sample clock rate allows, you can extend the interchannel sample delay by manually overriding the AI Convert Clock Rate via DAQmxSetAIConvRate(TaskHandle taskHandle, float64 data);.  The longer you can extend this (up to a slowest limit of Sample Rate X # of channels in the task) the better leeway you give for settling between channels.

Hopefully this helps-

[pingpong]

Hi Tom,

thanks for the reply. Yes, the variable voltage range is also one of the reasons we went with C functions instead of AcqNUpdates. The voltage settings for the calls to DAQmxCreateAIVoltageChan are as you have assumed - 0.2 V for ai1, ai3, ai4 and 2 V for ai2. The interchannel delay idea is something we will certainly try. We also noticed that simply decreasing the sampling frequency accomplishes significant reduction in crosstalk. We would still be interested in specifying the channel scan order but your reply seems to imply that this is not possible. If still there is a way to accomplish this somehow, we would appreciate it if you could instruct us how to do it.

Thanks again

[Tom_W_[DE]]

Hi pingpong-

The channel scan order can certainly be set- I apologize if my earlier post was misleading.  The order in which you add the channels to the task will dictate the scan order in all but a few cases where the hardware does not support random scanning (this mostly only applies to older SCXI modules).  Your hardware should still be scanning in the order you have specified, but the interchannel delay may need to be extended to ensure more adequate settling time.  How fast are you setting your Sample Clock rate?  This KB explains why you might see different behavior with the default Convert Clock rate based on the Sample Clock rate you have specified.

[pingpong]

Tom, thanks a lot, this explains everything.