WIP: show busy state in GUI while energy change is in flight #216

2026-09-10T16:32:57+02:00

duan_j commented

2026-09-10 16:32:57 +02:00

WIP - GUI-only. Not yet tested against a real mono move on X10SA.

Why

PUT /beamline/change_energy never takes the hw lock, so /status.busy
stays False for the whole mono move (minutes). The GUI only had a readback
heuristic: spin green until within 1 eV of target, or green forever if the
mono missed (the case bec_worker itself warns about). Two Set Energy rows
kept independent state, so a click in one showed nothing in the other.

What

The endpoint blocks server-side until the move ends, so the PUT reply edge
is the "done" signal - same trick as center_loop / AUTO CENTERING.

daq_worker: new energy_changing(bool) signal, True on send, False on
reply.finished (fires on error too, flag always clears)
SpinMoveState.set_changing: forces moving + read-only spin (blocks a
second request racing the first), clears to neutral without waiting for
arrival
both Set Energy rows (Beamline setup, Exp. Config.): button reads
"Changing..." during the move
sample cameras: red animated CHANGING ENERGY curtain, same tier as
AUTO CENTERING
tests for the edge on SpinMoveState, both panels, overlay, camera, worker

Not in this PR

Other GUIs stay blind: only the clicking GUI sees the request. Needs the
server to take the hw lock (@needs_hw_lock on change_energy, as
mono_pitch_scan already does). Separate PR, changes server semantics
(concurrent hw ops would get BeamlineBusyException).
Passive Axis views get no curtain (mirrors AUTO CENTERING).

To verify before un-WIP

real energy change on X10SA: badge appears, both rows lock, all clear
when the move ends
failed change (BEC error) still clears the busy state

Generated with Claude Code

WIP - GUI-only. Not yet tested against a real mono move on X10SA. ## Why `PUT /beamline/change_energy` never takes the hw lock, so `/status.busy` stays False for the whole mono move (minutes). The GUI only had a readback heuristic: spin green until within 1 eV of target, or green forever if the mono missed (the case bec_worker itself warns about). Two Set Energy rows kept independent state, so a click in one showed nothing in the other. ## What The endpoint blocks server-side until the move ends, so the PUT reply edge is the "done" signal - same trick as `center_loop` / AUTO CENTERING. - `daq_worker`: new `energy_changing(bool)` signal, True on send, False on `reply.finished` (fires on error too, flag always clears) - `SpinMoveState.set_changing`: forces moving + read-only spin (blocks a second request racing the first), clears to neutral without waiting for arrival - both Set Energy rows (Beamline setup, Exp. Config.): button reads "Changing..." during the move - sample cameras: red animated CHANGING ENERGY curtain, same tier as AUTO CENTERING - tests for the edge on SpinMoveState, both panels, overlay, camera, worker ## Not in this PR - Other GUIs stay blind: only the clicking GUI sees the request. Needs the server to take the hw lock (`@needs_hw_lock` on `change_energy`, as `mono_pitch_scan` already does). Separate PR, changes server semantics (concurrent hw ops would get BeamlineBusyException). - Passive Axis views get no curtain (mirrors AUTO CENTERING). ## To verify before un-WIP - [ ] real energy change on X10SA: badge appears, both rows lock, all clear when the move ends - [ ] failed change (BEC error) still clears the busy state Generated with [Claude Code](https://claude.com/claude-code)

gitea-actions bot commented

2026-09-10 16:35:19 +02:00

Coverage report (automated)

Total line + branch coverage: 51%
Diff coverage vs main: 100% (minimum 80%)

Full report: coverage artifact on this run.

Coverage report (automated) Total line + branch coverage: 51% Diff coverage vs main: 100% (minimum 80%) Full report: coverage artifact on this run.

duan_j added 1 commit 2026-09-10 16:36:43 +02:00

feat: show busy state in GUI while energy change is in flight

CI / lint (push) Skipped

CI / test (3.12) (push) Skipped

CI / test (3.13) (push) Skipped

CI / test-with-beamline-plugins (pxi_bec) (push) Skipped

CI / test-with-beamline-plugins (pxii_bec) (push) Skipped

CI / test-with-beamline-plugins (pxiii_bec) (push) Skipped

CI / lint (pull_request) Successful in 1m0s

Details

CI / test (3.12) (pull_request) Successful in 1m8s

Details

CI / test (3.13) (pull_request) Successful in 1m12s

Details

CI / test (3.14) (pull_request) Successful in 1m11s

Details

CI / test-with-beamline-plugins (pxi_bec) (pull_request) Successful in 1m14s

Details

CI / test-with-beamline-plugins (pxii_bec) (pull_request) Successful in 1m28s

Details

CI / test-with-beamline-plugins (pxiii_bec) (pull_request) Successful in 1m34s

Details

CI / test-with-coverage (pull_request) Successful in 1m51s

Details

CI / coverage-analysis (pull_request) Successful in 20s

Details

6c95727532

Server never takes the hw lock for /beamline/change_energy, so
/status.busy stays False for the whole mono move and the GUI had only
a readback heuristic (spin green until within 1 eV, or green forever
if the mono missed). The endpoint blocks until the move ends, so the
reply edge is used as the done signal, same as center_loop:

- daq_worker: energy_changing(bool) emitted on send / reply.finished
- SpinMoveState.set_changing: forces moving + read-only, clears to
  neutral without waiting for arrival (both Set Energy rows follow)
- panels: button reads "Changing..." during the move
- sample cameras: "CHANGING ENERGY" curtain, same tier as AUTO CENTERING

GUI-only: other GUIs stay blind until the server takes the hw lock.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

duan_j force-pushed show-busy-when-changing-energy from 9a56795720 to 6c95727532

2026-09-10 16:36:43 +02:00

Compare

duan_j closed this pull request

2026-09-10 16:40:21 +02:00

Pull request closed

Please reopen this pull request to perform a merge.

This pull request is marked as a work in progress.

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: mx/AareDAQ#216