nidaqmx does not generate numbered virtual channel names correctly

[AlexHearnNI]

If a DAQmx channel is created for physicalChannel=Dev1/ai0:7 with nameToAssignToChannel=myChan09, then DAQmx will assign Dev1/ai0 the name myChan09, Dev1/ai1 the name myChan10, and so on. In particular, notice the renumbering of the channels and the zero padding of the numbers. See https://www.ni.com/docs/en-US/bundle/ni-daqmx/page/nameassignment.html for reference.

nidaqmx calculates the virtual names incorrectly.

To demonstrate, run the following script:

import nidaqmx

with nidaqmx.Task() as task:
    ai_channel = task.ai_channels.add_ai_voltage_chan("XSeries6363/ai0:3")
    print(ai_channel.name)
    print(ai_channel.chan_type)

with nidaqmx.Task() as task:
    ai_channel = task.ai_channels.add_ai_voltage_chan("XSeries6363/ai0:3", name_to_assign_to_channel="myChan09")
    print(ai_channel.name)
    print(ai_channel.chan_type)

It will fail on the last line with nidaqmx.errors.DaqError: Specified channel is not in the task..

The output before that is

XSeries6363/ai0:3
ChannelType.ANALOG_INPUT
myChan090:3

AB#3099973

[marktsuchida]

I ran into this same issue with Task.di_channels.add_di_chan().

The issue seems to be the same across all of the add_*_chan() functions that can create more than one channel in one call. I think the culprit is

nidaqmx-python/generated/nidaqmx/task/collections/_ai_channel_collection.py

Lines 51 to 55 in f80501f

	if num_channels > 1:
	name = '{}0:{}'.format(
	name_to_assign_to_channel, num_channels-1)
	else:
	name = name_to_assign_to_channel

and the corresponding (identical) code for AO, CI, CO, DI, and DO. This code clearly assumes that the given channel name does not contain commas or colons and does not end with a digit.

In contrast, the corresponding C API functions allow the given "name to assign" to contain multiple channel names (with commas and/or colons). When the user passes fewer names than required, the missing ones are generated by incrementing the numerical suffix if present.

Ideally the channel name (potentially containing commas and colons) should be passed as is to the C DAQmxCreate*Chan() functions, and the resulting channel names should be read back, though I'm not sure how you would separate them out from preexisting channels.

If that is not possible, then I expect there needs to be a pure-Python implementation of the algorithm used by the C functions to generate the actual channel names from the string given by the user.

Either that or the Python API should check and reject names containing commas or colons or ending in digits.

[bkeryan]

In DAQmx 2024 Q3 or Q4, we solved the same problem for the DAQmx .NET API by storing the last created channel name in thread local storage and adding an internal entry point to query the last created channel name. We should use the same internal entry point to solve this for the Python API.

[zhindes]

FYI - this is fixed under this scenario:

• Library Interpreter
• DAQmx 24.5 or newer installed

It is not fixed under these scenarios

• gRPC Interpreter
• Version earlier than DAQmx 24.5 installed

We have two options to resolve those gaps.

1. Fix this internally to the Python bindings by replicating the logic DAQmx does. I added advanced test cases that would help prove out an implementation. However, I don't think this is a worthy use of time.
2. For gRPC, we should update grpc-device and nidaqmx.proto to return the channels that were created from each create channel call. e.g., add an out-param to CreateAIVoltageChanResponse that indicates what was created. Internally it would use the same APIs we use here (InternalGetLastCreatedChan) to do that.

If somebody is passionate about the gRPC use-case here, we could create an issue over there. For now, I'm going to let this be.