Skip to content

P99 Acquisition & Visualisation Interface Overhaul #373

Open
1 of 18 issues completed
Open

Description

@Relm-Arrowny

Transition the P99 CSXID interface from its current development state into an end-to-end UI. This issue tracks the core infrastructure and UI components required to build a multi-layered visualisation, stream real-time device, manage scan queue/script executions, and support workflows.

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

  • Interactive Mapping Data Overlay: The user can view live 2D STXM scan data, reconstructed ptychography images and read space image of sample as configurable, transparent layers on a single central canvas.
  • Mapping Data Overlay Region Selection: The user can interact with the plot (e.g. select an ROI) to automatically populate scan position text fields.
  • Device & Telemetry Readout: The user can view live device positions, setpoints, and environmental variables within the UI via EPICS API.
  • Scan Execution with Queue Management: The user can define multi-component scan plans, add them to an execution queue, monitor progress via an estimated duration progress bar showing the current scans ETA as well as an ETA for the whole Queue.
  • Manual Scripting Interface: The user can run manual scripts and custom plan execution using an terminal client.
  • Focus Scans: The user can execute scan along the beam direction or any direction they choose.

Tasks

base on the goals, deduce the tasks required. check them off once they're done

1 Live Data & Image Plotting

Note

What we trying to do here is highly related to the core milestone

  • [DataVis - Milestone 3] Canvas Throttling & Reduction: Add rendering limits to decouple incoming stream rates from UI frame rates to prevent UI freezing during fast acquisitions.
  • [DataVis - Milestone 5] View State Export & Annotations: Allow users to annotate regions, take snapshots, and export visual states or plots directly to the beamline logbook.
  • [DataVis - Milestone 6] Reconstruction Acceptance/Rerun Actions: In the Analysis tab, add controls to review reconstruction quality indicators, flag/tag datasets, and quickly re-trigger workflows with modified parameters.
  • [DataVis - Milestone 1] Manifest Filtering: Add search, filtering, and sorting to the completed scans manifest.

2 Device Readouts

3 Queue Management & Experiment Control

4 Backend Integration/ Experiment Manifest / Post Collection Tagging/ Pocessed Data

5 Focus Scans

Related Resources

BlueApi native client : #364

  • Note the sm-client is caching all the emitted data making local data processing completely......Local.

NumTracker: UI should be able to query the latest scan number.
Davidia: Integration if it provide everything we want and where and how to deploy it.
EPIC API : We need to find out if/when it become available.

Data Flow Diagram

flowchart TD
    subgraph Client / Interface
        UI[UI]
    end

    subgraph Control & Execution Layer
        blueAPI[blueAPI / RE]
        DAQ[DAQ QUEUE]
        Numtracker[Numtracker]
    end

    subgraph Messaging & Services
        RabbitMQ[RabbitMQ]
        GraphQL[GraphQL]
    end

    subgraph Storage & Pipeline Layer
        Devices[Devices]
        NexusWriter[NexusWriter]
        Tiled[Tiled]
        Disk[(disk)]
        Workflows[Workflows]
    end

    %% Flow Connections
    UI -- "REST API" --> blueAPI
    UI --> DAQ
    UI --> Devices
    UI --> GraphQL

    DAQ --> blueAPI
    blueAPI <--> Numtracker

    blueAPI --> RabbitMQ
    blueAPI --> Devices
    blueAPI --> Tiled

    RabbitMQ --> NexusWriter
    RabbitMQ --> Tiled

    Devices --> Disk(/dls/beamline/data)

    NexusWriter --> Disk
    Disk <--> Workflows

    Tiled --> Workflows
    GraphQL --> Workflows
Loading

UI mock:

Image Image

Additional context
Add any other context or screenshots about the feature request here.

Activity

  1. Relm-Arrowny commented on Sep 4, 2026

    @Relm-Arrowny
    CollaboratorAuthor

    Original meeting notes:
    What was shown:

    NL & RF demonstrated the current "development UI" on P99, performing a STXM-fast scan followed by running a workflow that reconstructs the image from this workflow. There were hardware and software issues with the scan so it was not possible to complete this process, but all of the components to run and reconstruct plans are there.
    NK showed some designs for the final interface, involving a left-hand panel where multi-component plans/ scans/ scripts are defined and run (added to Queue), a large central image showing the overlapping layered images and a panel on the right where data from scans or workflows are are selected and configured to be plotted in the central window.

    What was discussed:

    The limitations of the current interface are clear and the shape of the deployment interface are now becoming clearer, however it is unclear how to progress from one to the other. A backlog of tasks needs to be generated that breaks down the components of the final product into parts that can either be worked on by this team or be raised with core teams.

    Limitations of the current interface & workarounds:

    Current motor positions are not visible in the interface, making it difficult to know what positions to scan and what the limits are. The workaround is to look at EPICS. The ideal solution is to have a component that displays the current positions of selected devices.
    The visit directory must be entered manually on each of the screens. Ideally the current visit would be pulled from ULIMS and appear automatically (not even shown in the final).
    Scanned data (plotted STXM data) is not shown in the interface. The workaround is to use a jupyter notebook and the BlueSky python API to plot the data. Ideally this would appear and populate during the scan.
    Processed data (plotted Ptychography image) is not shown in the interface. The workaround is to see the output in the Workflows interface.
    There is little feedback when running a scan - ideally a progress bar would be shown.
    The current scan number is not shown and not propagated to the workflows input field.
    There is currently no way to process multiple scans using the workflow presented.
    Defining a new scan requires filling in a lot of text fields. Ideally this would be done through interacting with the image plots.
    There is currently no ability to stop a scan. Workaround - wait for the scan to stop, or for the Earth to be consumed by the sun, whichever comes first.
    There is currently no scripting or python interface. Workaround - use BlueAPI python client. An terminal for this could be added quite easily on the current interface.
    Focus scan - how to perform a series of single-axis scans over a sharp feature at multiple z positions?

    I think that most of the above can be turned into tickets that have some value to the final software. In addition, I think there are several interface components that we can start working on:

    Multi-component scan definition (ability to assemble multiple stages of a plan) - essentially something like the left hand panel of Neeli's proposed interface.
    Image plotting window with multiple transparent layers and ability to configure different layers independently. (See DataVis Reqs above).
    List of completed scans and workflows that can be used for plotting or additional processing. (Experiment manifest).
    4 repliesNeeli  [4:32 PM]
    Thanks for these Dan. I had a meeting with David Burn today and there have been some refinements to the design including potential to downgrade priority of the Multi-component scan definition as it was not the anticipated output of the MVP. However, I have added a few features including a component that displays device positions, setpoints and traces (attached). David and I also spoke about Focus scans and what they may look like in the UI (potential for tab buttons which switch the main canvas back and forth for the y-z and x-z views. I will share the more detailed notes of this meeting below.
    SVG Container.svgSVGNeeli  [10:31 AM]

    Image

    Epics:

    Multi-component scan definition (Not a priority - just the ability to run a stack of bluesky plans).
    Connect "queue" to interface. Define Queue.
    Linked list or Queue? For insertion of events, deletion, deferral. Needs to be evaluated.
    The ability to give estimated time for each process/bluesky plan with a progress bar (can be calculated, easy calculation can be done on frontend - motor speed, acceleration time, estimation etc). Core needs to be asked to see if this is being priorities as other beamlines will need this. Update the time as the plan goes on - should exist in BlueSky?
    BlueSky stack of plans initially.

    Analysis tab to list completed scans and workflows that can be used for plotting and additional processing
    Persisted data store for completed list of scans for downstream analysis. Potential use through Tiled (especially for tagging).
    Data tagging: Should be appended to the nexus file (Ask Fajin, other groups? Swift?).
    How would the view look like - is it ULIMS or Acquisition? Needs to be clarified.

    Devices readback
    Connection of PVs to the UI (not currently recommended by the UI team). Can do it through BlueSky (cant read when scan is being run) or through EPICS API (preferred).
    Can they see these motor positions from i15? Seems straight forward. Check with Raymond after a while.

    BlueSky/Api
    Common pattern to move something and then run a plan (focus scan and plan?) - is this exposed via BlueApi and the interface?
    How do we handle temperatures? This exists (i10, i06). Its just another device which can be interacted with. Should be exposed to the interface?
    Scan number? Blue API will ask numtracker but not immediately available. Potentially come from Tiled (p99 scan number), but its not immediately available. Evaluate numtracker by poking it - see if you can pull that.

    Data vis and unknown Backend (Data API?):
    Live updated 2D plot like in imaging interface in GDA, scanned data for STXM shown on the interface. Will be added as a live updated layer liken to operando map in SWIFT. Needs to be discussed.
    Image plotting window with multiple transparent layers and ability to configure different layers independently.  [BIG EPIC]
    Region of Interest and populating text fields based off this - Davidia?
    Offset, rotations, transformation matricies - persisted in data store or saved into the metadata for that scan (somehow). Including coordinate system for multiple layers - To be evaluated in the UI.
     Ability to convert coordinate system to sample and motor coordinate systems - where will this be stored? - To be evaluated.

    Data Analysis (Nathanael):
    Be able to pull reconstructed image from processing pipeline onto the UI
    Reconstructing from multiple scans to be investigated

    Other:
    Focus scans

    1.2/1.3 meeting:
    What is the single point of truth? Where to get the data from.
    Nexus file
    DataCats
    Tiled
    Which one should we read from and put data into? How, why and when? For tagged data specifically (edited) 
    Raymond Fan  [5:07 PM]
    Just putting more stuff here before I move them into tickets:
    This may be useful for live ploting and how we design live ploting.
    #364 (review)
    Neeli  [5:44 PM]
    Think Davidia was also considered for live plotting too. Not sure if these are adjacent? Or if anybody has played with the live plotting aspect @Nathanael Leung?

  2. changed the title [-]P99 Acquisition & Visualization Interface Overhaul[/-] [+]P99 Acquisition & Visualisation Interface Overhaul[/+] on Sep 4, 2026
  3. fajinyuan commented on Sep 9, 2026

    @fajinyuan
    Collaborator

    Thanks @Relm-Arrowny for this long and detailed descriptions. are they to replace JIRA MMG board? or complimentary to that?
    I will spend sometime to digest them.
    It looks most are GUI related, not function related.

  4. Relm-Arrowny commented on Sep 9, 2026

    @Relm-Arrowny
    CollaboratorAuthor

    Thanks @Relm-Arrowny for this long and detailed descriptions. are they to replace JIRA MMG board? or complimentary to that? I will spend sometime to digest them. It looks most are GUI related, not function related.

    I think no one other than me use the JIRA MMG board, so I would consider this as a replacement as these are the latest wish list from the i17 team. Section 1 is mostly GUI related but 2, 3, 4 are functional dependence on blueapi and epics.
    My summary judement is
    1 Requires the Data visualization milestones.
    2 Requires Epic API
    3 Require Queue and scripting service.
    4 Require ULIMS API.

  5. fajinyuan commented on Sep 9, 2026

    @fajinyuan
    Collaborator

    Thanks for the summary. I will have a look to see if I understand them and have any questions tomorrow.

  6. NKatti2011 commented on Sep 16, 2026

    @NKatti2011
    Collaborator

    @EmsArnold

    Corrections to this issue

    • There is no EPICS API. The acceptance criterion referring to device readout "via
      EPICS API" should be reworded. Device readout could go through csweblib for
      PV access (unknown); VISR uses PVWS for its UI . See Real-Time Device Readout Panel #381 for why
      reading back through Bluesky is not viable.
    • The UI mock in this issue is aspirational. Two specific things it shows are not
      confirmed to be supported: the Deferred queue state (see Queue Data Structure & UI Layout #382) and the Programme
      Library block editor.

    Shared decisions

    1. Tiled is the single point of truth. All data reaches the UI through Tiled rather
      than the UI selecting a different transport per data type. A NeXus writer sits behind
      Tiled (currently being developed). See Establish Single Point of Truth (SPOT) read/write rules between NeXus, DataCats, and Tiled. #389.
    2. Transformation maths should live in a standalone package, not inside Davidia and not
      inside the UI - To be confirmed. It is consumed by low-level controls (kHz feedback), by the UI
      (user-supplied offsets), and by the processing pipeline (post-reconstruction
      alignment). See Reference Frame Coordinate Transformations #379.
    3. Davidia is the intended rendering layer, client and server, and an evaluation of
      it is in progress. Several issues depend on the outcome: Live 2D STXM Data Streaming #375, Multi-Layer Canvas #376, Reconstructed Image Overlay #378, Reference Frame Coordinate Transformations #379,
      Interactive ROI Selection Tool #380 and Live 1D Data Plotting (Motor vs. Detector) #392.
    4. Applying a transformation from the UI moves motors. The ROI tool and offset
      controls need limit validation and confirmation.
      See Interactive ROI Selection Tool #380.
    5. The queue There is a single RunEngine, so parallel
      calls are not possible; work is expected to funnel through the queue. This applies to
      the scripting terminal (Embedded Python scripting terminal #387) and probably to interactive moves from the canvas (Interactive ROI Selection Tool #380).
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

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions