Program Branch

Program is the lower of the two Control-Tree branches the Execution page hosts: route /execution, Control-Tree path execution/program, one node per NC source file the session read. It is a read-only view of a run — the file's text, the passes that went over it, the per-line marks the run left behind, and the writeback files the run wrote — assembled from session data rather than from anything typed into it. Its node ids are positional, so an id addresses a node without surviving the branch growing around it.

Program Against Mission

Mission is what a run executes; Program is what the run read. That one difference sets the rest of the branch:

Mission's nodes edit the project. Program's item types declare a panel and a child builder and nothing else — no enable checkbox (the tree hides the tick on every node that is not a Mission command or an enable-bearing Mission section), no control bar, no add, delete, move or duplicate.
Mission's shape is authored. Program's shape is a consequence: a subprogram file appears on it only because a run followed a call into it.
Mission belongs to the project. Program's contents belong to the session — the index behind it is fed piece by piece as the run executes, and it is dropped when the session ends or the project changes.

Before anything runs the branch is not empty. The server seeds it by walking the mission root-first through its nested lists — skipping a disabled entry along with everything beneath it — and taking the NC file of every Program File command and the title of every NC Code command. It seeds one placeholder per distinct string, not one per command: both loops append only where no root already carries that string under the same case-insensitive, slash-normalised comparison the sibling merge uses, and they share one namespace, so a Program File path and an NC Code title that normalise alike collapse into one node. A Program File command whose path is still unset is skipped and seeds nothing. A placeholder carries no invocations, so its panel shows the file's text with no marks and an empty, disabled pass selector.

The transport bar is the one control the branch does carry, and it is not the branch's own: the primary editor pane pins the Execution Tool Bar above the panel of the Execution root and of every node beneath it, so a run can be started, stepped and reset while a program file is on screen.

The Nodes the Branch Mints

Three item types, each keyed by position rather than by identity.

The branch root (execution/program) carries the summary panel and the child builder that fetches everything.

A file node is one source file as reached through one call edge. The server groups executed sentences by the file index stamped on them, resolves each invocation's caller from the call-stack record on the executed piece, and nests the callee's node under the caller's; the same subprogram called from two different files therefore appears once under each. Sibling nodes merge on a case-insensitive, slash-normalised path comparison, so repeated passes over one file under one caller collapse into a single node holding several invocations. Placeholders are appended after the nodes a run produced, and one whose path a run node already holds is skipped rather than doubled — that skip is also what keeps an inline command to one node, because the run stamps the command's title as the path of every piece it plays, so the placeholder and the run node carry the same string. A later pass flags every root whose path matches an enabled NC Code command's title as inline; that flag drives three presentational choices — the label prefix, the panel's inline caption and which missing-text wording it shows — and one behavioural one: the root's child builder matches a node against the writeback conversions only when the node is not inline, so an inline root is never stamped with a conversion, never gains the forward links to a converted file, and cannot be the target a conversion's converted from header jumps back to. The tree label is the path's base name, prefixed (inline) for an inline node and suffixed with a multiplication sign and a count when the node holds more than one invocation.

A conversion node is one NC writeback conversion held by the session, labelled with an arrow and the written file's base name. Conversion nodes are appended after all file nodes.

A file node's id is its parent's id plus its index among that parent's children (execution/program/0, execution/program/0/1); a conversion node's is the branch root's id plus dst- and the conversion's position in the session's list. Both are positional, and the tree those indices count into grows as a run discovers files, so a ?tree= link into this branch names a position and not a file.

The whole branch costs two requests. The root's child builder takes the file tree in one response and the conversion list in another, stashes each file's raw subtree on the node it mints, and the file nodes' builder only maps what is already there — no node fetches for itself. A failed file-tree request yields an empty branch rather than an error; a failed conversion request leaves the file tree standing without cross-links.

Invocations

An invocation is one pass over one file, keyed on the file index the run stamps onto every executed sentence. A fresh index is allocated for each top-level play of a file and for every subprogram call, call repetition and loop or jump re-segmentation, so a file entered or looped over more than once contributes one invocation per pass, and the file panel's pass selector is exactly a pick among them. Each entry reads as a hash-prefixed ordinal and a trigger, and the trigger is derived from the piece that opened the pass:

the call term with its P word — M98 P8, M198 P8 — when the piece carries a Fanuc subprogram-call record. Only that record is read, so a pass opened by a Siemens or Heidenhain call, or by a Fanuc macro call, falls through to the two cases below;
re-entry when this session has already seen a pass over the same path;
top otherwise.

The selector opens on the last invocation in the node's list — the pass that started most recently — and re-defaults whenever a rebuild leaves the current selection absent from the list. It is disabled while the node has none, and it takes typed text as a filter over the entries. Everything below it belongs to the selected pass alone: switching passes drops the mark and link caches and refetches both for every page of text already loaded, not only for the pages on screen. The footer counts the file's lines and, for the selected pass, the number of distinct source lines that executed in it.

What a Run Marks

The line viewer is virtualized. Text arrives in 1000-line pages covering the visible window plus two pages either side; the server caps one request at 2000 lines and keeps a small most-recently-used cache of whole files keyed on path and last-write time, so paging through a long program does not re-read it once per page. A path with no file on disk is answered as non-existent, the miss is cached so scrolling does not re-fire it, and the panel captions the file as missing — or, for an inline node, as inline text that is no longer available, because an NC Code command's text is served from the mission command itself and goes when the command is removed or retitled. A disk file wins over a command title that shadows it.

Marks are fetched the same way and per selected pass. A line the pass executed carries the sentence index it ran and the range of machining steps that sentence produced; a line absent from the answer did not execute in that pass and is greyed — but only once the node holds at least one invocation, so a placeholder's text renders plain rather than uniformly grey. A line whose sentence produced steps carries a step badge, single-valued or a range.

Marks grow as a run advances, so a page cached early would keep later lines looking unexecuted. The panel drops its mark cache and re-fetches the visible window on every throttled CL-strip update broadcast.

Clicking a line points the shared sentence cursor at that source position, which is what fills the Step Info column's Sentence Syntax panel; when the line's sentence produced steps, the click also selects that sentence's first step, moving the charts and the 3D strip with it. A line with no steps — a G54, a comment, a line that never ran — moves the cursor alone. Hovering a line sends the same anchor as the entered step on a 50 ms leading-edge throttle, and leaving the viewer clears it.

The traffic runs the other way too. A step picked on a chart or the 3D strip resolves to a source anchor and lands on the cursor; a file panel whose path matches switches to the pass that step belongs to and scrolls the line into view. The Follow toggle beside the pass selector is the live variant: while it is on, the panel scrolls to whatever line the execution-status hub's cursor reports for this file. It is off by default, it belongs to the mounted panel rather than to stored preferences, and it does not change the selected pass.

Writeback Conversions

The session retains the destination piece streams and source-to-destination maps of its latest CL-to-NC writeback run — NcConversions(API), refilled by ConvertClToNcFiles(API). This branch only displays them; the writeback itself is switched on by the mission's Post-Execution command, in its CL → NC Writeback section. Because the conversions live on the session, they go when it does.

A conversion node shows the written file's lines, each line whose piece has a registered source carrying a back-arrow badge naming that source line. The panel's header names this conversion's source file; the link on that name lands on the file's node when a root file node matched the conversion's source path, and otherwise falls back to the first entry of the branch's file-index map, so a conversion whose source was reached only as a nested or inline node can name one file and open another. Clicking a badge selects the source node, switches it to the invocation the piece came from, and scrolls to the line; clicking anywhere else on a row only highlights it. The viewer has no missing-file caption of its own, so a written file no longer on disk renders as an empty viewer.

The reverse direction is carried by the file panel. A root file node whose path matches a conversion's source path gets forward-arrow badges naming the destination line, with a count when one source line produced several destination lines, and clicking one selects the conversion node and scrolls to the first of them. That matching is done on root nodes only, and never on an inline node, so a subprogram file reached through a call carries no forward badges of its own even though a backward jump can land on it and switch its pass.

The jump itself rides one shared slot, because only one editor panel is mounted at a time: the requesting panel parks the target line and emits a selection, and the twin takes the parked jump when it mounts — or through a watcher, when it was already the selected panel. A target consumed before the first page of text resolves is parked again and re-applied once the line array is sized.

When the Branch Is Rebuilt

Page initialization. Building the Execution root builds the branch, and only when a project is loaded; without one it stays empty.
Any change in the broadcast execution status. The status the hub reports is one of NoProject, Ready, Running, Paused and Finished, and the host re-reads the branch whenever that value changes. It deliberately does not take the structural-change path used elsewhere in the tree, because that path force-expands the node it rebuilds and a run would then keep re-opening a branch the reader had closed. The panels pick up part of the change from the replaced nodes: the path caption, the pass selector, the inline wording and the executed-line count are all derived from the node, but the file text is not — it is fetched once per page on mount and on scroll, with no watcher on the path, and the panel is not remounted because its key is built from the node id, which is positional and therefore unchanged. A rebuild that puts a different file at the same index leaves the previous file's text on screen under the new node's caption and marks.
The refresh button on the root panel. This one does take the structural-change path: it re-reads the file tree from the current session and expands the branch.

A reset is the emptying event: it ends the session and clears the index, so the next read of the branch returns the mission's placeholders and nothing else.

Layout

Program Node
- Intro Caption
- Status Row
  - Run-State Badge — reads run data when any of the branch root's direct file children holds at least one invocation and not run yet otherwise; like the count beside it, it looks one level deep and never at nested subprogram nodes. It is computed from the nodes, not from the file-tree response's own run-data flag.
  - File Count Caption — the branch root's direct file children only; nested subprogram nodes are not counted.
  - Converted File Count Caption — shown only when the session holds conversions.
  - Refresh Button
- Not-Run Hint — shown while the badge reads not run yet.
- Conversions Hint — shown only when the session holds conversions.
Program File Node
- Path Caption — the path as the run stamped it; an inline node appends an inline-NC-code tag.
- Pass Select
- Follow Toggle
- Not-Run Hint — shown while the node has no invocations.
- Missing-Source Caption — the disk-file wording or the inline-text wording.
- Line Viewer
  - Line Number
  - Line Text
  - Step Badge
  - Converted-Line Badge
- Count Footer — line count, plus the selected pass's executed-line count.
Converted File Node
- Path Caption
- Converted-From Line — the source file's name, linked to its node when a root file node matched.
- Line Viewer
  - Line Number
  - Line Text
  - Source-Line Badge
- Count Footer — line count and converted-piece count.

Source Code Path

See HiNC App Anatomy for git repository links.

Web Application

HiNC-2025-webservice (Quasar CLI SPA):

wwwroot-src/src/components/controlTree/programItemTypes.ts — the branch's three item types, the node ids, the labels, the conversion stamping, and the two-request child builder.
wwwroot-src/src/components/controlTree/ProgramRootPanel.vue — the branch root: intro, run-state badge, file and conversion counts, hints and the refresh button.
wwwroot-src/src/components/controlTree/ProgramFilePanel.vue — one source file: the pass selector, the Follow toggle, the paged line viewer, the execution marks, the step and converted-line badges, and the cursor and hover wiring.
wwwroot-src/src/components/controlTree/ProgramConversionFilePanel.vue — one written file: the paged line viewer and the source-line links back into the file panel.
wwwroot-src/src/components/controlTree/useControlTreeHost.ts — declares the branch root under the Execution root, re-reads it on every execution-status change without expanding it, and hides the tick on every node that is not a Mission command or an enable-bearing Mission section.
wwwroot-src/src/components/controlTree/itemTypes.ts — the node shape carrying the program bookkeeping, the merged item-type registry, and the eager subtree builder.
wwwroot-src/src/components/controlTree/ControlTreePanel.vue — the tree pane that renders the branch's nodes and binds the tree's strict tick strategy.
wwwroot-src/src/components/controlTree/PrimarySlavePanel.vue — mounts the selected node's panel, forwards its selection request to the host, and pins the transport bar above every Execution-scope node.
wwwroot-src/src/api/ncProgram.ts — the typed client for the file tree, the paged lines, the line marks, the syntax piece, the sentence-to-step mapping and both directions of conversion links.
wwwroot-src/src/api/clStrip.ts — the step-select and step-enter posts a line click and a line hover make.
wwwroot-src/src/composables/useConversionJump.ts — the single parked-jump slot the two viewers hand a target through.
wwwroot-src/src/composables/useSentenceCursor.ts — the shared source position, written by a line click and by the resolved step selection.
wwwroot-src/src/composables/useClStripHub.ts — the throttled run-advance counter that invalidates the visible marks.
wwwroot-src/src/composables/useExecutionStatusHub.ts — the status the branch rebuild watches and the running cursor the Follow toggle scrolls to.
wwwroot-src/src/components/execution/SyntaxPiecePanel.vue — the Step Info column's Sentence Syntax panel, the other reader of the shared cursor.
wwwroot-src/src/i18n/en/tree.ts — the branch's labels, hints, badges and pluralised counts.
Execution/NcProgramController.cs — the read-only endpoints: the file tree, the paged file lines with their inline-command fallback and whole-file cache, the line marks, the syntax piece, the sentence and step lookups, the conversion list and both directions of conversion links.
Execution/NcProgramRegistryService.cs — the session-scoped index: the event feed, the invocation records with their trigger and caller resolution, the file-tree snapshot with its mission placeholders, the per-line marks, and the clear on reset or project change.

HiAPI Engine

HiNc/MachiningProcs/LocalProjectService.cs — the app-lifetime bridge that forwards each executed piece and each built machining step, and the reset that ends the session.
HiMech/MachiningProcs/MachiningSession.cs — the retained conversions and the CL-to-NC writeback run that refills them.
HiMech/NcParsers/NcWriteback/NcConversion.cs — one conversion: the destination piece stream, its written path and the source-to-destination map the cross-links walk.
HiMech/NcParsers/Syntaxs/SyntaxPiece.cs — the executed unit the index is keyed on, and the source line stamped on its sentence.
HiNc/SessionCommands/NcFileCommand.cs — the Program File command whose path seeds a placeholder.
HiNc/SessionCommands/NcCodeCommand.cs — the NC Code command whose title is the pseudo-path of an inline node and whose text is that node's only source.

Table of Contents