View and dashboards

The View page: the Visualization column of folders, screens and unit panels, the open screen's bar with Expand and Full screen, the grid a screen composes on, and who may press what on it.

View as Markdown

View is the first entry of the navigation rail and the page the station opens on. It lists every screen this station shows and runs the one you pick: the dashboards you build on a grid over the live Logic address space, and the panels the Process units put here. Every role reaches it, because "View dashboards" is the one permission every role holds (see Permissions); what a role may then do on the page is read off its other permissions, verb by verb.

The page answers four routes. /view is the canonical address and / opens the same page; /home is kept so an old shortcut still lands here. /d/{id} opens one screen directly, which is how a bookmark on a tablet or a link from another page reaches it; an id this connection's role may not see, or one that no longer exists, falls back silently to the screen the page would have opened anyway. /d/{id}?edit=true opens the screen straight in the editor, the landing after a copy or a repair link from Validation, and is ignored when the screen cannot be edited.

The Visualization column

The column on the left is headed Visualization and holds one row per thing the station can show:

  • Folders, two levels deep at most, each with a chevron that folds the group and a name that opens the folder itself on the stage. A folder row ends with how many screens it holds, subfolders included.
  • Screens, your own dashboards, filed into folders or standing at the top level, each with the icon picked in its settings and its description as the row's tooltip.
  • Unit panels, the entries the Process models put here, one per unit, named Model · Unit · Surface. The ones nobody filed stand together under a Unit panels heading after the tree; a filed one joins its folder beside your screens.

A screen holding a component whose point currently fails to read wears a quiet attention dot after its name, and so does every folder above it, so a failure is findable with the groups rolled up. The dot says nothing else: no count, no motion.

The footer carries New… (drawn only for a role that may edit dashboards; it opens a menu with New dashboard and New folder, both at the top level), then, while the editor is open, Move dashboard up and Move dashboard down for the open screen, and in the trailing corner Expand all and Collapse all over the folders. Right-clicking a screen or a folder row opens the menu that files, renames and removes; all of that is Screens and folders.

The column collapses to a narrow rail with the chevron in its header. A press on that rail opens the list as an overlay over the stage, so the canvas keeps every pixel it gained; choosing a row closes it again, and the pin puts the fixed column back. The splitter between the column and the stage drags between 260 and 600 px. Which folders you opened, the width and the collapsed state are yours for the session: they are held per connection, so a browser folding a group never folds it on the station's own window, and nothing of it is saved.

The open screen's bar

The bar over the stage names what is open, with the screen's icon and name, and carries the verbs for it. While the editor is open the name wears an Editing badge.

Command What it does Greyed when (situation) Not drawn when (role)
Copy Makes an editable copy of the open screen beside it, in the same folder, named after the original with "(2)", "(3)" and so on until a name is free, and opens the copy in the editor. Nothing is open ("Open a screen to copy it."), engineering is locked, the runtime is stopped. The role may not edit dashboards, or the open entry is a unit panel or a unit screen (nothing to copy: it is arranged on its model).
Edit / Done editing Enters the editor on the open screen, or leaves it and goes back to viewing. Leaving is never refused. Nothing is open ("Open a screen to edit it."), engineering is locked ("Engineering is locked while a Unit is running"), the runtime is stopped ("Runtime stopped"). The role may not edit dashboards, or the open entry is a unit panel or a unit screen.
Edit in Process Opens the entry's own definition in the Process workspace: the panel row or the screen row of its model. Never greyed; it is drawn only when it can run. The open entry is a screen of your own, or the role may not manage models.
Expand Hides the rail, the title bar and the bar itself and gives the screen the whole window; the window stays as it is. Nothing is open. Never, but withheld while editing.
Full screen The real thing: the station's window covers the monitor, or a browser goes to document fullscreen. F11 does the same. Nothing is open. Never, but withheld while editing.

Expand and Full screen are for operating a finished screen, so the bar withholds both while the editor is open and F11 does nothing then. Everything about the two modes, the flyout and the status bar is on Fullscreen operator mode.

When a folder is open instead of a screen, the bar changes subject: it names the folder and carries Rename folder (opens the name field on the folder's own row) and, in the danger ink on the right, Remove folder (the same confirmation as the row's menu). Both are drawn only for a role that may edit dashboards and greyed while engineering is locked.

The stage

What the stage draws follows the row you picked:

  • A screen runs on the canvas: its grid scales to fill the stage, with no scroll, and its components read the address space at the page's own pace (every 150 ms on the station's window, every 400 ms on a remote browser).
  • A folder opens as an overview: one line saying what is filed there, a row per subfolder with its count, and a card per screen with its icon, name and description. Pressing a card opens the screen.
  • A unit panel is not a layout but a stack of cards, so the stage becomes a scrolling column of them: see Unit panels on View. A unit screen (a model's screen shown on View) runs on the canvas like any screen, resolved for its unit.

With nothing to show the stage says so: a station without any dashboard reads "No dashboards yet. Create one to assemble live readouts, charts and controls for your bench, then open it full screen to operate." with a New dashboard button for a role that may edit; a role every dashboard is hidden from reads "No dashboards are visible to your role."; a list holding folders but no screen, or a folder open with no screen picked, says which of the two it is.

The grid

Every dashboard owns a grid of Columns × Rows cells (24 × 12 until you change it, each between 1 and 96) that fills the stage and scales with the window. A component occupies a rectangle of cells (its X, Y, width and height); components may overlap freely, and each carries a layer number (Z): the higher layer draws on top and takes the click. That is how a Frame becomes a true background: send it to back and draw the group over it. Placement, sizing and the layer order are the editor's; the grid's own size is a dashboard setting.

Commands, permissions and the lock mark

Every command component writes through the station's single Logic write funnel, journaled, and answers to one permission model. That is every control you can press on a screen, the Procedure cards a unit panel carries, and the acknowledge on an Alarm banner with them:

  • Pressing a control on a dashboard of your own needs the role's Operate dashboards permission, granted per role on the Users page.
  • A press whose target is a Process mutation (a unit run command, a staging field, a run comment, the Procedure picker, the Interlock's Rearm) additionally needs Run procedures. What a press needs is read off its resolved target, never off the component kind: a Button writing a value or opening another dashboard stays on the dashboard permission.
  • On a unit panel or a unit screen, the Process permission alone governs: Run procedures, nothing about dashboards.
  • While the runtime is stopped every command is refused with "Runtime stopped", whatever the role.

A command the signed-in role may not press stays on screen and wears the quiet lock mark: a small padlock in the component's corner, with the whole reason ("Dashboard operation permission required." or "Run procedures permission required.") in the component's tooltip. It is deliberately quiet, because a viewing role sees it on every control at once and a plant running normally must not read as a screen of warnings. Authorization is rechecked at the moment of every press, so a sign-out or a role change with the screen open cannot dispatch a stale click.

Each command component answers on its own feedback line under the control ("Written", "OK · 12 ms", or the refusal), which expires after five seconds. That line is the one surface left when a fullscreen screen hides the status bar, which is why commands answer there and not in the status bar's action feed.

Locks

While a unit runs, the page shows the Engineering locked banner: "A Unit operation is active. Configuration stays read-only until every Unit finishes; run controls and other operator actions remain available." Creating, copying, editing, filing, renaming and reordering are greyed with that reason, an open editor closes, and the screens keep running and taking permitted commands. A stopped runtime closes the same verbs and the commands too; the shell's own paused notice says where the restart happens.

What the page does not do

It never edits a unit panel or a unit screen (Edit in Process leads to where they are arranged), never reorders them, and never lets a role see a dashboard hidden from it, by the list or by address. It keeps no layout state of yours beyond the session: the folded folders, the column width, the pin and the selected screen all reset with the connection. Deleting a screen is done inside the editor's Dashboard settings, not from the column.

In this area

Page What it covers
Screens and folders Creating, copying, filing, renaming, reordering and removing what the column lists, the startup screen and who sees which screen.
The dashboard editor The workbench: the palette, the canvas, selection, the property sections every component shares, and the connections drawn between symbol terminals.
Dashboard settings What one screen declares about itself: name, description, icon, grid, startup, the status bar in full screen, visible roles, deletion.
Fullscreen operator mode Expand and Full screen, F11 and Esc, the flyout and the status bar preference.
Unit panels on View The stack of cards a Process unit is operated through, as it appears here.
Charts The toolbar every chart carries, its scale, statistics and reference panels, and the detached chart window.
Dashboard components The catalog of component kinds, the addresses they bind, how a reading is drawn, and a reference page per kind.