Modal vs Non-Modal G-Codes in CNC Programming
Modal vs non-modal is the distinction at the heart of reading and writing G-code, and it is simple to state: a modal code sets a state that stays in force through the blocks that follow it until another code of the same kind replaces it, while a non-modal (one-shot) code acts only in the block that carries it and is then forgotten. The distinction matters because most of a CNC program’s meaning lives in its modal state: a program does not repeat the feed mode or the motion mode on every line — it sets them once, and every later block runs under them. The machine is not executing a list of independent instructions but a running state that each block updates, and the machinist who reads a program well is tracking that state, as the reading a program block entry explains. This entry sets out the distinction fully: what is modal, what is not, and what the difference means for the programs a shop writes and runs.
What a modal code does
A modal code is a code with memory, and its memory is the whole point of it. When a program writes a motion word — say, the straight-line feed of the linear and circular interpolation family — that word sets the mode of motion, and every following block that gives coordinates continues in that mode until another motion word replaces it. The same is true across the modal families of G-code: the plane selection, the unit system, absolute or incremental dimensioning, the work offset selection, cutter compensation on or off, and the feedrate mode are all modal states set once and carried forward. The economy is enormous — a long run of cutting blocks needs no mode words at all, only coordinates and the occasional feed or speed — and the codes are written once near the start of a section, exactly as the structure of a program prescribes. Modal codes are the reason a program can be short enough to read and to prove.
One code from each group
The modal codes are organised into groups, and the rule that governs them is that only one code from a group can be active at a time. The motion group holds the rapid, the straight-line feed and the arcs; the units group holds metric and imperial; the dimensioning group holds absolute and incremental; each new code from a group quietly cancels the code from that group that was active before. The control tracks one current member of every group, and a block changes only the groups its words touch — a block that writes a new motion mode changes the motion group and leaves the units and the offsets untouched. Reading a program is therefore not a matter of looking at each block alone but of knowing, for every modal group, which code is currently in force, because the block that moves the tool assumes every one of them without saying so. This is the sense in which a program block is read as part of a running conversation rather than as a sentence on its own.
What a non-modal code does
A non-modal code is the exception that proves the rule: it acts only in the block that carries it, sets no lasting state and is forgotten when the block ends. The classic one-shot words are the dwell, which pauses the machine for a set time in its own block and nothing more; the move in machine coordinates, which positions the tool relative to the machine’s fixed zero rather than the part and leaves the working modes unchanged; and the direct return to a machine reference point, which performs its move and is done. A non-modal code is written exactly where its single action is wanted, and it does not disturb the modal state that surrounds it — the program steps into it and steps back out, with the feed mode and the offsets exactly as they were. Reading one is simpler than reading a modal code, precisely because it carries no future: the block is the whole of its effect.
The state at start-up and reset
The modal state of a program has a beginning, and the beginning is the machine’s own. When a control is powered up or reset it returns to a set of default modal states — its initial motion mode, its initial unit and dimensioning defaults — and these defaults are not the same on every make of machine. A program cannot assume that the machine is in the modes the program wants when it starts: it must set them. This is why the disciplined opening of a program forces every critical mode to a known value before any cutting — the absolute or incremental mode, the units, the offset and the feed mode are declared, not inherited — so that the program’s first blocks mean the same thing on any machine and after any reset. The same discipline guards the restart: a program resumed from a middle block, or run again after a reset, stands on whatever state is active, and only a program that sets its own state can be trusted to run from anywhere.
Why the distinction matters
The modal and non-modal distinction is not an academic detail of the language; it is the source of both the power and the danger of G-code. Its power is economy and clarity — a program that sets its modes once and then gives coordinates is short, fast to read and easy to keep consistent, and the modal groups this wiki describes are the machinery of that economy. Its danger is assumption — a mode left over from an earlier block, a dimensioning mode changed and forgotten, a motion mode replaced unseen, and the machine does something the program’s writer did not intend, which is why the proving out of a program walks its blocks tracking the state as this entry has described. The machinist who holds the distinction — what stays active, what acts once, and what the machine believes at any moment — reads a program the way its writer meant it to be read, and writes programs that mean the same thing to every control that runs them.