Table of Contents

The Program Branch

What the run actually read, line by line, as opposed to what the mission asked for.

The Execution page's Control Tree carries two roots: Mission above, Program below, at Control-Tree path execution/program. Program is read-only — its nodes are what the session played or produced: the files the mission points at, the files the run reached from them, the inline text of the NC Code commands, one node per distinct title, and the writeback files converted from a played file — and the transport sits in the run header at the top of the Control Tree pane, with the run-state badge at its right end, so a run can be started, stepped and reset without leaving the branch.

Before anything runs

The branch is not empty before a run. The service seeds it from the mission: first one node per distinct file an enabled Program File command names — NC, CL or CSV alike, since the seed reads the command's path and not its kind — in the order the mission lists them and reaching into nested List commands, then one node per distinct title among the enabled NC Code commands — so an NC Code command listed above a Program File still seeds below every file node. Those nodes are placeholders — a file the run has not opened yet — and the branch panel says so, badging itself not run yet beside the file count.

Three things decide what is seeded:

  • A disabled command seeds nothing. The mission's greyed Program File entry names a file that never reaches the branch, and nothing beneath a disabled List reaches it either.
  • Two commands naming one file seed one node. Paths are compared with case and slash direction ignored, so a file played twice appears once. In the screenshot below the first circle.ptp command sits inside the collapsed List [Roughing] and the second is the top-level Program File row, so the branch shows one plain circle.ptp; the ×2 it takes once both commands have played is in the next section.
  • An NC Code command is seeded under its own title, not under a file name, because it has no file — its text lives in the mission. The branch marks it (inline), and two NC Code commands with the same title share one node.

The Execution page before a run: the run header at the top of the Control Tree pane shows the six transport buttons and a green ready badge at its right end; under it the Mission root row, with a + at its right edge, lists nine command rows, each with a checkbox and a drag handle, two of them greyed out and unticked, and the two List rows carry their own +; the Program root below is selected and holds five nodes — circle.ptp, drill_slot.ptp, side.ptp, slide.ptp and (inline) Inline finishing pass; the Program panel in the editor row under the tree is badged not run yet beside 5 files with a round refresh button at the row's right end, above the hint to run the mission; the 3D canvas shows an uncut block, and the four Session Messages tabs carry no badge

The Program branch at /execution?tree=execution/program, on a project that has not been played. The disabled Program File entry in Mission has no node under Program; the enabled NC Code command has one, under its title.

After a run

Playing the mission fills the same nodes in and adds any file the run reached that the mission did not name — a subprogram call nests its callee under the caller. The panel's badge changes from not run yet to run data, and a file the run made more than one pass over takes a × and a count in its tree label.

The same page after the run has finished: the badge at the right end of the run header reads finished, the Mission rows are unchanged, the first Program node reads circle.ptp ×2, the Program panel under the tree is badged run data beside 5 files with the refresh button at the row's right end, the 3D canvas shows the cut block with a gold cutter and green tool paths above it, and the Session Messages tabs carry counts — Shell 11 and NC Diagnostics 7, with Step Diagnostics and NC Manipulation still unbadged — over a list of System messages

The same deep link once the run has finished. circle.ptp ×2 is one node holding two passes, because two Program File commands named the same file.

Important

The branch is rebuilt when the run changes state — starting, pausing, finishing, being reset — and not while it is playing. During a long run the nodes on screen are the ones the last transition left there, so a file the run has since opened may not be listed yet. The round refresh button at the far right end of the Program panel's badge row — across the row from the run data badge and the file count, its tooltip Re-read the file tree from the current session — rebuilds the branch on the spot without touching the transport; pausing rebuilds it too, since a pause is a state change.

Reading one file

Selecting a node opens the file as the run saw it: the path it was read from, a selector for the passes made over it, and the text with what each line produced beside it.

The Program branch with circle.ptp ×2 selected and the canvas and right-hand columns switched off, so the Control Tree pane spans the window: the menu bar carries a red disconnected chip beside the four layout toggles, the run header's green finished badge sits at the far right, the Mission root row is collapsed with a + at its right edge, the Program root beneath it is open and holds five nodes — circle.ptp ×2 highlighted in blue, drill_slot.ptp, side.ptp, slide.ptp and (inline) Inline finishing pass — and the editor row's header reads Program / circle.ptp ×2; inside it the path caption NC/circle.ptp, a pass selector reading Pass (2) and #2 · re-entry beside a Follow toggle, then twenty-one numbered lines of NC with a step range printed to the right of ten of them, a footer reading 21 lines · 21 executed lines, and the window footer reading Ready

One file node at /execution?tree=execution/program/0, with the canvas column switched off so the line viewer has the width — which is why the menu-bar chip reads disconnected: the badge folds the page's rendering connection in with its service connections, and with the canvas column off the page holds no rendering connection (see The Application Window). The pass selector names the pass and why it was entered.

  • The pass selector carries one entry per pass, labelled with how that pass was entered. A pass that an M98/M198 subprogram call started carries the call word and its P number — M98 P8 — on every pass, so a subprogram the caller repeats with an L count or calls a second time reads ×N with each pass labelled by the call, never as a re-entry. A pass with no call behind it reads top on the first arrival at that path and re-entry on every later pass over it — whether a second Program File command named the file again or a WHILE or GOTO inside a single play of it started a new pass. So a file the mission names once can still read ×N, with every pass after the first labelled re-entry.
  • The step range beside a line is what that line produced. A line with no range beside it ran and produced no motion: G and M words that set state, and the tape marks, all execute without cutting anything.
  • A line missing from the marks altogether did not run in that pass. That is the difference the branch exists to show, and it is per pass — the same line can be greyed in one pass and marked in the next.
  • Follow keeps the viewer on the line the run is executing; with it off the view stays where it was put.

What the branch does not hold

  • The writeback files are not inside the file nodes. With Post-Execution › CL → NC Writeback enabled, the mission re-serializes every file the session played — NC plays as well as CL plays — and each converted file makes its own node, labelled → and the output file's name, at the top level of the branch, after the file nodes rather than under them; the Program panel counts them beside the file count, and clicking a line on either side jumps to its twin on the other. With that section disabled the branch shows only source files.
  • Node addresses are positions, not files. A node is execution/program followed by an index at each level of nesting — execution/program/0 for a top-level file, execution/program/0/0 for a subprogram nested under it — and a writeback node takes dst- and its own index in place of a file index, execution/program/dst-0. So a deep link into the branch survives only as long as the branch has the same shape. Link to the branch, not into it.
  • A skipped line is not only recorded here. A line suppressed by block skip is also announced in the NC Diagnostics list while the run is playing — see When Something Goes Wrong.

See Also