Skip to main content

Runs and history

The History page at /runs lists stored tunes with filters and pagination. Full-mode filter selections and page offsets are encoded in the URL, so reloads and browser back/forward navigation restore the same view. Opening a run and returning to History preserves that query. Invalid filter values are reset with an inline explanation. Demo keeps pagination but does not accept Full-only filter parameters. The list and tune form fit viewports at and below 1024 pixels; the history table scrolls inside its own container when it is wider than the screen.

A run detail page at /runs/:id shows the live or completed trend, configuration, results, notes, initial readings, and PID audit information. The run ID in its heading can be copied; the selected OPC ItemID in the tag browser has the same action. Each copy control reports success only after the clipboard accepts the value and explains when copying is unavailable.

History list​

BHTune Full mode History page with filterable tune-run rows
History provides filterable, paginated access to stored runs; open a row for its complete detail and audit trail.

Demo history is private to the anonymous browser session that created it. A different browser profile receives the same 404 for another session's run ID.

BHTune Demo mode visitor-private History page
Demo history uses the same list shape while the server scopes every row to the current anonymous session.

Live run detail​

While a run is active, the trend chart streams persisted samples over Server-Sent Events. The initial PV/MV readings appear before the first MRFT sample, and a Cancel run action follows the same abort-and-restore path as the CLI. Simulator timestamps use the configured fixed poll step; live OPC DA timestamps use monotonic elapsed time projected onto the run start.

BHTune Full mode active run detail with live PV and MV trend and cancellation control
Live run detail combines progress, current measurements, the streaming trend, and the safety action to cancel.
BHTune Demo mode active simulator run detail with live trend
Demo runs use the same live trend and cancellation workflow, but cannot access live-plant actions.

Completed run detail​

Once a run completes, the page hands the chart to the stored samples and shows the calculated results before the trend. The trend adds presentation-only initial-reading and restored-MV boundary points; exports contain the persisted sample series. Invalid results remain visible with a reason and cannot be written as PID constants.

The run-detail page announces outcome changes through a polite screen-reader status region without announcing every streamed sample. The live progress panel shows the current tick, PV, MV, and cycle counts. The trend legend uses PV and Commanded MV; plotted values are not converted and engineering units are not inferred. The Full-mode Summary retains the recorded run tag. There is no point selector, recorded-tag caption, or repeated measurement readout beneath the chart. A hidden description lets screen readers read the figure's plotted point count, time span, axes, and observed PV/MV ranges; it does not add measurements or controls.

BHTune Full mode completed run detail with calculated results, trend, summary, notes, and audit sections
Completed detail promotes calculated results above the trend and keeps the full run evidence below in collapsible sections.
BHTune Demo mode completed simulator run detail with calculated results, trend, and summary
Demo completion shows simulator results and recorded run context without any write-back controls.

The page's independently collapsible sections include Summary, Notes, Test configuration, Initial readings, and PID change history. Live progress stays above the trend without a repeated measurement-count footer beneath the sections. When a live OPC DA run stored a gateway compatibility snapshot, Summary shows it as a badge: full, partial, unknown, or incompatible. Simulator runs and older runs have no badge. See OPC gateway compatibility. Sampling and latency diagnostics remain recorded and available through bhtune history show, the run-detail API, and structured logs rather than a panel or tuning-quality badge on this page. Invalid calculated results, failed runs, and incomplete restoration remain visible.

Reviewing PID actions​

Eligible completed OPC DA runs show Review & write for each calculated response level. The review popup names the loop tag, response level, snapshotted parameter labels, exact destination tags, and values. Apply closes the popup while the request continues in the background; physical write and readback failures appear in the page alert and audit table.

The table and write popup use the same backend-generated controller targets: Yokogawa displays one decimal place, while the other built-ins use three significant digits. The run retains its template's precision policy even after catalog edits. The run-detail API keeps raw calculated values in their original fields and exposes controller-ready values separately. A result whose active term would round to zero is Unwritable, with a reason and disabled write action; its raw calculation status is unchanged.

BHTune PID review modal showing the exact response level, destination tags, and values before a write
The safety review is the last visual confirmation before calculated PID values are sent to a live controller.

The newest successful write offers Restore previous values through the same popup. The restore review and the audit show the recorded values without applying template rounding. Both actions are disabled with a reason unless the run is finished, used OPC DA, has all PID tags, and recorded its original server and bridge connection. Export CSV/JSON, Delete tune, and Duplicate this run are available from the completed detail page. CSV/JSON downloads contain the recorded samples only, not run metadata or calculated results. Delete tune opens a styled confirmation dialog before it removes the run's persisted samples, calculated results, and PID write/audit history; the deletion cannot be undone through the UI. While the request is pending, the dialog's confirm, cancel, close, backdrop, and Escape dismissal paths are locked. A failed request leaves the dialog open with an inline retryable error and leaves the run in history; retrying uses the same dialog and removes the run only after a successful response, then returns to /runs.

BHTune failed completed-run deletion confirmation with an inline retry error
Run deletion is a retryable, styled confirmation: the failed attempt does not change history, while the successful retry removes the run and navigates back to History.