Use correct sense function for sense parameters in Keysight 344xxA driver

[janekfleper]

The Keysight344xxA class implements the sense parameters without checking the sense function.

The parameters in the SENSE subsystem have to be handled based on the current sense function. By default the VISA path is always "SENSe:VOLTage:DC" and the parameters will only get/set the values for the DC voltage measurement. The actual sense function that is currently used by the instrument completely ignored.

I was not entirely sure how to implement this. I had the following other ideas how to solve this:

1. Create a SenseParameter class that overrides get_raw() and set_raw() to read the sense function just before calling either get() or set(), but according to the documentation you cannot use both get_raw() and get_cmd at the same time. And it would also be overkill since I actually just need a decorator for the methods get_raw() and set_raw(), I don't need to completely modify them. Is there a way to add such a decorator?
2. Create an instrument module Keysight344xxASense for all the sense parameters to move them from the root instrument to self.sense. I could then override the methods ask() and write() in the module to "inject" the correct sense function path just before actually sending the command to the VISA handle.
3. Pass callable methods to the parameters get_cmd and set_cmd and manually call self.ask() and self.write() with the correct commands.

The merge request currently implements solution 3 for the parameters NPLC, autorange, autozero, aperture_mode and aperture_time. The parameters range and resolution are still missing since their validators require some extra work.

Are you happy with the current approach or would you prefer one of the other two solutions? Or is there something that I am missing completely that would make the implementation a lot more straight forward?

I am looking forward to your feedback!

[janekfleper]

@microsoft-github-policy-service agree company="University of Bonn"

[jenshnielsen]

@einsmein Could you review this since I think you looked at the 344xx not that long ago

[einsmein]

@janekfleper The second option would be ideal. It reflects the instrument interface where we specify measurement types with every sense function.
That being said, this approach makes sense given the interface we have now. (The non-ideal part is that by setting sense_function parameter, we implicitly modify the behavior of other parameters. But we can address that in the future.)

Have you tested this code on the instrument? In that case LGTM

[astafan8]

just a tiny correction :)

[janekfleper]

I have tested the changes on the model 34465A and I would also have the models 34470 and 34411A available for further testing. But since these models are all equally affected by the changes, I don't think it is necessary here.

[codecov]

Codecov Report

Attention: Patch coverage is 94.44444% with 1 line in your changes missing coverage. Please review.

Project coverage is 59.91%. Comparing base (fc91544) to head (d4504b3).
Report is 21 commits behind head on main.

Files with missing lines	Patch %	Lines
...ers/Keysight/private/Keysight_344xxA_submodules.py	94.44%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6723      +/-   ##
==========================================
+ Coverage   59.89%   59.91%   +0.02%     
==========================================
  Files         342      342              
  Lines       31459    31475      +16     
==========================================
+ Hits        18841    18857      +16     
  Misses      12618    12618              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.