Unit panels on View
The stack of cards a Process unit is operated through, as it appears on the View page: how it gets there, what each card shows and lets you do, and the Process permissions it obeys.
A unit panel is a Process surface standing on the View page: the cards a model arranged for operating its units, drawn for one unit. It is not a dashboard. Nothing about it is composed on a grid, no editor opens on it, and every unit of the model operates through the same cards, so a bench of four identical stations is arranged once. The arrangement is made on the model's Panels row in the Process workspace (Panels); this page covers the panel as View shows it.
How a panel gets onto View
Each panel of a model carries a Show on View switch on its row's bar in the Process
workspace (it needs the Manage process permission). Turned on, the panel puts one entry
per unit of the model in the Visualization column, named Model · Unit · Panel and
wearing the icon picked on the panel, or the fixed mark of a panel when none was picked.
The entries stand under the Unit panels heading after your folders and screens until
you file one into a folder from its row's menu, exactly like a screen of your own; a model
that has no unit puts nothing there. A model's screen shown on View the same way is a
different thing: it runs on the canvas, resolved for its unit, and is covered at the end of
this page.
The stage bar names the entry with its full name and offers Edit in Process for a role that may manage models, which opens the panel's own row on the Process page. Copy and Edit are not drawn: there is no layout to take. Expand and Full screen work as on any screen, and the status bar stays on.
Permissions
Seeing a unit panel needs Look at models; the visibility checklist of your own dashboards does not apply. Everything that commands the unit needs Run procedures, and a role without it reads the notice at the top of the stack: "You can watch this unit's run state here, but starting or steering it needs the “Run procedures” permission." The run card then draws neither the procedure choice nor the lifecycle buttons, the single commands card is not drawn at all, the Metadata entries are disabled, and a command component inside a card wears the lock mark with "Run procedures permission required." in its tooltip. The Operate dashboards permission plays no part here.
Two more refusals come from the station rather than the role, and both are said on the card that fired the command: why the station as a whole is not accepting run operations (the runtime stopped: "Runtime stopped"), and why this unit in particular is not (an execution barrier such as a tripped interlock). Who pressed is recorded at every press: the user signed in on this connection, or the station when nobody is.
The stack
The entry opens as a scrolling column of cards, in the order the panel arranges them. Every card opens with the same head: its name on the left and, on the right, the one thing qualifying it right now. A card the station gives nothing to show is left out rather than standing empty: Single commands with no datalog and no instant recipe to fire, Channels on a model with no readable channel, Metadata while the staged procedure prompts no field, a screen card whose screen is gone or still empty. A panel that draws no card at all says: "This panel draws no card. Choose its cards on the model's Panels row, under Visualization."
Above the cards, and never arranged away, stands the interlock banner when the model's stop interlock is enabled: nothing while the unit is normal; a critical banner while it is Tripped, with the reason, the source, its value and its quality; a caution banner while it is Awaiting reset, with a Rearm button that needs Run procedures. What the interlock is and how it is configured is on Automation.
Run
The procedure staged for the next start and the commands that steer the run.
| Element | What it shows or does |
|---|---|
| Head, right side | A lamp and a word: Recording while a run records, Preparing while the unit is reserved but not yet recording, Not recording otherwise. |
| Procedure | A picker of "(none)" and every procedure of the model. Choosing one stages it for the next Start; "(none)" stages nothing. Disabled without Run procedures or while the runtime is stopped. A staging the station refuses (an alias set that cannot be pinned, for example) snaps the picker back and says why on the card. |
| Start, Hold, Resume, Stop, Abort | The lifecycle commands, each greyed until the run can take it, with a tooltip saying what it does: "Start the staged procedure on this unit", "Freeze the temporal window; the datalog keeps recording", "Release the hold and carry the window on", "End the run cleanly and freeze it as history", "End the run as aborted; the finalization block still runs". Hold and Resume are drawn only while the staged procedure is a Temporal one, because only a temporal window can be frozen; with nothing staged the whole set is drawn. |
| Notes under the commands | The last command this unit refused, then the station-wide and the unit's own reasons for not accepting run operations, while they hold. |
What Start validates and what each command does to the run are on Runs and comments.
Metadata
One entry per metadata field the staged procedure prompts, under the line "What the next run of “Procedure” is recorded under. A field marked * is prompted by every procedure." A manual field is a text entry, disabled without Run procedures; a sequential field is never an entry but a prediction of the identifier the counter will reserve at Start (or "Reserved at start" while it cannot be predicted), with a tooltip saying a shared counter may move before then. With nothing staged the card reads "Stage a procedure and the fields it prompts appear here." What you type is station-wide staging: another connection sees it at once.
Run state
Three readouts: State (the run's state, or "Preparing" while the unit is reserved, "Idle" otherwise), Cycle ("2 / 10", or "Not cycling"), drawn only while the staged procedure is Temporal, since only a temporal window repeats, and Verdict (the verdict of the evidence so far, "None" when there is none). Nothing here is tinted.
Comments
The comment timeline of the unit's active run, headed by the line the timeline writes about itself (which run, or that there is none). Each comment shows its time, its phase and its text, with Edit (rewrite in place; Enter saves, Escape cancels) and Delete (the first press arms the row with "Delete this comment? This cannot be undone." and the second removes it). The Add a comment… box and its Add button append one to the active run. All of them need Run procedures; a locked timeline stays readable and says the reason on the gesture. The command answers on its own feedback line under the box.
Occurrences
The unit's active and recent occurrence episodes, headed by the list's own line. Each row carries the occurrence's name, its status, how long it has been Active, a Signal loss or Signal unavailable clock where the source dropped out, and its message. An empty list says so. The episodes come from the model's Occurrences.
Channels
The unit's readable channels on one live chart, each series named the way the channel is called on this unit (an alias shows live) and drawn in the colour and on the bands the channel declares in Channels. The chart carries the standard row of buttons a chart on a screen opens with (zoom into an area, reset the zoom, save and copy a PNG, show or hide series, the tooltip and full screen) and a note under the drawing when the retention it asked for could not be granted whole; what every button does is on Charts.
Productivity
Produced quantities, rates and the outcome ledger of the unit, under the line "Production activity in today." or "Production activity in the last N hours." (or days). The head's right side is the period: Today (since local midnight) or Last N h / Last N d, the rolling window the model declares (or the unit overrides) in Productivity. The body is three readouts (Productivity, Yield, Typical elapsed, each saying what it still misses instead of drawing a placeholder: "No reference", "Not classified", "Not measured"), the Output ledger (one row per output: name, quantity with its unit, and the rate per elapsed hour or "No elapsed time"), the Completion outcomes tally (Finalized, OK, NOK, Inconclusive, Not evaluated, Aborted, Failed) and a By Procedure disclosure with the same figures per procedure. A model where no procedure contributes production says: "No Procedure contributes production yet. Enable “Production output” on a Procedure to start these indicators."; a period with nothing recorded says "No production recorded in today." (or in the window).
Single commands
"Fire one isolated command on this unit, outside a procedure." Each row is drawn only where the model declares the library it fires from:
| Row | Controls | What it does | Greyed when |
|---|---|---|---|
| Snapshot | A datalog picker and Capture | "Record one datalog row now as a finished run in Histories": one row of the picked datalog becomes a born-finished run. | No Run procedures, the unit is busy (preparing, running, held or saving), the unit or the station refuses run operations, or a snapshot is already in progress. |
| Evaluate now | A datalog picker, an evaluation picker and Evaluate | "Snapshot one row and judge it against the evaluation now"; the verdict is recorded in Histories. Drawn only where the model has both a datalog and an evaluation. | The same as Snapshot. |
| Apply recipe | An instant recipe picker and Apply | "Write the recipe's setpoints once through the funnel (no run recorded)"; the journal is the record. Only Instant recipes are offered. | No Run procedures, the unit or the station refuses run operations, or an apply is in progress. It stays available while the unit is busy. |
While the unit is busy the card explains: "Snapshot and Evaluate are unavailable while this unit is preparing, running, held or saving. Apply recipe stays available through a run, but not while the interlock is holding the unit: a tripped chain, one waiting to be rearmed and one whose reading is unavailable all refuse it." The outcome of each command lands in the status bar's action feed ("Snapshot recorded. See Histories.", "Evaluated. The verdict is recorded in Histories.", "Recipe applied.", or the refusal). The pickers start on the first item of each library and keep your choice while the entry stays open.
A screen as a card
A panel may also carry one of the model's screens as a card, at the height chosen on the panel (120 to 1200 px, 320 by default), headed by the screen's name. The card runs the model's one screen definition resolved for this unit: every abstract channel answered with the unit's own bound source. It scales to fill the card and never scrolls; the page does. Its commands follow the Process rule above (Run procedures only), and a screen with nothing on it is left out.
A unit's screen on View
A model's screen marked Show on View on its Dashboards row puts one entry per unit in
the same list, named Model · Unit · Screen. It is not a stack of cards: the stage runs it
on the canvas like any dashboard, resolved for its unit, with the status bar preference
and the icon chosen on the model's screen. Its commands need Run procedures only, seeing
it needs Look at models, and it is edited on the model's Dashboards row
(Dashboards of a model), where the same editor opens with the model's
abstract channels leading every address list.
What a unit panel does not do
It is never edited, copied or reordered on View, never filed by the model (only by you, one unit entry at a time), and never carries the Visible to checklist. It records nothing on its own: a snapshot, an evaluation or a run is recorded through the Process services and read back in Histories. And it never draws a card the station has nothing for, so a card missing from the stack is a card with nothing to show, not a card turned off.