DAQmx C API - Maximum number of simultaneous input channels available.

[ttaneff]

I'm developing custom acquisition software using the C/C++ API. I have no particular problem with setting up the sample clock, buffers, modes etc. But I have a problem with determining one of the properties of a device:

What is the maximum supported number of simultaneously sampled ai-channels (in a task) for a given device...

I have been successful in reading all other properties (maxrate, physical channels, ranges, terminal configurations...), but the mentioned property is nowhere to be found in the API reference. This is related to error -200168: "Number of channels to acquire exceeds the device maximum". Well in order this not to happen, I need the "device maximum", which MAX reports as "Maximum Number of Different Channels Allowed:". Is this property hardcoded into MAX and has to be known for each device, or is there a corresponding value in the DAQmx API? Also if the latter is the case, where in the documentation and/or specifications of each device is it pointed out?

If it is of relevance - I'm using mostly M-series devices (USB6211, USB6009, USB6212...).

Thanks in advance. I'll be grateful for any comments and suggestions.

[BalazsNagy]

Dear ttaneff!

M series are multiplexed devices, which means that they have one ADC for all the channels during the digitizing. A MUX will switch to each channel, and DAQmx API will be able to divide the digitized samples between the channels.

As you wrote, you need the "maximum supported number of simultaneously sampled ai-channels".

Basically this means you will need the total number of AI channels for the specific device you are using. In the DAQmx C reference HELP (download link below) you can find the list of C Properties.

Under properties, please search for Device Properties, and the following:

I/O Type => Analog Input => Physical Channels

So the Physical Channels property does the following:

Indicates an array containing the names of the analog input physical channels available on the device.

In my opinion this is that You are looking for, if not please let me know!

 DAQmx C reference Help:

https://www.ni.com/docs/en-US/bundle/ni-daqmx-c-api-ref/page/cdaqmx/help_file_title.html

Please allow me to highlight, that you also can use the X sreies devices, that make throughly simultaneous sampling avaliable, since each AI channel has a dedicated ADC.

More info: https://www.ni.com/en/support/documentation/supplemental/09/what-is-ni-x-series-.html

If you are searching for the specs. of a specific device, I suggest to use ni.com.

Eg. for 6211: https://www.ni.com/en-us/shop/model/usb-6211.html

Choose the Recourses tab (by default Pricing is active). Select Manuals, and search for Specs.

Yous should find the following:

https://www.ni.com/docs/en-US/bundle/usb-6211-specs/page/specs.html

I hope I helped, please let me know, if you have any other questions.

Best Regards,

[ttaneff]

Thanks for answering in such complete manner.

I'm aware of the multiplexing and principle of the M-series. And the particular "problem" is that the 6211 is able to sample beyond 32 virtual channels (ai0, ai0, ai1, ai1, ai2 .... Differential + ai0, ai0, ai1, ai1, ai2, ai2... RSE) and the 6009 only 8 virtual channels no matter of the configuration (diff + rse, only diff, or only rse). The actual problem is that in order to be flexible, my application has to "know" the limit of a device and constrain the number of selected input channels in the task.

In the specs of all the devices and the DAQmx properties I can get all the physical channels, but I can not get the property of the MUX - how many virtual channels can it switch in one cycle.

On of my thoughts was that the number of physical channels is equal to the maximum virtual channels, but this is not true (6009: 8/4 physical - 8 virtual; 6211: 16/8 physical - >> 32 virtual).

It seems what I'm looking for is a property of the multiplexer (kind of)...

Thanks again and sorry if I'm being too thorough.

[Dennis_Knutson]

The 6211 has a total of 16 channels and there is nothing virtual about them. I simply don't see where you get 32.

It sounds like you need to do a little arithmetic. For each differential connection, you need two physical channels (i.e. ai0/ai8), so, the connection type has to be selected first and from the total number of available channels, you can determine if the selected channels are valid.

[John_P1 · Accepted solution]

ttaneff is talking about a sort of corner case where you have multiple copies of the same physical channel in your task.  This is occasionally useful for various reasons (e.g. to be able to sample the same channel with a different terminal configuraiton or with a different input range, or perhaps something like this).

From a quick experiment, the M Series devices can have up to 4095 channels. The 6009 can have up to 8. There's no property node that returns these values, and I'm not even aware of any documentation regarding them.

You can however have more channels configured (on either device) if all of the following apply:

1. You have sets of channels with identical configuration (physical channel, range, terminal configuraiton all identical)
2. These channels are grouped consecutively in the task (e.g. chA, chA, chA, chB, chB, chB, ...)
3. The number of channels in each grouping of consecutive channels is identical (I'm not sure of the limit to the maximum size of the groupings--memory and performance constraints are probably your limiting factor)
4. The number of groupings is limited to the numbers reported above (4095 for M Series, 8 for 6009).

A few examples:

EDIT:  I just realized you are using the C API, apologies for the LabVIEW examples--hopefully the examples still make sense.

Best Regards,

[ttaneff]

@John_P1: Well I think this is the answer I was (kind of) looking for. Really thankful for your experiment, it showed me a possible workaround (the LabView diagrams are fine with me). I'll switch my code to checking (verifying) the channel configuration on-the-fly in the GUI.

I read about the option of grouping channels but I hadn't realized the third point (that groups must contain equal number of physical channel references).

Note: I'm certain that somewhere on low driver level there's a property/flag for this... but it's not that critical to justify the research 🙂

Again thanks!