Table of Contents

Machine and Controller Plane

Machine / Controller is the first of the Controller branch's two plane stems: what describes the machine and the control that drives it, edited one leaf at a time. It lives on the General Setup page at /general-setup under the Control-Tree id equipment/controller/machine, and each of its leaves takes that id plus one segment — brand, limits, rapid, home, tool-change, parameters, m-codes, canned-cycle, block-skip, subprograms, indexing-positions, native. 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 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 "Machine and controller presets that travel with the runner file — brand, travel limits, rapid rates, home / G28 reference, the tool-change position and the controller parameters (in both a domain-grouped interface form and the native parameter form)."

What “Travels With the Runner File” Means

The phrase names an ownership boundary, not a file on disk, and the boundary does not fall where the introduction's list suggests. Half of what this plane edits is stored on the project.

The suit's two members

NcRunnerSuit carries the runner, SoftNcRunner, and the project's own PerCaseNcDependencyList, and serializes the two side by side. The runner half honours SoftNcRunnerFile: with a project-relative path recorded there the runner XML is written to that side file and referenced from the project; with none recorded it is inlined in the project file. The per-case half is always inlined — the suit writes it as a nested element with no file reference of its own.

The web service reads that recorded path and never writes one. On a project that has never been given a side file, both halves therefore sit inside the same project file, in two slots whose contents behave differently the moment a runner is swapped. A controller file is one serialized runner. Its canonical extension is .Controller (FileExtension), and the branch root's Load browser accepts the earlier .SoftNcRunner spelling beside it.

Which half a value lands in

A runner's PipelineNcDependencyList holds two shapes of entry.

A plain dependency is the runner's own. Its edited values serialize with the runner, and installing another runner replaces the instance outright.

A proxyINcDependencyProxy — carries no live data. Each brand parameter-table proxy holds a fixed machine-config seed and serializes only that seed; WireNcDependencyProxies(API) deep-clones the seed into the project's per-case list only when the project holds no table of that type, and an existing table wins. Reads and writes then resolve through GetEffectiveNcDependencyList(API), which substitutes the project's table for the placeholder. All four brand tables' proxies are written to the same shape, and the seed is set once at construction and never rewritten by an edit.

Two consequences follow, and they are what the introduction's phrasing hides:

  • The per-axis rows, the M-code declarations and the native parameter rows are stored on the project, because they are all rows of the brand parameter table. Installing a same-brand runner file leaves them where they are, apart from the rotary reference and rapid rows that any re-bind of the suit re-stamps.
  • Saving a runner file captures the proxy's seed, not the table the panels have been editing. A .Controller written after the axis tables were tuned carries the preset seed those tables were cloned from.

Why the table is per-case at all splits by brand. The Fanuc-family and Syntec tables mix machine configuration with the per-case work-coordinate offsets the program-data plane edits, which the two planes could not otherwise separate. The Siemens machine-data and Heidenhain tables carry no work coordinates — those two brands keep their offsets in a separate per-case table — and are per-case for the other half of the same reason: the project's own table wins over the seed, so machine data and machine parameters already edited survive a same-brand runner install instead of resetting to the preset's.

The Plane's Leaves

Ordered as the branch builder pushes them: the ungated leaves first, then each gated leaf 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 What backs it Stored on
brand Controller Brand ungated CncBrandDependency runner
limits Machine Limits (Stroke) ungated the brand parameter table's stroke-limit rows project
rapid Rapid Feedrates ungated the brand parameter table's rapid-rate rows project
home Home / G28 Reference ungated the brand parameter table's reference-position rows project
tool-change Tool-Change Position ungated ToolingMcConfig runner
parameters Controller Parameters ungated the brand parameter table, plus the runner's iteration guards split
m-codes M-Code Declarations hasNativeTable the brand parameter table's declaration map and tool-change trigger project
canned-cycle Canned Cycle (Peck) hasCannedCycle the brand parameter table, or FallbackConfig brand-dependent
block-skip Block Skip / Delete hasBlockSkip GenericBlockSkipConfig runner
subprograms Subprogram Folders hasSubprogramFolders SubProgramFolderConfig runner
indexing-positions Indexing Position Tables hasIndexingTables SiemensMachineDataTable project
native Parameters (Native) hasNativeTable the brand parameter table, as its raw dictionaries project

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.

One flag grows two of these leaves: hasNativeTable gates both M-Code Declarations and Parameters (Native), because the declarations live on the same table the native form exposes.

Two leaves that straddle the boundary

Controller Parameters is the one leaf whose fields do not share a storage half. Max spindle speed, the cutter-compensation startup type and the tool-axis direction are written onto the brand parameter table, so they are project-owned; the macro loop guards under Macro loop guards (advanced) are written onto the runner's own iteration-guard dependencies, so they are runner-owned. The panel gates its whole body on the parameter table's presence, which is the project-owned half.

Canned Cycle (Peck) is the one leaf whose storage half depends on the brand. Where the brand table supplies the clearance it is a row of that table and project-owned; where the preset supplies it through the generic fallback config it is a plain runner entry and runner-owned. The read reports which of the two answered, and the panel names the source in the caption under the field.

What an Install or a Brand Switch Does

Object-Management Load, Paste and XML apply all install a runner through SoftNcRunner, and a brand switch assigns the brand's preset through the same setter. Both are followed by the same sweep, and for this plane the outcome splits exactly along the storage column.

The runner-owned leaves take the incoming runner's values, so a brand switch returns the tool-change position, the block-skip layers, the subprogram folders and the macro guards to the new preset's defaults. Installing a controller file of the brand already in force replaces those same four with the file's values while the project keeps its own parameter table — the same-brand re-flash the REST surface's own remark calls per-case lossless, naming those four as what resets. That re-flash is not reachable from the brand select, whose apply is enabled only while the staged brand differs from the active one (Brand Switch); Load, Paste and XML apply are the surfaces that issue it.

The project-owned leaves keep the project's table: the incoming proxy re-binds to it rather than cloning its seed over it. Before the swap, any brand parameter table baked directly into the outgoing runner's pipeline list — the storage a project file saved before that table went per-case still uses — is moved into the per-case list so the incoming proxy can claim it, and a moved table no proxy claims is dropped again afterwards. The chain walk that follows the re-bind is the only part of the swap that writes into the surviving table: it stamps the chain's axes onto it, and with them every rotary axis's reference position and rapid rate.

A switch to a different brand ends with the per-case tables the new runner resolves through no proxy removed, so the previous brand's parameter table does not linger unread. Switching back does not restore it; a fresh table is cloned from the new preset's seed instead.

Both writes are refused while an NC program is playing, and each answers with a conflict rather than swapping the parser under a running session.

One Table, Two Forms

Machine Limits, Rapid Feedrates, Home / G28 Reference, M-Code Declarations, most of Controller Parameters and all of Parameters (Native) read and write one object: the brand parameter table. ControllerParameterTableBase declares the role accessors — home reference, axis set, rapid feedrates, stroke limits, spindle control, M-code declarations, the tool-change trigger — and each brand subclass maps those roles onto its own parameter numbers. The domain-grouped leaves call the accessors; the native leaf writes the raw dictionary cell under the number. Editing one form changes what the other shows.

Where a brand stores a role in its own unit the two forms differ by that unit, and the peck clearance is the case that ships: the Syntec table stores it in microns and its accessor converts, while the Fanuc-family table stores millimetres directly. The interface leaf therefore shows the same number on every brand and the native leaf shows the brand's raw stored value.

What a freshly switched brand shows is decided by that brand's default table. Every one of them declares a linear X, Y and Z with a reference position of zero and a rapid rate per axis, so Rapid Feedrates and Home / G28 Reference open populated. None of them declares a stroke limit, so Machine Limits opens with empty cells on every brand; and only the Siemens default table pre-declares any M-codes, so M-Code Declarations opens empty on the other four brands, Mazak included, because it carries the Fanuc table. An axis with no rapid-rate row of its own reads a fixed default rather than a blank cell.

The axis rows those leaves list are the parameter table's own axis entries. Whenever the suit or the machine chain is re-bound, a chain walk stamps the chain's axis codes onto that table: it adds axes and removes none, and a linear axis keeps what the table already holds, gaining a reference position only where it had none. A rotary axis is the exception — every walk rewrites its reference position to 0 deg and its rapid rate to 36000 deg/min, so a tuned rotary value does not survive the next stamp. The chain itself is edited on Machine Tool.

Layout

  • General Setup Control Tree — the left dock of /general-setup
    • Controller Node Row
      • Machine / Controller Group Row — equipment/controller/machine
        • Controller Brand Node Row
        • Machine Limits (Stroke) Node Row
        • Rapid Feedrates Node Row
        • Home / G28 Reference Node Row
        • Tool-Change Position Node Row
        • Controller Parameters Node Row
        • M-Code Declarations Node Row — grown while the snapshot reports a brand parameter table
        • Canned Cycle (Peck) Node Row — grown while it reports a peck-clearance provider
        • Block Skip / Delete Node Row — grown while it reports a block-skip config
        • Subprogram Folders Node Row — grown while it reports a subprogram-folder config
        • Indexing Position Tables Node Row — grown while the brand table is the Siemens machine-data table
        • Parameters (Native) Node Row — grown on the same flag as M-Code Declarations
      • Program Data Group Row — the plane beside this one
  • Editor Row — the panel of whichever node is selected
    • Machine / Controller 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

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 machine stem's id, label key and intro key, the leaves it pushes unconditionally, and the snapshot flag each further leaf is pushed behind, in the order the table above lists them.
  • 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 the equipment/controller root 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, and the install and brand-switch calls that regrow the branch.
  • wwwroot-src/src/i18n/en/softNc.ts — the stem's introduction line and every leaf label in the table above.
  • Mech/SoftNcRunnerController.cs — the plane's REST surface: the presence flags, the per-group readers and writers, the runner install, and the brand switch with its carry and its sweep of per-case tables the new runner references through no proxy.

HiAPI Engine

  • HiMech/NcParsers/NcRunnerSuit.cs — the suit: the runner, its optional side-file path, the per-case list, the flat serialization that inlines the per-case half and file-references the runner half, and the proxy wiring.
  • HiMech/NcParsers/SoftNcRunner.cs — the pipeline list this plane's dependencies sit in, the five brand presets that decide which of them a brand carries, the proxy resolution every read goes through, and the chain configuration that stamps axis codes onto the table.
  • HiMech/NcParsers/ControllerPresetWriter.cs — the canonical controller-file extension and the writer that renders one brand preset as a standalone runner file.
  • HiMech/NcParsers/Dependencys/INcDependencyProxy.cs — the maker-and-taker contract: what a proxy may serialize, and why its resolved data is never written into the runner.
  • HiMech/NcParsers/Dependencys/Fanuc/FanucParameterTableProxy.cs — the get-or-create proxy behind the Fanuc-family table the Fanuc and Mazak presets share, and the shape the other three brand tables each repeat in a proxy class of their own: a serialized seed on the runner, a deep clone installed into the project only when the project has no table of that type, and a take thereafter.
  • HiMech/NcParsers/Dependencys/ControllerParameterTableBase.cs — the role accessors the domain-grouped leaves call, the per-brand parameter numbers they map onto, and the raw dictionaries the native leaf edits.
  • HiMech/NcParsers/Dependencys/Fanuc/FanucParameterTable.cs, HiMech/NcParsers/Dependencys/Syntec/SyntecParameterTable.cs, HiMech/NcParsers/Dependencys/Siemens/SiemensMachineDataTable.cs, HiMech/NcParsers/Dependencys/Heidenhain/HeidenhainParameterTable.cs — the four brand tables and their default seeds: the axis rows, the rapid rates, the peck clearance and its unit, and the only pre-declared M-codes on the plane.
  • HiMech/NcParsers/Dependencys/Generic/ToolingMcConfig.cs, HiMech/NcParsers/Dependencys/Generic/GenericBlockSkipConfig.cs, HiMech/NcParsers/Dependencys/Generic/SubProgramFolderConfig.cs, HiMech/NcParsers/Dependencys/Generic/FallbackConfig.cs — the plain runner-owned dependencies behind the tool-change, block-skip, subprogram and fallback-clearance leaves, and the values each one serializes with the runner.
  • HiMech/NcParsers/Dependencys/Fanuc/FanucGotoIterationDependency.cs — a macro guard, the runner-owned half of the Controller Parameters leaf.
  • HiMech/NcParsers/Dependencys/CncBrandDependency.cs — the brand marker the first leaf edits.
  • HiNc/MachiningProcs/LocalProjectService.cs — the facade setter every install and brand switch assigns through: the hoist of pre-proxy baked tables, the drop of the ones no proxy claims, the proxy re-binding and the chain-driven axis stamp.
  • HiGeom/Common/XmlUtils/XmlUtil.cs — the file-reference helper that decides whether the runner is written to its side file or inlined.

Pages

Ordered by the first node each page owns, as the plane lists them.

  • Controller Brand — The brand select and its staged apply, and what a brand change carries, resets and destroys
  • Per-Axis Tables — The four leaves whose rows follow the machine chain: stroke limits, rapid rates, the G28 reference and the tool-change position
  • Interface Parameters — The domain-grouped parameter form and the peck-clearance leaf beside it, including the fields whose storage half differs
  • M-Code Declarations — What a declared machine M-code consumes, the tool-change trigger mode, and the codes an undeclared M word still warns about
  • Program Reading — The two leaves that decide how a program is read rather than how the machine moves: block-skip layers and the subprogram lookup folders
  • Indexing Positions — The coded-position tables and the per-axis assignment that decides which axis reads which
  • Native Parameters — The raw parameter form: brand numbering, raw stored units, and the same table every other leaf on this plane edits

See Also

  • Controller Branch — the branch this plane is half of, its runner root and the program-data plane beside it
  • Program Data Plane — that plane itself, whose leaves are project-owned throughout where this one's ownership splits between the runner file and the project
  • 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
  • Controller Brand — the control that replaces the runner, and therefore everything in the runner-owned column here
  • Per-Axis Tables — the per-axis leaves whose rows come from the machine chain and whose values are stored on the project
  • Interface Parameters — the interface parameter form and the peck-clearance leaf, the two entries that straddle the storage boundary
  • M-Code Declarations — the declaration map on the same table the per-axis leaves edit
  • Program Reading — the block-skip and subprogram leaves, the two settings that change how a program is read rather than how the machine moves
  • Indexing Position Tables — the leaf that grows only where the brand table is the Siemens machine-data table
  • Native Parameters — the raw form of the table behind most of this plane