Fix bug which prevents Lakeshore blocking_t from exiting

[trlemon]

Issue

When setting blocking_t(), in the function wait_until_setpoint_reached(), the setpoint parameter is called to get the latest setpoint. However, this can be problematic since it doesn't always fetch the last set setpoint, likely due to the setpoint parameter being called before the instrument has time to update properly. If the wrong setpoint is returned, then the while loop inside of wait_until_setpoint_reached() will never exit because the temperature will never be in tolerance.

Solution (changes)

Call self.setpoint.get_latest() instead of self.setpoint() to ensure the last set value is used instead.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 59.90%. Comparing base (aa276ab) to head (65d54e2).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #7796   +/-   ##
=======================================
  Coverage   59.90%   59.90%           
=======================================
  Files         352      352           
  Lines       31810    31813    +3     
=======================================
+ Hits        19055    19058    +3     
  Misses      12755    12755           

☔ 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.

[astafan8]

So are you saying there's evidence that when setpoint() parameter is set e.g. .setpoint(1), and then you immediately (or shortly after) get it .setpoint() (or .setpoint.get()) then the returned value is not 1 but some previously set setpoint value? And have you tested how much time it takes for the instrument to start returning the correct setpoint value? Because if this is really the issue, then i suggest to add a post_delay to setpoint parameter (say 1 second, or whatever it takes), so that whenver users set .setpoint() parameter they are sure that once the call returns the setpoint value is actually set on the instrument.

In qcodes one of the basic design decisions or wishes is that when setting a parameter on an instrument, once the parameter set call returns, the user can be sure that the parameter on the instrument is set to the desired value. This is not possible at all times, but in 99% of the cases that's how instruments work (which is great). In cases when it does not work, time.sleep usually comes to help in the form of setting post_delay attribute on a parameter. And my experience shows that if a parameter set call returns but it turnes out the instrument needs a bit of time to actually set that parameter to a value internally, then experimentatlists/measurers will be adding time.sleep to their measurement scripts :)

[trlemon]

@astafan8 Yes, there is evidence this is the case (please see screenshot below, where I set the setpoint to 6K, but it was reading the setpoint as 6.5K while ramping down to 6K).

I have not yet tested how much time it takes for the instrument to start returning the correct setpoint value. I will investigate this specifically and set an appropriate time delay instead of using get_latest().

[trlemon]

@astafan8 I ran a limited set of tests and found that it took up to 110 ms for the instrument to return the expected setpoint. I added a short delay of 0.5 seconds which is configurable by the "setpoint_settle_delay" parameter.