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 branches: Mission above, Program below, at Control-Tree path execution/program. Program is read-only — every node on it is either a file the mission points at or a pass a run made over one — and the transport bar stays pinned above its panels, 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: one node per distinct NC file a Program File command names, and one per NC Code command, taken in the order the mission lists them and reaching into nested groups. 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, and each of them is visible in the screenshot below:

A disabled command seeds nothing. The mission's greyed Program File entry names an NC file that never reaches the branch, and nothing beneath a disabled group 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.
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).

The Execution page before a run: the Control Tree shows the Mission branch with nine commands — two of them greyed out and unticked — over the Program branch, whose five nodes are circle.ptp, drill_slot.ptp, side.ptp, slide.ptp and (inline) Inline finishing pass. The branch panel below the transport bar is badged not run yet beside 5 files, and the four Session Messages tabs are empty

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 Execution root badge reads finished, the first Program node now reads circle.ptp ×2, the branch panel is badged run data beside 5 files, and the Session Messages tabs carry counts — Shell 11 and NC Diagnostics 7, with Step Diagnostics and NC Manipulation still unbadged

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, 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. Pausing brings it up to date.

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: the breadcrumb reads Execution / Program / circle.ptp ×2, 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 thirteen of them, and a footer reading 21 lines · 21 executed lines

One file node at /execution?tree=execution/program/0, with the canvas column switched off so the line viewer has the width. 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 — the first arrival at the top of the file, a re-entry when the mission came back to it, or the call that reached it from another file.
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. Converting a played program back to NC makes its own node at the top of the branch, beside the file nodes rather than under them, and clicking a line on either side jumps to its twin on the other. That conversion is the CL-to-NC writeback, so a mission that plays brand NC produces none, and the branch shows only source files.
Node addresses are positions, not files. A node is execution/program followed by its index, 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.