Add Blocking to DynaCool PPMS During Temperature Ramp #7534

trlemon · 2025-09-29T23:35:48Z

Summary of Changes

Add blocking function to DynaCool PPMS driver that waits for temperature state to be stable before allowing other functions to be called when setting the temperature.

codecov · 2025-09-30T00:01:04Z

Codecov Report

❌ Patch coverage is 16.66667% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 59.88%. Comparing base (d337823) to head (67b78a9).

Files with missing lines	Patch %	Lines
...ent_drivers/QuantumDesign/DynaCoolPPMS/DynaCool.py	16.66%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7534      +/-   ##
==========================================
- Coverage   59.89%   59.88%   -0.01%     
==========================================
  Files         352      352              
  Lines       31806    31812       +6     
==========================================
+ Hits        19051    19052       +1     
- Misses      12755    12760       +5

☔ 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 · 2025-10-08T13:29:52Z

src/qcodes/instrument_drivers/QuantumDesign/DynaCoolPPMS/DynaCool.py

+    def _block_on_temperature_ramp(self) -> None:
+        """Block all instrument interactions until temperature stabilizes."""
+        while self.temperature_state() != "stable":
+            sleep(1)


let's make this sleep time configurable via an attrbiute on the class?

Added _blocking_t_sleep attribute.

This is better, however it's a private attribute, so as if it's not supposed to be touched by the users, which is not the case, i think it's totally fair that users can adjust that sleep time. So with that logic, i suggest to make it a memory/in-memory parameter (get_cmd=None, set_cmd=None), similar to how it's done with this parameter

Qcodes/src/qcodes/instrument_drivers/american_magnetics/AMI430_visa.py

Line 856 in d337823

self.ramping_state_check_interval = Parameter(

that controls sleep interval for a while loop that monitors magnetic field ramp.

astafan8 · 2025-10-08T13:31:01Z

src/qcodes/instrument_drivers/QuantumDesign/DynaCoolPPMS/DynaCool.py

        values[self.temp_params.index(param)] = value

        self.write(f"TEMP {values[0]}, {values[1]}, {values[2]}")
+        self._block_on_temperature_ramp()


i'd suggest to leave the current T parameter's implementation as-is in order not to break any existing code in terms of the fact that now setting the temperature blocks; and instead implement a new parameter that includes the "block on ramp". What do you think?

I created a new parameter to address this but also added a default bool to _temp_setter to control blocking functionality without breaking current implementation of the original temperature setting parameters.

I am not a big fan of having two parameters that control the temperature. Which one is the source of truth? I would have made a manual boolean parameter (block_during_temperature_ramp) and then make that one control the behaviour of the existing temperature parameter

My guess is that we're trying to follow the pattern that was established in lakeshore temperature controller driver https://microsoft.github.io/Qcodes/examples/driver_examples/Qcodes%20example%20with%20Lakeshore%20336%20or%20372%20-%20Bluefors%20T%20control.html#Sweeping/blocking-paramameter where there's setpoint parameter that's not blocking, and a blocking_t parameter that does the same as setpoint but also blocks until it's reached.

I'd be in favor of keeping consistency across the drivers (even if it's likely opinionated), so having both setpoint and blocking_t parameters is ok as long as their caches are in sync, i left a separate comment about it.

…ppms

…revent breaking current implementations.

…ppms

…-dynacool-ppms

SherwanMicrosoft · 2025-12-19T09:56:38Z

Testing Results - Bug Found

Environment:

PPMS: Quantum Design DynaCool
QCodes version: 0.55.0.dev194 (this PR branch)
Testing date: December 19, 2025

Issue: `blocking_t()` causes PPMS server crash

Steps to Reproduce:

Fresh PPMS connection - reads work normally (ppms.temperature() ✓)
Execute: ppms.blocking_t(300)
Result: VI_ERROR_IO on the TEMP write command
Subsequent reads fail with VI_ERROR_CONN_LOST
PPMS server connection is lost

Error Details:
VisaIOError: VI_ERROR_IO (-1073807298): Could not perform operation because of I/O error
at DynaCool.py:434 in write(): self._error_code = int(self.visa_handle.read())

Then:
VisaIOError: VI_ERROR_CONN_LOST (-1073807194): The connection for the given session has been lost

Observations:

✅ ppms.temperature_setpoint() (non-blocking) works fine
❌ ppms.blocking_t() crashes the connection
✅ blocking_t parameter exists and is configured correctly
Issue occurs immediately when TEMP command is sent with blocking enabled

Root Cause Analysis:
The failure occurs at line 434 when trying to read the error code response after sending the TEMP command. The PPMS receives the command but fails to respond, then the connection is lost.

…ppms

…-dynacool-ppms

trlemon · 2026-01-02T19:48:11Z

@SherwanMicrosoft My last commit resolves this issue. Thank you for the detailed report!

…ppms

astafan8

a few small comments, but otherwise ready for merge!

astafan8 · 2026-01-14T08:58:07Z

src/qcodes/instrument_drivers/QuantumDesign/DynaCoolPPMS/DynaCool.py


+        self.blocking_t: Parameter = self.add_parameter(
+            "blocking_t",
+            label="Block instrument while ramping temp",


Suggested change

label="Block instrument while ramping temp",

label="Block instrument while ramping temperature",

astafan8 · 2026-01-14T08:59:13Z

src/qcodes/instrument_drivers/QuantumDesign/DynaCoolPPMS/DynaCool.py

        )
        """Parameter temperature_setpoint"""

+        self.blocking_t: Parameter = self.add_parameter(


could you mention this parameter in the example notebook https://microsoft.github.io/Qcodes/examples/driver_examples/Qcodes%20example%20with%20DynaCool%20PPMS.html ?

astafan8 · 2026-01-14T09:02:52Z

src/qcodes/instrument_drivers/QuantumDesign/DynaCoolPPMS/DynaCool.py

+    def _block_on_temperature_ramp(self) -> None:
+        """Block all instrument interactions until temperature stabilizes."""
+        while self.temperature_state() != "stable":
+            sleep(1)


This is better, however it's a private attribute, so as if it's not supposed to be touched by the users, which is not the case, i think it's totally fair that users can adjust that sleep time. So with that logic, i suggest to make it a memory/in-memory parameter (get_cmd=None, set_cmd=None), similar to how it's done with this parameter

Qcodes/src/qcodes/instrument_drivers/american_magnetics/AMI430_visa.py

Line 856 in d337823

self.ramping_state_check_interval = Parameter(

that controls sleep interval for a while loop that monitors magnetic field ramp.

astafan8 · 2026-01-14T09:09:23Z

src/qcodes/instrument_drivers/QuantumDesign/DynaCoolPPMS/DynaCool.py

        values[self.temp_params.index(param)] = value

        self.write(f"TEMP {values[0]}, {values[1]}, {values[2]}")
+        self._block_on_temperature_ramp()


My guess is that we're trying to follow the pattern that was established in lakeshore temperature controller driver https://microsoft.github.io/Qcodes/examples/driver_examples/Qcodes%20example%20with%20Lakeshore%20336%20or%20372%20-%20Bluefors%20T%20control.html#Sweeping/blocking-paramameter where there's setpoint parameter that's not blocking, and a blocking_t parameter that does the same as setpoint but also blocks until it's reached.

I'd be in favor of keeping consistency across the drivers (even if it's likely opinionated), so having both setpoint and blocking_t parameters is ok as long as their caches are in sync, i left a separate comment about it.

astafan8 · 2026-01-14T09:14:41Z

src/qcodes/instrument_drivers/QuantumDesign/DynaCoolPPMS/DynaCool.py

+            label="Block instrument while ramping temp",
+            unit="K",
+            vals=vals.Numbers(1.6, 400),
+            set_cmd=partial(


let's make this parameter not gettable (explicitly :) )

Suggested change

set_cmd=partial(

get_cmd=False,

set_cmd=partial(

astafan8 · 2026-01-14T09:21:06Z

src/qcodes/instrument_drivers/QuantumDesign/DynaCoolPPMS/DynaCool.py

+        if block_while_ramping:
+            while self.temperature_state() != "stable":
+                sleep(self._blocking_t_sleep)
+


let's make sure that the caches of the two temperature parameters are in sync when either of them gets set. Note that private method _set_from_raw_value is used since we operate inside this method with raw values (not values, which could have offset/scale), so for correctness reasons we need to use the private method, which is OK to use inside qcodes and inside driver code, just not in user facing measurement code.

Suggested change

self.setpoint.cache._set_from_raw_value(values[0])

self.blocking_t.cache._set_from_raw_value(values[0])

Thomas Lemon added 2 commits September 29, 2025 16:23

Add blocking during temperature ramp

8aadf38

Update newsfragment for DynaCool PPMS driver improvement

3de5952

astafan8 reviewed Oct 8, 2025

View reviewed changes

trlemon and others added 9 commits October 15, 2025 10:14

Merge branch 'main' into tlemon/add-temperature-blocking-to-dynacool-…

e605648

…ppms

Add optional bool to _temp_setter to control blocking_t function to p…

433c77f

…revent breaking current implementations.

Use new attribute for blocking_t sleep

ce37e3c

Merge branch 'main' into tlemon/add-temperature-blocking-to-dynacool-…

00b6c84

…ppms

Merge branch 'main' into tlemon/add-temperature-blocking-to-dynacool-…

27b9edc

…ppms

Merge branch 'main' into tlemon/add-temperature-blocking-to-dynacool-…

d4c0960

…ppms

Merge branch 'main' into tlemon/add-temperature-blocking-to-dynacool-…

c1b3b19

…ppms

Merge branch 'microsoft:main' into tlemon/add-temperature-blocking-to…

dc50bb3

…-dynacool-ppms

Merge branch 'microsoft:main' into tlemon/add-temperature-blocking-to…

5f11aae

…-dynacool-ppms

trlemon and others added 3 commits December 19, 2025 09:12

Merge branch 'main' into tlemon/add-temperature-blocking-to-dynacool-…

8cf5199

…ppms

Merge branch 'microsoft:main' into tlemon/add-temperature-blocking-to…

f2708e2

…-dynacool-ppms

Fix bug that crashes PPMS server

6f650c8

trlemon added 2 commits January 2, 2026 11:48

Merge branch 'main' into tlemon/add-temperature-blocking-to-dynacool-…

326244f

…ppms

Merge branch 'main' into tlemon/add-temperature-blocking-to-dynacool-…

f0f0a23

…ppms

trlemon marked this pull request as ready for review January 6, 2026 23:30

trlemon requested a review from a team as a code owner January 6, 2026 23:30

Merge branch 'main' into tlemon/add-temperature-blocking-to-dynacool-…

67b78a9

…ppms

astafan8 approved these changes Jan 14, 2026

View reviewed changes

	label="Block instrument while ramping temp",
	label="Block instrument while ramping temperature",


	self.setpoint.cache._set_from_raw_value(values[0])
	self.blocking_t.cache._set_from_raw_value(values[0])

Add Blocking to DynaCool PPMS During Temperature Ramp #7534

Are you sure you want to change the base?

Add Blocking to DynaCool PPMS During Temperature Ramp #7534

Conversation

trlemon commented Sep 29, 2025

Summary of Changes

Uh oh!

codecov bot commented Sep 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SherwanMicrosoft commented Dec 19, 2025

Testing Results - Bug Found

Issue: blocking_t() causes PPMS server crash

Uh oh!

trlemon commented Jan 2, 2026

Uh oh!

astafan8 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

codecov bot commented Sep 30, 2025 •

edited

Loading

Issue: `blocking_t()` causes PPMS server crash