You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add a scan progress bar with calculated time-to-completion based on motor speeds and count time etc. #384
Part of #373 Queue Management & Experiment Control
Implement visual progress feedback including dynamic progress bars and remaining duration calculations during scan execution
Goals
Acceptance criteria : What journeys should the user be able to complete to consider your feature done
Be as specific as you can, check them off once they work. Add more if you find more requirements during development. Issue should only be considered done after all of them are checked
The user can view an active scan's execution progress bar with an estimated time remaining.
Tasks
base on the goals, deduce the tasks required. check them off once they're done
Duration Estimator: Build a calculator using motor speed, acceleration, range, and scan resolution to compute estimated plan runtimes, this most likely will be done with Bluesky simulation or something build into plan direction, to allow estimate of the plan progression.
Progress Updates API: Subscribe to BlueSky plan event milestones to update progress bar states dynamically.
Below include notes from a meeting with @EmsArnold.
Two existing estimators to evaluate before writing our own:
A naive runtime estimator is landing on the SuperGraph soon. It may only work for ULIMS
experiments, in which case an equivalent could be written for another beamline.
Worth establishing which of these we can consume, and whether either is accurate enough to
drive both the per-scan ETA and the whole-queue ETA required by #373, before committing to
motor-speed/count-time calculation in the UI. Though It is likely we will have to write our own for the beamline.
There is a repo on gitlab, one central deployment but there will be different implementation or calculations per beamline - each beamline that wants to use the service will have to write that. New field on the experiment type on supergraph (dev). Graphql queries - request for a particular visit, get me experiment with this id and get me these fields on it - if one of the fields is runtime then the service is queried separately. Works on the ULIMS dev graph currently but not on actual supergraph.
There has been some talk about simulating the entire plan, and simulating the motor moves but this is very far in the future.
Activity
DanPorter commentedon Sep 16, 2026
This overlaps with the proposed solution for Waffle:
https://gitlab.diamond.ac.uk/sscc-docs/architectural-decision-records/-/blob/main/docs/records/0022.md
NKatti2011 commentedon Sep 16, 2026
Below include notes from a meeting with @EmsArnold.
Two existing estimators to evaluate before writing our own:
experiments, in which case an equivalent could be written for another beamline.
Worth establishing which of these we can consume, and whether either is accurate enough to
drive both the per-scan ETA and the whole-queue ETA required by #373, before committing to
motor-speed/count-time calculation in the UI. Though It is likely we will have to write our own for the beamline.
Update - @jacob-williamson