How to control the channel scan sequence in DAQmx

[TradLuddite]

I have an existing application written for the traditional DAQ C API that I need to convert to use the DAQmx drivers. The application currently uses the SCAN_Setup function to create a complex channel scanning sequence to effectively sample at different rates on each channel and to vary the rate on one of these channels. The following example shows the channel scan sequence passed as the chanVector argument to the SCAN_Setup call:

0 0 0 0 0 0 0 0 0 0 0 1 0 2 0 3 0 1 0 2 0 3 0 1 0 2 0 3

The AI sequence is synchronised with an AO waveform and is designed to measure the response on AI0 of an external system to that waveform while taking other measurements from other sensors at the same time: AI1, 2 and 3. This sequence achieves a higher sampling rate on AI0 at the start of the waveform.

How do I do this using DAQmx?

I have tried to use a loop to make multiple calls to the DAQmxCreateAIVoltageChan function, one for each sample in the channel vector, but the result does not appear to read the correct channels in the correct order.

Is there a problem with adding the same physical channel multiple times to the same task?

Thanks for your help.

[Brad_K]

Hi TradLuddite,

On many DAQmx devices (e.g. E Series, M Series), you can scan repeated physical channels by passing a comma-delimited string like "Dev1/ai0,Dev1/ai0,Dev1/ai0,Dev1/ai1,Dev1/ai0,Dev1/ai2" for the physicalChannel parameter to DAQmxCreateAIVoltageChan() or by calling this function multiple times, as you are trying to do.

Some other DAQmx devices (e.g. S Series, DSA, and Compact DAQ) do not support repeated physical channels.

Is DAQmxCreateAIVoltageChan() returning an error code? One likely issue is that each virtual channel in the task needs to have a unique name with respect to the task. This means that you need to pass something other than an empty string for the nameToAssignToChannel parameter, or you will get an error when adding repeated physical channels to the same task. By default, the virtual channel name is the same as the physical channel name, which is not unique in your case.

If this doesn't answer your question, you should post more information. What device are you using? Could you post a concise snippet of code that demonstrates the problem?

Brad

Message Edited by Brad K on 07-08-2009 12:43 PM

[TradLuddite]

Hi Brad,

I am currently using a PCI-6052E card, with plans to move to more modern M-series cards. The following code is the loop I use to add channels:

for (ui=0; ui < Depth && iStatus == DAQmxSuccess; ui++)
{
sprintf(sPhysicalChanName, "/%s/ai%u", DevName, piChanVect[ui]);
sprintf(sVirtualChanName, "mychan%u", ui);
NIERROR(DAQmxCreateAIVoltageChan(mxtask_AI_Handle, sPhysicalChanName, sVirtualChanName, iTerminalConfig, dfpMin/pf64GainVect[ui], dfpMax/pf64GainVect[ui],
DAQmx_Val_Volts, NULL), "DAQmxCreateAIVoltageChan");
if ( DAQmxSetAIDataXferMech(mxtask_AI_Handle, sVirtualChanName, DAQmx_Val_DMA) != DAQmxSuccess )
{
if ( DAQmxSetAIDataXferMech(mxtask_AI_Handle, sVirtualChanName, DAQmx_Val_Interrupts) != DAQmxSuccess )
{
NIERROR(DAQmxSetAIDataXferMech(mxtask_AI_Handle, sVirtualChanName, DAQmx_Val_ProgrammedIO), "DAQmxSetAIDataXferMech");
}
}
}


The Depth variable can be 250, 500 or 1000. I don't get any NI errors when this code runs.

Thanks,
Dave

Message Edited by TradLuddite on 07-09-2009 04:19 AM

[Brad_K · Accepted solution]

Hi TradLuddite,

E Series devices have a "configuration memory size" specification of "512 words", which means that they can scan up to 512 unique physical channels. So I would expect a Depth of 1000 to cause DAQmxStartTask() to return an error. However, it may be possible to exceed this limit if the scanlist consists solely of identically-sized groups of identical physical channels (where the input limits and terminal configuration are identical within each group), because the hardware supports a very simple form of scanlist compression. M Series devices have a corresponding "scan list memory" specification of "4095 entries", so a Depth of 1000 would not run into this limitation on M Series.

Setting the data transfer mechanism property is probably unnecessary. DAQmx chooses a default value for this property based on the type of device and the sample timing type property. Using DAQmxCfgSampClkTiming() to set the sample timing type to "Sample Clock" will result in a default data transfer mechanism of "DMA", "USB Bulk", or "Interrupts" depending on bus type (PCI/PXI, USB, and PC Card, respectively). Not configuring timing (or calling DAQmxSetSampTimingType(taskHandle, DAQmx_Val_OnDemand)) will result in a default data transfer mechanism of "Programmed I/O".

Which DAQmxRead() function are you calling? Are you specifying DAQmx_Val_GroupByChannel or DAQmx_Val_GroupByScanNumber for the fillMode parameter? Have you checked the value returned in *sampsPerChanRead?

Are only the repeated channels returning incorrect data? Does it work when you don't repeat any channels? If not, perhaps the terminalConfig parameter doesn't match how the signals are wired, you are experiencing ghosting, or there is a problem with the signal wiring. Does it still work in Traditional NI-DAQ?

Brad

[TradLuddite]

Hi Brad,

I've gone through your suggested checks and removed some redundant lines of code. It turned out that a fault had developed in the external system. The MX method now works the same as the old Traditional code!

Thanks.