Speed up time of AI Create Channel.vi task containing thousands of channels

[SteveP]

I am creating an AI task containing a total of 8000 channels of different channels with each channel being acquired many times before the next channel is acquired.  The channel list is something like 0,0,0,...,1,1,1,...,2,2,2...3,3,3... where each channel number would be acquired 2000 times.  The purpose is to perform averaging.  I am seeing that DAQmx Create Channel.vi takes about 100 msec to create 1000 channels for a total of 800 msec to create all channels (DAQmx 9.4, LV 11, WIN 7, CoreDuo P8700 2.5 GHz).  I would like to speed this up by a factor of 10 if possible.  Test vi attached.

[Ben]

So in the end you are only looking at 4 channels of input?

I would just create a task with those 4 channels and grab 2000 points from each and then average them. At least this way all of the data associated with a channel are in the same 1d array.

TO the best of my knowlege there is no way to speed up the create channel function since most of the time it requires is devloted to allocating buffers to store the data between being acquired but prior to the code reading the buffer.

Ben

[SteveP]

I do not want to create a channel scan list as 0,1,2,3 and then acquire many samples of that list.  That is easier and faster to program but results in potential problems of settling time and cross talk between channels.  Those issues can be reduced by increasing the time between samples but that then decreases the number of samples that can be acquired in one 60 Hz power line cycle for signal averaging.  I want to acquire all samples from one specific channel one after each other so there are not settling time issues and then switch to the next channel.  I will throw away the first few points after the channel is switched to eliminate any settling time problems.

I will be looking at between 4 and 32 channels of input in multiples of 4 and always 8333 total points (=500kHz conversion rate divided by one cycle of 60 Hz).

If the issue is memory allocating, is there a way to pre-define a large memory array and then fill it with the Create Channel ?

[Ben]

Cross talk can be reduced by adding an extra channel between the active channels wher ethe extra channels are wires to ground. This effectively discharges the input cap before switching to the next channel.

Interchannel delay also can be set.

The cross talk is an isue associated with high output impeadance.

Ben

[Brad_K]

Hi SteveP,

The DAQmx task contains data structures representing channels, which in turn contain other data structures representing channel properties and such. Most of the execution time of DAQmx Create Channel is spent allocating and initializing these data structures. They are separate from the task's input buffer (where data is stored until DAQmx Read is called). The input buffer is allocated when you reserve the task (which is normally done by DAQmx Start Task), and it is indeed allocated as a single large array.

DAQmx support for repeated channels focused on the SCXI use case, where hundreds of milliseconds of channel creation time seemed to be an acceptable tradeoff for measuring thousands of thermocouples. During development of NI-DAQmx 7.0, we used 3072 channels as our large system benchmark for channel creation, since that's the maximum number of channels supported by an SCXI task: 8 chassis x 12 modules x 32 channels (ignoring CJC channels). Repeated channels also make your use case possible, but this wasn't the original goal, otherwise we would have tried to make it easier to use for this purpose.

When replying to your previous thread on this topic (DAQmx AI Task with many samples CH0, then many CH2, then many CH3), I assumed that you were doing this because you were having problems when you took the straightforward approach to averaging, but Ben is right to point out that there are ways to deal with ghosting, cross talk, etc. What is the source impedance of the signals that you are measuring? How Do I Eliminate Ghosting From My Measurements? lists some options for dealing with high source impedance.

Failing that, is it possible for you to reduce the frequency at which your program creates and destroys tasks? If you can extend the task lifetime by reusing the same task more than once, you can avoid the channel creation overhead, or at least amortize it over the lifetime of the task. Note that you don't have to clear one task before you create a second one; you only have to make sure that two tasks don't have the same hardware reserved at the same time--if you do, you will get a reservation error. In most cases, stopping the first task before starting the second is sufficient to avoid this. It is possible to create multiple tasks up front, then switch between them throughout the rest of your program.

Brad

[johnsold]

SteveP,

Following what Ben and Brad K suggested, consider this to see if it is a possibility. Create 4 to 32 tasks, one per channel.  Acquire 8333/#channels samples on one task, then switch tasks as Brad K described to get the next channel.  Reduce the samples per task to allow task switching time and adjust the last channel if necessary to get synchronism with the power line.

You might need to run some tests to see how fast the task switching is and how much jitter can occur.

Or consider changing the sample rate so that you are looking at 8192/#channels samples for each task. 8192 is evenly divisible by 4..32.  That is the equivalent of 491520 kHz.

Lynn

[SteveP]

Brad,

Yes, I switched to the 0,0,0,1,1,1,2,2,2,3,3,3 sequence from the simpler 0,1,2,3 due to influence of a signal of several volts (that can vary from scan to scan) on one channel coming from the output of an op amp (so low source impedance) on the next channel which measures voltage directly at a 100 ohm platinum  RTD fed from a 1 mA constant current source.  So an RTD signal change of 1 mV or less will result in result in an apparent temperature change of several degrees.  Amplifying the RTD voltage before sending to the daq device may thus help.  None the less, I prefer to stay with the 0,0,0,1,1,1,2,2,2,3,3,3 sequence since in the future the source impedance or cable length or other factors may change.  The optimum interchannel delay now may be different should conditions change.  With this sequence arrangement, I know the measured signal will be accurate.

My application currently acquires groups of 4 channels with from 1 to 8 groups.  The task is kept active and only changed when the user changes the specification of how many groups to use.  Then the channel list is changed and the number of samples of each group is adjusted so that the maximum number of possible samples are taken to span one 60 Hz cycle.  I am Committing the task and then acquiring only 1 set of channels (actually 2 due to the  the minimum allowed for Samples per Channel) and then using a software trigger to restart at a hopefully consistent periodic time (500 msec) later similar to the example Acq&Graph Voltage-Int Clk-SW Trig Restarts.vi

It occurred to me also to preallocate an array of 8 tasks covering the 8 possible group channel configurations that I could use.  So I will try your suggestion of creating all possible tasks up front - that may work for me Lynn.

Ben - I note that the Eliminating Ghosting link states that scanning a grounded channel before a high impedance channel does not necessarily help.

Steve