Program Data Plane
Program Data is the second of the Controller branch's two plane stems: the coordinate, offset and
variable tables that belong to the workpiece rather than to the control, edited one leaf at a time.
It lives on the General Setup page at /general-setup under the Control-Tree id
equipment/controller/program-data, and each of its leaves takes that id plus one segment —
work-coordinates, tool-offsets, siemens-tool-offsets, tool-names, datum-presets,
datum-shifts, frames, retained-variables, r-parameters. The stem is not gated: it is part of
the branch builder's return value rather than a conditional entry, so it appears wherever a runner
resolves and always carries the two leaves no flag guards.
Important
Anatomy makes no claim that any id named here is stable across versions. The migration hop that
keeps an older ?tree= value resolving is described in
Tree Ids and Routes.
Selecting the stem shows the shared group editor: its own introduction over a clickable list of its children. The introduction reads "Data that travels with the workpiece / project — work-coordinate offsets (G54…), tool offsets and the brand-specific per-case tables. Kept on the project even when the runner file is swapped."
Every leaf below follows the branch's shared editing rules — one read on mount, per-control commit, capture-assign-await-restore on failure, a dense markup table with no sort and no pagination, and the two empty layers. Those rules, and the places this plane departs from them, are Editing Contract.
Where the Data Actually Lives
The stem's introduction names a storage location, and here — unlike the machine stem's own introduction — it holds for every leaf. What it does not say is that the location is not a file.
One list, inlined in the project
NcRunnerSuit carries the runner beside the project's own PerCaseNcDependencyList, and serializes the two side by side. The runner half can be written to a side file; the per-case half never is — the suit writes it as a nested element with no file reference of its own, so it lands inside whatever file the owning project writes. Every table this plane edits is an entry of that one list.
No panel and no endpoint reads or writes a table by reaching into that list by name. The one place that addresses the list directly is the sweep that follows a runner swap, and it removes whole entries rather than editing any value in one. A brand preset's pipeline list carries an INcDependencyProxy in place of each of these tables, and every read and write resolves through GetEffectiveNcDependencyList(API), which substitutes the project's table for the placeholder. That is also what the snapshot flags probe, so the tree grows a leaf for the concrete table and never for the proxy — Brand Matrix.
The proxies on this plane carry nothing
ToolOffsetTableProxy and its siblings — the Siemens $TC_DP,
frame and R-parameter proxies, the Heidenhain datum proxy and the Fanuc-family retained common
variable proxy — are get-or-create placeholders with no seed. Each serializes an empty element, and
on wiring installs a bare new instance into the per-case list when the project holds none of that
type; an existing table is left untouched.
Two consequences follow. A controller file written from the branch root's Object-Management menu carries none of the values edited on this plane: the seedless proxies write an empty element, and the one proxy on this plane that does carry a seed — the brand parameter-table proxy standing behind the work coordinates on the Fanuc family and Syntec — serializes the fixed seed it was constructed with rather than the table the panels have been editing. And a table this plane loses is not recoverable from a preset: a fresh instance is what the proxy makes.
Which store a work coordinate lands in
Work Coordinates is the one leaf whose backing object changes with the brand. The panel reads and writes the first IIsoCoordinateConfig in the effective list, and the caption above its table names which one answered.
| Brand | Backing object | Ids the table lists | Caption above the table |
|---|---|---|---|
| Fanuc, Mazak | FanucParameterTable | G54–G59 and G54.1P1–G54.1P48 | "Stored in the Fanuc parameter table (#5221+ / #7001+)." |
| Syntec | SyntecParameterTable | G54–G59 and G54.1P1–G54.1P48 | "Stored in the Syntec parameter table (Pr5221+ / Pr7001+)." |
| Siemens | SiemensFrameTable | G54–G57 and G505–G599 | "Stored as Siemens settable frames ($P_UIFR; G500 cancels and is always zero)." |
| Heidenhain | HeidenhainDatumTable | G54–G59 | "G54–G59 map onto Heidenhain datum preset rows 1–6." |
An id appears only where the store actually holds it. A Fanuc-family or Syntec table yields an id whose parameter address is present, and every one of those default tables seeds all of them at zero; the Siemens frame table seeds G54–G57 and the extended series, and has no G58 or G59 row at all; the Heidenhain table yields one id per preset row 1–6 that exists. G500 is never a row — the frame table refuses to store it and does not seed it.
That caption is the panel's only statement of where a value went, and it is selected from the snapshot's work-coordinate kind rather than from the brand marker.
The one setting that is not in the list
The Tool Offsets leaf's Set ideal offset dependent on tool house toggle is not a dependency. It writes IsIdealOffsetDependentOnToolHouse, an element the project serializes beside the runner suit. It therefore stays with the project like everything else on this plane, but by a different route — and, being outside the per-case list, it is untouched by the sweep that follows a runner swap.
How This Differs From the Machine Plane
The machine plane's ownership is split. Several of its leaves are plain instances the runner owns outright — the tool-change position, the block-skip layers, the subprogram folders, and on Siemens and Heidenhain the peck clearance — and an install replaces them with the incoming runner's; the rest are rows of the brand parameter table and are stored on the project. One leaf holds both halves: Controller Parameters, where the macro loop guards are runner-owned fields sitting beside table rows. Which side of that line a machine-plane field falls on is Machine and Controller Plane.
This plane has no such split. Nothing on it is a plain runner-owned instance: every leaf resolves a per-case table through a proxy, so every value it edits is stored on the project. That is what makes the two introductions' phrasing load-bearing rather than decorative — and it is why installing a controller file of the brand already in force changes nothing here at all: each of that brand's proxies takes the table the project already holds rather than installing a fresh one over it. The same install does return the machine plane's runner-owned settings to the incoming file's values.
The one crossing runs the other way. On Fanuc, Mazak and Syntec the work coordinates are rows of the same brand parameter table whose other rows the machine plane's per-axis leaves and native parameter form edit. A single object straddles both stems there, which is exactly why that table is per-case at all: the two planes could not otherwise be separated.
The Plane's Leaves
Ordered as the branch builder pushes them: the two ungated leaves first, then each gated leaf or gated pair behind the snapshot flag that grows it. Which brands satisfy each flag is Brand Matrix; the column that page does not carry is the last one here.
| Node segment | Label the tree shows | Gate | Backing table |
|---|---|---|---|
work-coordinates |
Work Coordinates (G54…) | ungated | the brand's ISO coordinate provider, per the table above |
tool-offsets |
Tool Offsets, read as Tool Offsets (ISO G43 H) where the Siemens table resolves | ungated; label switched by hasSiemensToolOffsets |
ToolOffsetTable |
siemens-tool-offsets |
Tool Offsets ($TC_DP) | hasSiemensToolOffsets |
SiemensToolOffsetTable, its cutting-edge map |
tool-names |
Tool Names | hasSiemensToolOffsets |
SiemensToolOffsetTable, its name map |
datum-presets |
Datum Presets (Q339) | hasDatums |
HeidenhainDatumTable, its preset rows |
datum-shifts |
Datum Shifts (D) | hasDatums |
HeidenhainDatumTable, its shift rows |
frames |
Frames (Siemens) | hasFrames |
SiemensFrameTable |
retained-variables |
Retained Common Variables | hasRetainedVariables |
RetainedCommonVariableTable |
r-parameters |
R Parameters | hasRParameters |
SiemensRParameterTable |
Every label above is a translated role string rather than a type name, so the tree renders the translation and a locale change rewrites the rows without touching an id.
Two leaves stand on every brand: Work Coordinates (G54…) and Tool Offsets. They are the builder's unconditional entries, and every brand preset satisfies them — each carries an ISO coordinate provider of its own, and all five proxy the generic tool-offset table. The remaining leaves are pushed inside a flag test, and each of those flags is satisfied by one brand family only.
Fewer tables than leaves
Two flags grow two leaves each, because two leaves edit two halves of one object. Tool Offsets ($TC_DP) and Tool Names are the cutting-edge map and the name map of a single Siemens tool-offset table, which is why there is no separate tool-name flag and why the two nodes appear and disappear together. Datum Presets (Q339) and Datum Shifts (D) are the preset rows and the shift rows of a single Heidenhain datum table, served by one component that reads its role from the node id's last segment.
The work coordinates then fold two more leaves together, on the two brands where the ISO provider is a table this plane already lists. On Siemens, Work Coordinates and Frames (Siemens) are two views of one frame dictionary — the same ids, the same X/Y/Z translations, edited through two panels. On Heidenhain, the G54–G59 rows of Work Coordinates are preset rows 1–6 of Datum Presets (Q339), so editing one changes what the other shows. Datum Shifts has no such alias, and the Siemens frame table's per-axis translation components beyond X/Y/Z are reachable from neither panel.
The two tool-offset ledgers disagree on the sign of wear
Where both are present the difference matters more than the labels suggest. On the generic table an
effective value is the ideal minus the wear; on the Siemens $TC_DP table it is the geometry plus
the wear. That is why the Siemens panel spells the addition out in a footnote below its table, and
says in its own description that a shortened tool is entered as negative wear, while the generic
panel states no sign rule at all. The relabel of the ungated leaf to Tool Offsets (ISO G43 H)
exists so that the two are not read as one ledger.
What a Brand Change Does Here
A brand switch replaces the whole runner with the target brand's preset and then removes every per-case table the new runner references through no proxy. This plane is where that sweep lands: the machine plane's project-owned parameter table is one entry, and every other entry the sweep can reach is a table edited here. The staged select, its confirmation and the rest of the control are Controller Brand; what follows is the outcome for this plane alone.
- Tool Offsets survives every switch. All five presets proxy the generic tool-offset table, so the sweep's keep-set always contains it. Its rows, its tool numbering and the tool-house dependence toggle beside it come through a brand change unchanged; only the leaf's label can change.
- Every other table on the plane is brand-bound and is removed the moment the target brand
proxies none of it — the Siemens
$TC_DPtable with its tool-name map, the Siemens frame table, the Siemens R-parameter table, the Heidenhain datum table, and the Fanuc-family or Syntec parameter table that holds the work coordinates. Switching back does not restore what was removed; the proxy makes a fresh instance instead, empty for the tool-offset, tool-name, R-parameter and retained-variable tables, and zero-filled for the frame and datum tables that seed a row set in their constructor. - The Fanuc and Mazak presets proxy the same parameter table, so a switch between those two brands sweeps nothing here: the work coordinates and every other row of that table stay where they are.
- Retained Common Variables spans a family rather than a brand. Fanuc, Syntec and Mazak all proxy it, so it survives any switch among those three and is removed on a switch to Siemens or Heidenhain.
- Work coordinates are the one set of values a switch can carry across. The brand panel's Carry work-coordinate XYZ (G54…) into the new brand's table checkbox is on by default; the switch reads every id the outgoing providers exposed and, after the swap, writes each back only to a provider on the incoming runner that lists it — never to a provider that would merely accept it. The Fanuc-family and Syntec presets expose the same set — G54–G59 and all forty-eight G54.1 P offsets on the brand table, every address seeded, plus the extended G59.1–G59.9 on the brand-neutral table behind it — so a switch between Syntec and either of Fanuc and Mazak carries every one of them. A switch into Siemens carries only G54–G57, the frame table listing no G58, no G59, no G59.x and no G54.1 P id at all; a switch into Heidenhain carries G54–G59 and drops the forty-eight G54.1 P offsets and the nine G59.x. No other table's values are carried, and the carry is skipped for a table the swap re-bound rather than replaced — which is the Fanuc-to-Mazak case.
The banner shown before the apply says as much in one line: "Switching brand replaces the whole runner with the {brand} preset. Machine settings reset to that preset's defaults and the old brand's program-data tables are removed — switching back does not restore them."
An Object-Management Load, Paste or XML apply runs the same install and the same sweep, so a controller file of another brand takes this plane through the identical outcome without the carry option. Both writes are refused while an NC program is playing.
Layout
- General Setup Control Tree — the left dock of
/general-setup- Controller Node Row
- Machine / Controller Group Row — the plane beside this one
- Program Data Group Row —
equipment/controller/program-data- Work Coordinates (G54…) Node Row
- Tool Offsets Node Row — reads Tool Offsets (ISO G43 H) where the Siemens
$TC_DPtable resolves - Tool Offsets ($TC_DP) Node Row — grown while the snapshot reports a Siemens tool-offset table
- Tool Names Node Row — grown on the same flag
- Datum Presets (Q339) Node Row — grown while it reports a Heidenhain datum table
- Datum Shifts (D) Node Row — grown on the same flag
- Frames (Siemens) Node Row — grown while it reports a Siemens frame table
- Retained Common Variables Node Row — grown while it reports a retained common variable table
- R Parameters Node Row — grown while it reports a Siemens R-parameter table
- Controller Node Row
- Editor Row — the panel of whichever node is selected
- Program Data Group Panel
- Intro Caption — the stem's introduction line
- Child List — one bordered, separated row per leaf above, each showing the leaf's label in the theme's primary colour with a right chevron; a click selects that leaf
- Program Data Group Panel
The stem's own editor holds no field, so nothing on this plane is edited from the group row itself.
Source Code Path
See HiNC App Anatomy for git repository links.
Web Application
HiNC-2025-webservice (Quasar CLI SPA):
wwwroot-src/src/components/controlTree/softNcItemTypes.ts— the branch builder: the program-data stem's id, label key and intro key, the two leaves it pushes unconditionally, the snapshot flag each further leaf is pushed behind in the order the table above lists them, and the tool-offsets relabel.wwwroot-src/src/components/controlTree/GroupInfoPanel.vue— the stem's editor: the intro caption and the clickable child list that selects a leaf.wwwroot-src/src/components/controlTree/useControlTreeHost.ts— builds theequipment/controllerroot this stem hangs from, inside the equipment group.wwwroot-src/src/api/softNcRunner.ts— the snapshot shape the builder reads its flags from, and the typed wrappers over each leaf's reader and writers.wwwroot-src/src/composables/useSoftNcRunner.ts— the shared snapshot the leaf panels gate on, the brand switch with its carry option, and the Object-Management install that regrows the branch.wwwroot-src/src/components/controlTree/SoftNcWorkCoordinatesPanel.vue— the one panel that reads the snapshot's work-coordinate kind, the caption it selects from it, and the extended-row filter.wwwroot-src/src/components/controlTree/SoftNcToolOffsetsPanel.vue— the generic ledger: the tool-house dependence toggle, the refresh it enables, and the Siemens caveat gated on the brand string rather than on the table flag.wwwroot-src/src/components/controlTree/SoftNcSiemensToolOffsetsPanel.vueandwwwroot-src/src/components/controlTree/SoftNcToolNamesPanel.vue— the two leaves over one Siemens table: the cutting-edge rows and the name map.wwwroot-src/src/components/controlTree/SoftNcDatumTablePanel.vue— the one component behind both Heidenhain leaves, choosing its role from the node id's last segment.wwwroot-src/src/components/controlTree/SoftNcFramesPanel.vue— the settable-frame table and its own always-visible set, narrower than the work-coordinate panel's.wwwroot-src/src/components/controlTree/SoftNcRetainedVariablesPanel.vueandwwwroot-src/src/components/controlTree/SoftNcRParametersPanel.vue— the two sparse variable tables, and the vacant entry a cleared cell writes.wwwroot-src/src/components/controlTree/SoftNcEmptyState.vue— the shared no-runner line every leaf on this plane falls back to.wwwroot-src/src/api/equipmentSetup.ts— the canvas marker id a work-coordinate row click writes, outside this branch's own REST surface.wwwroot-src/src/i18n/en/softNc.ts— the stem's introduction line, every leaf label in the table above, the work-coordinate storage captions and the brand-switch warning.wwwroot-src/src/i18n/en/common.ts— the shared column and action labels these tables reuse.Mech/SoftNcRunnerController.cs— the plane's REST surface: the presence flags, the per-table readers and writers, the brand switch with its work-coordinate carry, and the sweep of per-case tables the new runner references through no proxy.Mech/EquipmentSetupDisplayController.cs— the marked-coordinate id a work-coordinate row click stores, on the user configuration rather than on the project.
HiAPI Engine
HiMech/NcParsers/NcRunnerSuit.cs— the suit: the per-case list this plane's tables live in, the serialization that inlines it with no file reference, and the proxy wiring that materialises a table into a project holding none of that type.HiMech/NcParsers/SoftNcRunner.cs— the five brand presets as literal dependency lists, showing which proxies each brand carries, and the proxy resolution every read on this plane goes through.HiMech/NcParsers/Dependencys/INcDependencyProxy.cs— the maker-and-taker contract, and why a proxy's resolved data is never written into the runner.HiMech/NcParsers/Dependencys/Generic/ToolOffsetTableProxy.cs— the seedless get-or-create shape the Siemens, Heidenhain and Fanuc-family per-case proxies on this plane all repeat.HiMech/NcParsers/Dependencys/Fanuc/FanucParameterTableProxy.cs— the contrasting seeded proxy, and its own account of why the Fanuc-family table mixes machine configuration with the per-case work-coordinate offsets.HiMech/NcParsers/Dependencys/IIsoCoordinateConfig.csandHiMech/NcParsers/Dependencys/IsoCoordinateAddressMap.cs— the interface the work-coordinate panel edits through, and the address arithmetic that decides which ids a Fanuc-family or Syntec table lists.HiMech/NcParsers/Dependencys/Generic/ToolOffsetTable.cs— the generic ledger every preset proxies, and the subtraction that makes an effective value ideal minus wear.HiMech/NcParsers/Dependencys/Siemens/SiemensToolOffsetTable.cs— the cutting-edge map and the name map behind two leaves, and the addition that makes an effective value geometry plus wear.HiMech/NcParsers/Dependencys/Siemens/SiemensFrameTable.cs— the settable frames: the ids the constructor seeds, the ISO coordinate implementation the work-coordinate leaf shares, and the per-axis translation components neither panel exposes.HiMech/NcParsers/Dependencys/Siemens/SiemensRParameterTable.csandHiMech/NcParsers/Dependencys/Fanuc/RetainedCommonVariableTable.cs— the two persistent variable tables, their accepted id ranges, and the vacant entry a valueless element preserves across a save.HiMech/NcParsers/Dependencys/Heidenhain/HeidenhainDatumTable.cs— the preset and shift rows behind two leaves, and the mapping that aliases G54–G59 onto preset rows 1–6.HiMech/MachiningProcs/MachiningActRunnerConfig.cs— the tool-house dependence flag, the one setting on this plane stored outside the per-case list.HiNc/MachiningProcs/LocalProjectService.cs— the facade setter every install and brand switch assigns through, and the proxy re-binding that materialises the incoming brand's per-case tables.HiNc/MachiningProcs/MachiningProject.cs— where the suit and the runner configuration hang off the project, and the load path for a project file carrying the per-case list.
Pages
Ordered by the first node each page owns, as the plane lists them.
- Work Coordinates — The one uniform face over four brand storage models, its P0 and M0 row actions, and the row click that marks a coordinate on the canvas
- Tool Offsets — The generic ISO ledger: ideal against wear, the renameable tool number, and what tool-house dependence takes over
- Siemens Tool Offsets — The
$TC_DPcutting-edge table and the tool-name map beside it, two leaves over one object - Datum Tables — The Heidenhain preset and shift rows, one component serving both, and the preset rows the work coordinates alias
- Frames — The Siemens settable frames, the ids they seed, and what the work-coordinate leaf shows of the same table
- Persistent Variables — The retained common variables and the R parameters: sparse tables, accepted ranges, and the difference between vacant and deleted
See Also
- Controller Branch — the branch this plane is half of, its runner root and the machine plane beside it
- Machine and Controller Plane — the other plane, whose ownership splits between the runner and the project where this one does not
- Brand Matrix — which brand satisfies each gate named above, and what each flag actually probes
- Editing Contract — the commit, rollback and rendering rules every leaf on this plane inherits, and the panels that depart from them
- Work Coordinates — the ungated leaf whose backing object changes with the brand, and the only values a brand switch can carry
- Tool Offsets — the other ungated leaf, and the one table on this plane that survives every brand switch
- Siemens Tool Offsets — the second tool-offset ledger, whose presence relabels the first
- Datum Tables — the two Heidenhain leaves, and the preset rows the work coordinates share
- Frames — the Siemens frame table, read by two leaves of this plane at once
- Persistent Variables — the two variable tables a program's arithmetic reads, kept on the project rather than reset with the session