Add Active Dev to Timing Class

[charitylxy]

• This contribution adheres to CONTRIBUTING.md.
• I've updated CHANGELOG.md if applicable.
• I've added tests applicable for this pull request

What does this Pull Request accomplish?

• Update attributes.py metadata generated from add lv-filters to attribute metadata by charitylxy · Pull Request #269 · ni/grpc-device-scrapigen
• Add _active_devs to Timing class
• Implemented __getitem__ to return a new Timing instance with _active_devs set to the index
• Updated the property getter/setter/deleter template to use the _ex interpreter method if _active_devs is set.
• Added more unit test coverage for timing property

Why should this Pull Request be merged?

• Fixes Cannot set "ai_conv_rate" on NI DAQ 9209 due to missing active device modifier for timing attributes #692

What testing has been done?

1. Ran simple program to test some of the attributes:

• ai_conv_rate attribute with device specified

...
    task.timing["cdaqChassisTesterMod6"].ai_conv_rate = 100
    print (task.timing["cdaqChassisTesterMod6"].ai_conv_rate)
...

# Result: ai_conv_rate gets printed

• first_samp_timestamp_enable attribute with device specified

...
    dev = Device("nidaqmxMultithreadingTester1")
    print (task.timing[dev].first_samp_timestamp_enable)
...

# Result: Error -201118 displayed

2. Unit Test

(nidaqmx-py3.10) PS C:\Dev\nidaqmx-python> poetry run pytest -k test___timing___
=========================================================================================== test session starts ===========================================================================================
platform win32 -- Python 3.10.8, pytest-8.4.1, pluggy-1.6.0
rootdir: C:\Dev\nidaqmx-python
configfile: pyproject.toml
testpaths: tests
plugins: cov-6.2.1, mock-3.14.1
collected 2514 items / 2398 deselected / 116 selected

tests\component\task\test_timing.py .s.s..ss...sss...sss.s                                                                                                                                           [ 18%]
tests\component\task\test_timing_properties.py .s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s                                                        [100%]

============================================================================= 58 passed, 58 skipped, 2398 deselected in 1.44s ============================================================================= 

[github-actions]

Test Results

    34 files  +    25      34 suites  +25   56m 43s ⏱️ + 53m 41s
 2 515 tests + 2 305   2 145 ✅ + 1 935    370 💤 +  370  0 ❌ ±0 
44 838 runs  +42 948  38 426 ✅ +36 536  6 412 💤 +6 412  0 ❌ ±0 

Results for commit 6566ae5. ± Comparison against base commit 2a45bcc.

♻️ This comment has been updated with latest results.

[charitylxy]

@bkeryan I'm not too sure how we should go about specifying _active_devs for unsupported methods. Do we want to allow specifying _active_devs only for ai_conv_rate, and the rest would error out if _active_devs is specified?

[zhindes]

@bkeryan I'm not too sure how we should go about specifying _active_devs for unsupported methods. Do we want to allow specifying _active_devs only for ai_conv_rate, and the rest would error out if _active_devs is specified?

Can you try that in LabVIEW with the Property Node - what does it do if you specify one with an attribute that doesn't support it?

Overall, it looks good :) Once we figure out the behavior here, let's add a couple unit tests. Add a simulated cDAQ module that supports this, and then validate whatever the error cases (or not error depending on what we decide) are.

[bkeryan]

@bkeryan I'm not too sure how we should go about specifying _active_devs for unsupported methods. Do we want to allow specifying _active_devs only for ai_conv_rate, and the rest would error out if _active_devs is specified?

Look at NIDAQmx.h and see which timing property get/set/reset functions have an Ex version. Those are the ones that support active devices.

The timing properties that do not have an Ex version do not support active devices in the C API. The Python API should raise an exception rather than silently discard the active devices parameter. DAQmxErrorMStudioOperationDoesNotSupportDeviceContext is an appropriate error code, despite the fact that it has "MStudio" in the constant name: "Operation must be performed on the entire task. It cannot be performed only on specific devices in the task. Do not use the indexer, Item property in Visual Basic, or index operator in C++ to specify device names when performing this operation."

Note that you should still use the generic functions like DAQmxSetTimingAttributeEx, not the attribute-specific functions.

How do you know based on the metadata which properties have active devices? I think you probably need to update scrapigen to look at whether lvFilter includes "Advanced:Timing (Active Device)", and you may need to extend the grpc-device/nidaqmx-python metadata schema to describe this new capability. MSDaqDotNET has a more generic approach that involves looking at which lvFilter groups include any "active property", but I think hardcoding the lvFilter groups is sufficient for this bug fix.

Can you try that in LabVIEW with the Property Node - what does it do if you specify one with an attribute that doesn't support it?

Overall, it looks good :) Once we figure out the behavior here, let's add a couple unit tests. Add a simulated cDAQ module that supports this, and then validate whatever the error cases (or not error depending on what we decide) are.

Normally I am in favor of parity with the LabVIEW API, but the underlying interfaces used by the LabVIEW API allow passing active devices to properties that do not support active devices in the C API.

We ran into this when we updated the .NET API to call the C API, and ended up using a warning instead of an error in some cases. See Timing::ThrowIfHasContext and Timing::WarnIfHasContext in MSDaqDotNET.

[zhindes]

The timing properties that do not have an Ex version do not support active devices in the C API. The Python API should raise an exception rather than silently discard the active devices parameter. DAQmxErrorMStudioOperationDoesNotSupportDeviceContext is an appropriate error code, despite the fact that it has "MStudio" in the constant name:

"Operation must be performed on the entire task. It cannot be performed only on specific devices in the task. Do not use the indexer, Item property in Visual Basic, or index operator in C++ to specify device names when performing this operation."

...

Normally I am in favor of parity with the LabVIEW API, but the underlying interfaces used by the LabVIEW API allow passing active devices to properties that do not support active devices in the C API.

That all sounds good to me!

[zhindes]

Still looking for tests!

[charitylxy]

Still looking for tests!

@zhindes I'm trying to add a test for the timing boolean property, ai_conv_dig_fltr_enable is the only boolean property that allows active_devs. I've tried with multiple devices, but I kept getting "property not supported" error. Do you know what device supports ai_conv_dig_fltr_enable? Or is there anywhere in our codebase that specifies devices and their supported attributes?

[bkeryan]

Still looking for tests!

@zhindes I'm trying to add a test for the timing boolean property, ai_conv_dig_fltr_enable is the only boolean property that allows active_devs. I've tried with multiple devices, but I kept getting "property not supported" error. Do you know what device supports ai_conv_dig_fltr_enable? Or is there anywhere in our codebase that specifies devices and their supported attributes?

Multiplexed X Series supports AIConvDigFltrEnable but not the active devs version.

Active devs timing was added to allow setting per-module convert rate on C Series modules, like the NI 9205. However, I don't think they support external convert clock, so there is no reason to support digital filtering of the convert clock.

Active devs for this specific property is the intersection of two corner cases, so I don't think you can test it.

Or is there anywhere in our codebase that specifies devices and their supported attributes?

raptor.dds, cseries.dds, tCDAQCartridgeAITimingExpert.attr, tAttributeQueryTest, etc.

[bkeryan]

Sorry for the delays. This looks almost done, but there are a few minor things I want you to fix.