Unnecessary write access request when trying to read a property

[Arkh42]

Description of issue

When I try to read the current_limit property, I get an error related to the current_limit_range property, as if I were trying to write the value.

System report

E           nidcpower.errors.DriverError: -1074097882: Requested value is not a supported value for this property. The property value may be invalid because it conflicts with another property.
E
E           Device: PXI1Slot2
E           Requested Value: 1.0e-3
E           Minimum Value: 100.0e-9
E           Maximum Value: 10.0e-6
E           Property: Current Limit
E           Channel Name: 0
E
E           Property: Current Limit Range
E           Corresponding Value: 10.0e-6
E
E           Property: Current Limit Autorange
E           Corresponding Value: Off
E
E           Property: Overranging Enabled
E           Corresponding Value: false

Steps to reproduce issue

``` python
import pytest

import nidcpower

@pytest.fixture
def smu() -> nidcpower.Session:
    return nidcpower.Session(
        resource_name="PXI1Slot2",
        channels=None,
        reset=True,
        options={'range_check': True,
                 'simulate': True,
                 'driver_setup': {'Model': '4163', 'BoardType': 'PXIe'}},
        independent_channels=True)

def test_default(smu):

    assert isinstance(smu.current_limit, float)

def test_lower_limit_range(smu):

    # Set a lower limit range to verify the error
    smu.current_limit_range = 10e-6

    assert isinstance(smu.current_limit, float)

def test_upper_limit_range(smu):

    # Set an upper limit range to verify the error
    smu.current_limit_range = 10e-3

    assert isinstance(smu.current_limit, float)
```

1. Run pytest on the above script.
2. The first test fails because a nidcpower.errors.DriverError is raised.
3. The second test fails because a nidcpower.errors.DriverError is raised.
4. The third test passes, proving that read-access to current limit is equivalent to a write-access, which should not be the case.

[Arkh42]

I tested with the voltage_limit property: it is working properly, contrary to current_limit.

[marcoskirsch]

I don’t believe this is a bug within the nidcpower Python module, rather the underlying behavior of the driver runtime. You’d get the same results from LabVIEW or C or C#.

What is the model of the SMU you run this on?
What is the version of the NI-DCPower driver runtime you installed?
What operating system are you using this with?

[Arkh42]

What is the model of the SMU you run this on?

The PXIe-4163.

What is the version of the NI-DCPower driver runtime you installed?

See the snapshot attached for the whole list. All packages are version 2023 Q4 Patch 1.

What operating system are you using this with?

Windows 10.

[Arkh42]

In "NI DC Power Supplies and SMUs Help", I found the following:

Accessing Attributes

[...]

Setting Properties and Attributes Before Reading Them

Properties and attributes are modified when you set them or when you call a configuration VI or function that sets them, respectively. It is important to set the properties or attributes or call any configuration VIs or functions before reading back any property or attribute values for the following reasons:

• [...]
• The driver verifies that the configuration of the session is valid at the time the property or attribute is read. It is possible to get an error when reading a property or attribute if the configuration is not valid at that point**, even when a setting later could make it valid.
• [...]

Could that be the reason for which a read-access operation in the above script raises an error, even though I am just trying to check the type of the returned variable?

[marcoskirsch]

Yes. Getting (reading) a property causes what is known as a "verify" operation, which looks at all the session's properties to confirm they are in a valid configuration, and raises if this is not the case. In your code, you get a property in order to see its type, but it doesn't really matter to the driver what your intent for getting the property is.

There are several reasons why the driver only looks at valid property values when the "verify" occurs, one example is to avoid ordering requirements on how you need to set properties.

Closing this since it isn't a bug in the nidcpower module, nor in the NI-DCPower driver runtime for that matter.