Skip to content

Feat/device power control - #22

Merged
jasasonc merged 7 commits into
masterfrom
feat/device-power-control
Jul 10, 2026
Merged

Feat/device power control#22
jasasonc merged 7 commits into
masterfrom
feat/device-power-control

Conversation

@jasasonc

Copy link
Copy Markdown
Collaborator

Adds software power control and makes connect() ride out a cooling camera.

  • standby()/power_on()/power_state: cut power / spin the cooler down and back
    up without unplugging.
  • reset(): firmware reboot; clears the cached IP so reconnect re-discovers the
    camera (it can come up on a new link-local IP).
  • connect()/wait_until_ready(): short timeout (~10s) when the camera is
    unresponsive, long one (~600s) while it's actively cooling.

Closes #15

jasasonc added 7 commits July 8, 2026 12:27
- power_state / standby() / power_on(wait=True): command the Stirling cooler
  off and on via REG_DEVICE_POWER_STATE_SETPOINT. Standby keeps the GVCP
  connection open (it is not a reset), so the camera can be quieted and its
  power cut during idle periods without unplugging; power_on waits for the
  detector to re-cool. Idempotent; docstrings note the cooler cycle-life cost.

- reset(): issue a firmware reset via REG_DEVICE_RESET (0xD340). The camera
  reboots and the control channel drops, so the call marks the Camera
  disconnected; reconnect once it has rebooted.

- connect(timeout=...): forward the timeout to wait_until_ready so connecting
  to a freshly powered, still-cooling camera no longer fails at the fixed
  120 s. Closes #15.
# Conflicts:
#	docs/source/changelog.rst
wait_until_ready() now uses two budgets instead of a fixed 120 s: a short
timeout (default 10 s) while the camera is unresponsive/stuck, and a long
cooling_timeout (default 600 s) while it reports it is actively cooling or
initialising (from TDC status). So a from-cold camera is waited out, while a
genuinely absent one fails fast. connect() forwards both; power_on()'s timeout
now maps to the cooling budget. Refines the #15 fix.
A firmware reset reboots the camera, which can bring it up on a new link-local
IP. The Camera object kept the old address, so reset() then connect() on the
same object chased a dead IP and never reconnected. reset() now clears
_camera_ip so the next connect() auto-discovers the rebooted camera. Verified on
hardware: reset -> reconnect on the same object in ~95s. Hardware reset test
hardened to retry-connect through the reboot.
…ontrol

# Conflicts:
#	docs/source/changelog.rst
#	tests/test_camera.py
@jasasonc
jasasonc merged commit 4fe47e9 into master Jul 10, 2026
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

connect() cannot extend the 120 s cooldown wait

1 participant