[BUG] DAQ WriteDigital function throwing errors

[noffz-nvidakovic]

Describe the bug NOTE: This might be a bug or we don't understand how is this intended to be used. Anyway, we would like some clarification.

When DAQ DO is used, if pinmap isn't configured in certain way, WriteDigital will throw an error. When we configure DO task in pinmap and specify channels that are going to be used like this:

and we specify connections in this way:

(Note that order of channels in task definition is not the same as how we defined them for sites: ch2 is used for site0 and ch1 is used for site1) we get an error:

We don't get this error when order of channels in task definition is matching order of channels mapping to sites:

After some debugging we discovered that issue is here:

This dictionary, which is populated during task initialization, and key that is tried here are not the same. Dictionary would have key "Port0/Line1,Port0/Line2" and requested key would be "Port0/Line2,Port0/Line1". Underlaying cause for this is that GetNIDAQmxTasks() from Semiconductor Module APIs called in DAQmxTasksBundle constructor and it's overload called in CreateDAQmxDOTasks() function during Initialization of the task don't return the same string (order gets messed up here).

Second scenario Additionally, we came across to one more issue. When we have 2 pins for DO and we define channels in task like this:

and we setup connections like this

We get the same error, even though order is the same. We checked and it's the same cause -> channel strings are different.

Workaround we found for these issues is creating 2 different instruments for same DO task - one for each pin and keeping the order in the same way.

This way, WriteDigital will work with multiple pins and multiple sites.

Conclusion and questions Is this a bug or the intended behavior ? I understand that root cause of the issue is Semiconductor Module API, not the Semiconductor Test Library, however, it probably can be handled better in SampleValuesCacher class.

Also, could you confirm that these are intended ways to use daq in pinmap:

• When we have multiple pins for DO we should create one Instrument for each of them (with same task type) ?
• When defining channels in that instrument, the order should be the same as for the mapping to the sites ?

If this is really the case, could you point me to the documentation or example where these things are explained. It's pretty painful getting to these conclusions empirically and it's not that obvious.

I think there is similar issue with AO functions, but I haven't investigated.

System Setup(please complete the following information):

• STS Software Version 24.5,
• Behavior was reproduced both on simulated and actual card.
• NI PXIe 6363

[Mattjet27]

@noffz-nvidakovic, thank you for reporting this issue in such detail. The issue has been reviewed internally and the root cause has been confirmed. The team will be working to address this in the next release. In the meantime, the workaround you suggested appears to be the best option. I will reiterate it below to clarify for others. Please note that this also affects DAQmx analog output tasks as well.

Workaround: When defining DAQmx digital output or DAQmx analog output tasks in your pin map, create one task per DUT pin. For each digital output or analog output task definition, ensure the channels defined in the Channel List are listed in ascending order by site number for the specific DUT pin.

[noffz-nvidakovic]

@Mattjet27 Thank you for confirmation. One more thing that we discovered later is that there might be an issue with input tasks as well, if we filter some sites out. If our task contain channels for multiple sites for one pin and if we apply FilterBySite function, channels in tasks are not actually filtered and we will get measurements for all channels. FillResultsDictionary function will not work correctly because we will have measurements for channels that are not expected and results won't be packed correctly. Workaround we found for this is adding this line before reading measurements: taskInfo.Task.Stream.ChannelsToRead = taskInfo.ChannelList; In this way it will read only channels that are active, since ChannelList was filtered previously. This is probably different bug, but you can look into this and let us know if our understanding was correct.