Table of Contents

Controller

The controller is the NC parser a project reads its programs with: a brand, the machine and control settings that brand assumes, and the coordinate, offset and variable tables an NC program addresses. Setting it up is picking the brand first, then filling in the tables that brand grew.

Where it is

The General Setup page, at /general-setup, reached from the menu bar's Page dropdown. Select the Controller branch of the Control Tree (/general-setup?tree=equipment/controller); it sits after Workpiece, and whichever node you select opens its editor below the tree in the same dock.

The branch grows children only with a project open and a controller resolved on it, so a Controller node standing alone is the state before a project is open rather than a fault; a project file naming no controller keeps the Fanuc preset. Once a runner resolves, the root's own panel badges the brand in force and enables an Object Management (⋮) menu, whose Load installs a .Controller, .SoftNcRunner or .xml runner file in place of the whole controller and whose Save As writes the current one out, offered as NcRunner.Controller.

Pick the brand first

Select Controller Brand (equipment/controller/machine/brand), pick one of Fanuc, Siemens, Heidenhain, Syntec and Mazak, and press Apply brand. Until you do the pick is only staged: Revert drops it, and so does selecting another tree row.

Do it before anything else, because it replaces the whole controller rather than one field:

  1. The dialect changes. Each brand is a different reader; what its G and M words actually do is NC Dialects.
  2. The node set changes. The branch is regrown, so nodes the new brand has no concept of stop existing and its own appear.
  3. Machine settings reset to the new preset's defaults. The runner-owned ones — the tool-change position, block-skip layers, subprogram folders and the macro iteration guards — reset on every apply. The travel limits, rapid feedrates, home reference, M-code declarations and native parameters live in the brand's parameter table and reset only where the switch also sweeps that table; Fanuc and Mazak share one, so a switch between those two leaves them where they are.
  4. The old brand's own program-data tables are removed — the ones only that brand proxies: Siemens frames, $TC_DP offsets and R parameters, Heidenhain datum presets and shifts. Tool offsets survive every switch, and retained common variables survive among Fanuc, Syntec and Mazak. What is swept does not come back: switching back builds those tables fresh from the new preset's defaults. Carry work-coordinate XYZ (G54…) into the new brand's table, ticked by default, moves the work offsets across — only those, and only for ids the new brand also holds: Fanuc to Siemens keeps G54–G57 and drops the rest.

A brand switch and an Object-Management load are both refused while an NC program is playing — see Playing a Program.

The Controller Brand leaf on a demo project, at /general-setup?tree=equipment/controller/machine/brand. The machine plane above it is expanded, so the eleven leaves this brand grows are all visible; the panel below carries the Controller brand select reading Fanuc, the carry checkbox ticked, and the Apply brand and Revert buttons that are enabled only while a different brand is staged.

The Controller branch of the Control Tree with its Machine / Controller plane expanded, listing Controller Brand, Machine Limits (Stroke), Rapid Feedrates, Home / G28 Reference, Tool-Change Position, Controller Parameters, M-Code Declarations, Canned Cycle (Peck), Block Skip / Delete, Subprogram Folders and Parameters (Native); the panel below shows a Controller brand select reading Fanuc, a ticked checkbox reading carry work-coordinate XYZ into the new brand's table, and the Apply Brand and Revert buttons

The two planes

Every other node hangs on one of two group stems, and which one it is on says what it describes; selecting a stem lists its children.

Plane Tree id What sits on it
Machine / Controller equipment/controller/machine What the machine is wired to do: travel limits, rapid feedrates, the home / G28 reference, the tool-change position, the controller parameters in both a grouped and a native form, the peck clearance, M-code declarations, block-skip layers, subprogram folders and, on Siemens, the indexing position tables
Program Data equipment/controller/program-data The tables a program reads and writes: work coordinates (G54…) and tool offsets on every brand, plus the brand's own — Siemens frames, $TC_DP offsets and R parameters, Heidenhain datum presets and shifts, Fanuc-family retained common variables

The machine plane's per-axis rows are driven by the machine tool's chain: every brand preset already declares X, Y and Z, and attaching a machine tool adds that chain's own axes beside them. Program data stays with the project, so loading a controller file of the brand already in force leaves those tables as they are.

Work Coordinates always lists the plain G54–G59 rows its brand's table holds — Siemens seeds only G54–G57 — and, on Fanuc, Mazak and Syntec, the extended G59.1–G59.9 rows of the brand-neutral table that sits behind the brand table; it shows the G54.1P and G505–G599 rows once a value is non-zero or the Show all toggle is on. Each row carries P0, which writes the machine coordinate the workpiece's program-zero anchor sits at, and M0, which writes machine zero; clicking anywhere in a row also marks that coordinate on the canvas. Both write into the table; neither moves the part. The other direction — moving the part so that program zero lands on the offset a row already holds — is not offered on the runner path: this branch is the runner's own settings face and has no such control, and the Legacy-Controller screen that used to carry one (Align P0) was removed on 2026-09-11. Placing the part on a recorded offset is done by hand — Program Zero Alignment.

A table that is not there

A node the active brand has no concept of is never created rather than shown and disabled — Frames on Fanuc, Retained Common Variables on Siemens, Block Skip / Delete on Heidenhain — and a ?tree= link naming one does nothing on the wrong brand, so name the brand alongside any id shared. Nor is an id promised to survive a version change — see Finding Your Way.

Two further rows may differ from a colleague's tree for an unrelated reason: CSV Controller and CL Controller are separate non-brand controllers, absent until their box in the Preference dropdown is switched on, and which box is on is a per-device setting — see Preferences. Unlike a brand-gated node, though, these two are still reachable by link: a ?tree=equipment/controller-csv or ?tree=equipment/controller-cl mints the node and selects it whatever the box says, so a shared bookmark never dead-ends.

The Preference menu answers whether you need either of them. Under each of the two checkboxes it reads This project plays CSV / This project plays CL, or Not used by this project, worked out from what the open project actually plays — the kinds its mission commands name, the play verbs its scripts call, and, for CL, a machine chain that can only be driven from CL. Neither node is a setup task in its own right: both are childless leaves with no Object Management, because a CSV or CL pipeline is not loaded, pasted or saved as a file the way a brand controller is. Switching a box on reveals the pipeline's settings; leaving it off on a project that plays neither costs nothing.

See Also

  • NC Dialects — what each brand's G and M vocabulary actually does, once the brand is picked
  • Machine Tool — the chain whose axes fill the per-axis rows on the machine plane
  • Program Zero Alignment — the other half of a work offset: where program zero sits on the workpiece
  • Setup — the rest of the pre-simulation configuration