Repository navigation
Description
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
- Live 1D Data Plotting (Motor vs. Detector) #392
- 1D Image Slice Viewer & Frame Slider #393
- Live 2D STXM Data Streaming #375
- Multi-Layer Canvas #376
- Reconstructed Image Overlay #378
- Reference Frame Coordinate Transformations #379
- Transformation Matrix: Implement transformation logic to map external coordinate spaces into the beam frame, (e.g. Sample camera view, reconstructed ptychography coordinate, Sample stage coordinate)
- Interactive ROI Selection Tool #380
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
- Queue Data Structure & UI Layout #382
- Program Block Definition & Plan Composition #383
- Add a scan progress bar with calculated time-to-completion based on motor speeds and count time etc. #384
- Add an explicit Stop / pause /Abort Scan UI control. #385
- Integrate UI scan number tracking via numtracker or Tiled endpoints. #386
- Embedded Python scripting terminal #387
4 Backend Integration/ Experiment Manifest / Post Collection Tagging/ Pocessed Data
- ULIMS Integration for Visit Directories #388
- Establish Single Point of Truth (SPOT) read/write rules between NeXus, DataCats, and Tiled. #389
- Implement data tagging that appends to (NeXus files || Tiled || DataCat).
- Enable multi-scan selection for workflow reconstruction. #390
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
UI mock:
Additional context
Add any other context or screenshots about the feature request here.
Activity
Relm-Arrowny commentedon Sep 4, 2026
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]
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?
[-]P99 Acquisition & Visualization Interface Overhaul[/-][+]P99 Acquisition & Visualisation Interface Overhaul[/+]fajinyuan commentedon Sep 9, 2026
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.
Relm-Arrowny commentedon Sep 9, 2026
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.
fajinyuan commentedon Sep 9, 2026
Thanks for the summary. I will have a look to see if I understand them and have any questions tomorrow.
NKatti2011 commentedon Sep 16, 2026
@EmsArnold
Corrections to this issue
EPICS API" should be reworded. Device readout could go through
csweblibforPV access (unknown); VISR uses PVWS for its UI . See Real-Time Device Readout Panel #381 for why
reading back through Bluesky is not viable.
confirmed to be supported: the
Deferredqueue state (see Queue Data Structure & UI Layout #382) and the ProgrammeLibrary block editor.
Shared decisions
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.
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.
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.
controls need limit validation and confirmation.
See Interactive ROI Selection Tool #380.
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).