Silently ignore and change value when passing minimum value to source_delay attribute in nidcpower

[Arkh42]

Description of issue

When trying to pass the minimum value for the source trigger delay, which is 0 s for the PXIe-4163, the value is silently ignored by the driver and changed to another value (approximately 138.89 ns).

The minimum acceptable value is documented in the NI official documentation here and there.

System report

When the test presented below is executed, the following error is raised:

```
AssertionError: assert hightime.timedelta(femtoseconds=138888889) == datetime.timedelta(0)
```

Steps to reproduce issue

  import datetime
  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_write_access_lower_limit(smu):

      smu.source_delay = datetime.timedelta(microseconds=0.0)
      assert smu.source_delay == datetime.timedelta(microseconds=0.0)

1. Run pytest on the above script.
2. The test fails and raises the AssertionError

The error is raised for a simulated instrument ('simulate': True) and for real instrument ('simulate': False).

[ni-jfitzger]

@Arkh42 this sounds like a driver issue, not an API issue.

As stated in the README

For support with hardware, the driver runtime or any other questions not specific to the Python API, please visit NI Community Forums.

[marcoskirsch]

I don't think this is a driver runtime bug. Rather I think this is the driver's correct behavior. In NI-DCPower (and most NI drivers) when you read back a property, you get the coerced value which is what the hardware can actually accomplish.

I am not surprised that a strict source delay of 0 cannot be accomplished by the hardware. This is a digital device that needs to emit a Source Complete Event and this takes some minimum discrete amount of time.

I am not surprised that the NI-DCPower driver developers allow you to set 0 even if strictly speaking the hardware is not doing 0.

[Arkh42]

I am not surprised that a strict source delay of 0 cannot be accomplished by the hardware. This is a digital device that needs to emit a Source Complete Event and this takes some minimum discrete amount of time.

In understand your answer, and it sounds an intuitive good reason.

However, in this case, there is an error in all NI documentation, because this value of 0 s is in fact documented in "NI-DCPower Properties", p. 80, without any warning regarding the instrument's hardware response time. (The documentation can be accessed here.)

So, what would be your advice in this matter?

[tobiasgordon]

Apologies for the delay, my reply got deprioritized for a while and then lost in a folder over the end-of-year goings-on.

I agree the documentation is less than helpful. We should clarify that although 0 seconds can be set as a value, reading it back will report the actual coerced source delay. Bug 2649858 has now been filed to improve the documentation.

To create the Bug, I clicked the "No" button on the "Was this information helpful?" at the bottom of the documentation page. This gave a pop-up where I was able to fill in details. Submitting this automatically creates an internal Bug for NI tracking purposes. It will be prioritized against our other work, but is simple enough to tackle.