Skip to content

Add a scan progress bar with calculated time-to-completion based on motor speeds and count time etc. #384

Open

Description

@Relm-Arrowny

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.

Activity

  1. DanPorter commented on Sep 16, 2026

    @DanPorter
    Collaborator
  2. NKatti2011 commented on Sep 16, 2026

    @NKatti2011
    Collaborator

    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.

    Update - @jacob-williamson

    • 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions