"What's in your safe start for every program?" — and why the answer matters
It’s one of the most-asked questions on any machining forum: what’s in your safe start for every CNC program? Almost every experienced machinist has a “safety line” they put at the top of every program — a short block that forces the control into a known, safe modal state before the real work begins. The reason is simple and a little unnerving: a CNC control is modal. It remembers. Cutter compensation, a canned cycle, incremental mode, a coordinate rotation, the wrong plane, even the wrong units — any of these left active by the program that ran before yours is still active when yours starts, unless you cancel it. The safe start block is how you refuse to inherit someone else’s leftover state.
What a safe start block typically includes
The exact set varies by control and by shop, but a common mill safe start looks like G17 G40 G49 G80 G90 — often with a few more. Here’s what each is doing and why it’s there:
- G17 — select the XY working plane, so arcs and canned cycles use the plane you expect (not a G18/G19 left active).
- G40 — cancel cutter (radius) compensation, so no leftover comp offsets your first moves.
- G49 — cancel tool-length compensation, so a stale length offset doesn’t drop the tool into the part.
- G80 — cancel any canned cycle, so a drilling/tapping cycle from the last program doesn’t fire on your first positioning move.
- G90 — absolute positioning, so your coordinates mean what you intend (not incremental from a G91 left active).
Depending on the control and the shop, a safe start also often includes: G94/G95 (feed-per-minute vs feed-per-rev), G20/G21 (inch vs metric units), G69 (cancel coordinate rotation), G15 (cancel polar), a work offset such as G54, and M5 / M9 (spindle and coolant off). The point isn’t a fixed magic line — it’s to explicitly cancel or set every modal state your program depends on, rather than assume it.
Why it prevents startup crashes
Leftover modal state is one of the classic ways a program crashes on its very first moves — before it’s really doing anything:
- A canned cycle left active (no G80) turns your first rapid positioning into a drilling move — the tool plunges where you only meant to move.
- Cutter comp left on (no G40) offsets your approach, so the tool goes somewhere you didn’t program.
- A stale tool-length offset (no G49) drives Z to the wrong height.
- Incremental mode left active (no G90) turns absolute coordinates into moves relative to wherever the machine happens to be.
- The wrong units or plane (no G21/G20, no G17) scales or orients everything wrong.
- A coordinate rotation left active (no G69) sends the whole program into a rotated frame.
None of these are errors in your program’s geometry. They’re the state your program started in — which is exactly what the safe start block controls.
Verify the startup sequence — not just assume it
A safe start block is a discipline, not a guarantee. It can be incomplete (missing the one cancel that mattered), wrong for the control (a code that doesn’t do there what you think), or defeated by an unusual leftover state. And whether your startup came from a post-processor, a template, or your own habit, the only way to know it leaves the machine in the state you intend is to run it the way the control will.
That’s the case for verifying the startup sequence, not just eyeballing it — because the safe start is precisely about modal state, which a static read of the line can’t confirm.
Where Eureka G-Code fits
Eureka G-Code executes the real NC program — safe start block and all — on a digital twin of your machine, reproducing the control’s modal state exactly as it will behave. So the startup sequence is verified for real:
- If the safe start fails to cancel something — a canned cycle, comp, a rotation — the twin runs the resulting motion, so the plunge, the offset approach, or the rotated move shows up as a collision, near-miss, or wrong motion before the machine does it.
- If a startup code is wrong for the control, the twin executes it the way the real control does, so the mismatch surfaces at a desk.
- Because it runs the whole program from its real starting state, the errors that only appear because of the startup state — not in the geometry — are exactly the ones it catches.
Whether the program is posted from CAM, generated by Eureka NC Coder, or hand-written, its startup is verified as your control will actually behave — the state the first moves really run in, not the state you assumed.
> Take a program’s opening block — your safe start plus the first few moves — and run it on a twin of your machine in Eureka G-Code. Watching the control land in the state you intended, before the first positioning move happens for real, is how a leftover canned cycle or comp gets caught at a desk.
FAQ
What is a CNC safe start block?
A short block at the top of a program that forces the control into a known, safe modal state — commonly G17 G40 G49 G80 G90, often with units, feed mode, work offset, and rotation/polar cancels. It exists because the control is modal and remembers settings from the previous program, which your program would otherwise inherit.
What does G17 G40 G49 G80 G90 mean?
G17 selects the XY plane; G40 cancels cutter (radius) compensation; G49 cancels tool-length compensation; G80 cancels any active canned cycle; G90 sets absolute positioning. Together they cancel or set the modal states most likely to be left active by a previous program.
What else should a safe start include?
Depending on the control and shop: units (G20/G21), feed mode (G94/G95), a work offset (e.g. G54), coordinate-rotation cancel (G69), polar cancel (G15), and spindle/coolant off (M5/M9). The goal is to explicitly set every modal state your program relies on rather than assume it.
How does a missing safe start cause a crash?
Because a leftover modal state governs your first moves. A canned cycle left active turns a positioning move into a plunge; cutter comp left on offsets the approach; incremental mode turns absolute coordinates into relative moves. The geometry is fine — the state it starts in isn’t.
How do I verify my startup sequence?
Run the real program, including the safe start, on a digital twin that reproduces the control’s modal behavior. Eureka G-Code executes it as the control will, so a safe start that fails to cancel something — or a code that’s wrong for the control — shows up as wrong motion or a collision before the machine runs.
Next step
Verify your startup sequence with Eureka G-Code before running the program.
A safe start block sets the state your program assumes. Verifying it — on a twin, as the control behaves — confirms the machine is actually in that state before the first move.
Related Articles
Why wrong plane selection causes arcs to cut into parts and canned cycles to plunge off-axis. Verify modal G17/G18/G19 plane state on a digital twin.
Moving legacy CNC programs to new horizontals risks costly crashes. Learn what breaks in G-code, offsets, and M-codes, and how to verify them
Discover common multichannel sync errors on the Okuma Multus U4000. Prevent crashes and deadlocks by simulating real ISO code on a digital twin.
A digital twin of your multi-channel turn-mill that reads the real ISO of every channel — synchronization, multiple spindles, sub-spindle transfer, constructor cycles and hand edits included — and proves it out before the turrets move. Any controller, any kinematics, no axis limit. Request a demo on a twin of your machine.
Deep-hole drilling for injection and die-casting molds (IMSA, CHETO) isn’t just a toolpath: depth vs diameter, chip evacuation, guide bushings, special cycles and process monitoring all matter
Master Bumotec s191 process orchestration across turning, milling, and grinding. Discover how digital twin simulation prevents costly first-cut errors.
On a multi-channel turn-mill, each channel’s program can be flawless and the machine still crashes — because the collision lives in the timing between channels, not in any one line. Eureka G-Code simulates the real ISO of every channel, synchronization commands included, on a digital twin of your machine, so wait-code mistakes surface before the turrets meet. Request a demo on a twin of your machine.
Eureka Cloud turns every PC on your network into a simulation agent, so a whole shift’s worth of NC programs is verified overnight, in parallel — cleared or flagged before they reach the machine. And despite the name, it runs on your own servers: a private cloud, so your NC programs, geometry and IP never leave your network. Highly customizable, it integrates with your CRM, MES or other apps through APIs and scripting, and can automate post-processing, simulation, and feedrate optimization end to end. Request a demo
Static checks miss parametric logic errors. Execute Macro B variables, IF/WHILE loops, and family-of-parts math on a digital twin to catch crashes off-line.
Why safe Z heights set below clamps or raised features cause rapid collisions between operations. Verify real ISO rapids over actual fixtures on a twin
Why rewrite the same helical interpolation code for every thread size when a macro can generate it from a few parameters? Eureka G-Code simulates the real G-code with macro expansion and helical interpolation, before you cut
Single-block on a multitasking machine is defusing a bomb with the timer running. Step through the real G-code off-machine on a digital twin — watch where a variable actually drives the tool, follow subprogram flow across channels — and find the bug at a desk. Eureka G-Code runs and edits the true G-code on a twin of your machine. Request a demo on a twin of your machine.
A digital twin of your sliding-headstock (Swiss-type) machine that reads the real ISO code and proves it out before the bar runs. Any controller, any kinematics
A probing cycle sets offsets at runtime and changes what every later move does — yet it’s the part of the program almost nobody simulates, because a toolpath render doesn’t run it. Eureka G-Code executes probing cycles on a digital twin of your machine, and checks pre-holes for tapping too. Request a demo on a twin of your machine.
Why G83 peck depths, G98/G99 retracts, and control-specific behaviors cause crashes and scrap. Simulate real canned cycles on a digital twin offline.
On a Citizen Cincom L20, the pains are multi-system ($1/$2/$3) synchronization, the G600-series machining-mode calls that govern gang, front, back and superimposed work, wait codes that must appear in every system, and Z-shift and guide-bushing traps. Eureka G-Code runs the real ISO across every system on a digital twin of the machine. Request a demo on a twin of your machine.
Avoid two-turret crashes on Nakamura-Tome machines. Learn to verify pinch turning, superimpose modes, and waiting M-codes across channels.
On the DMG MORI NTX 1000, the recurring pains cluster around tool offsets that rotate with the B-axis or sub-spindle, wrong origins between the main and counter spindle, a post that doesn’t match the real kinematics, and one-setup programs that assume a machine state that isn’t there. Eureka G-Code runs the real posted ISO on a digital twin of the actual kinematics. Request a demo on a twin of your machine.
G32 cuts a thread one pass per block — every pass, infeed, chamfer and pull-out is on the programmer, and the feed must match the pitch in sync with the spindle. It’s valid code that scraps the thread or crashes the tool when a value is off. Eureka G-Code runs the real G32/G92/G76 passes on a digital twin of your machine
A Swiss-type lathe flips the geometry, packs the tool zone, and lets one tool do many jobs — so the mistakes that scrap parts and crash gang tools are ones a conventional-lathe programmer has never had to think about.
Prevent head order errors, turret mirror mismatches, and EIA/ISO sequence crashes on the Mazak i-300 ST with Eureka G-Code digital twins
Aero-engine blisks and casings push machining to the edge: tough titanium and superalloys, thin deformable parts, and airflow passages between blades so narrow the tool can interfere on a five-axis move
Prevent slow, costly collisions on large vertical lathes like the Pietro Carnaghi AP80. Verify part zero, attachments, and G-code before production.
Most scrap isn’t a crash—it’s a valid program making an out-of-spec part. Compare real ISO simulation to CAD models to catch shifted offsets offline
How wrong call numbers, missing M99 returns, and carried modal states cause program flow crashes. Verify nested M98/M99 call structures on a digital twin
How G90/G91 modal errors, lathe U/W mix-ups, and subprogram mode shifts cause wild moves and crashes. Verify real ISO reference frames on a digital twin
Cut cycle time, extend tool life and save energy by re-modulating feedrates based on real tool engagement. Optimize G-code programs offline
CAM cycle-time math is optimistic on any machine — and on parallel channels with synchronization waits it’s worst of all, because the waits and the interleaving aren’t in the toolpath. Eureka G-Code computes cycle time from the real ISO on a twin of your machine, and Eureka Chronos optimizes it. Request a demo on a twin of your machine
A move that’s geometrically fine can still drive a rotary or B-axis into its travel limit — and because it isn’t a geometry error, a toolpath simulation doesn’t catch it. Eureka G-Code checks overtravel and near-miss against your real machine’s travels on a digital twin. Request a demo on a twin of your machine.
Prevent sub-spindle handoff crashes, front/back side errors, and XB B-axis mismatches on Nomura NN-20J3 Swiss machines with Eureka G-Code.
Unattended bar work turns a crash from one scrapped part into a stopped run and a damaged machine. Here’s the checklist of what has to be verified before you walk away — and how Eureka Cloud runs those simulations overnight, in queue, so the whole night’s programs are proven before the lights go off. Request a demo on a twin of your machine
After a coordinate rotation or a tilted working plane, ‘up’ isn’t machine-up anymore — so a retract programmed in the rotated frame, or with the wrong axis order, drives the head straight into the part instead of clearing it. It’s a crash during what should be a safe disengage. Eureka G-Code runs the real ISO — rotation and kinematics included — on a digital twin. Request a demo on a twin of your machine.
Feedrate optimization isn’t a lab trick. Across real production — hardened-steel molds, aluminum castings, precision components, large gantry work and continuous 5-axis parts like impellers — Eureka Chronos has cut cycle time by roughly 6–26% while holding surface quality and dimensional accuracy, with tool wear reduced or unchanged. And it needs no material or tool libraries to do it. Request a demo.
Master B-axis signs, sub-spindle logic, and Fanuc cycles on the SMX 2100ST. Verify actual ISO code with Eureka G-Code digital twins
CAM simulation checks the toolpath it generated. The machine runs the posted G-code — with constructor cycles, macros, variables, subprograms and probing the CAM never modeled. On multi-channel and sliding-headstock machines, that gap is where the crash lives. Eureka G-Code simulates the true G-code on a digital twin of your machine. Request a demo on a twin of your machine.
Master horizontal spindle kinematics, A’/B’ swivel table logic, and undercut operations on the GROB G350 with Eureka G-Code digital twins.
On paper the DVF 5000 Gen 2 gives you a big envelope and full 5-face access. In real setups it’s tighter: at tilt the reach shrinks, the fixture and trunnion interfere, the tool setter gets in the way, and the table sits off-center from the spindle. That gap between brochure envelope and usable envelope is where setups crash.
The main-to-sub-spindle handoff is a timed dance — advance, grip, match, release before cut-off — and getting it wrong drops the part or crashes the spindles. It’s timing, not geometry, so a listing and a toolpath sim both miss it. Eureka G-Code executes the real transfer on a digital twin of your machine. Request a demo on a twin of your machine.
CAM simulations assume correct offsets and miss wrong H numbers or missing G43 codes. Verify runtime control offsets and G49 states on a digital twin
How shortest-path rollover, degrees/min feed errors, and C-axis wind-up cause 5-axis crashes. Verify multi-axis kinematics and TCP cycles on a digital twin.
Standardize program verification across plants with automated, on-premises batch simulation. Eliminate bottlenecks and ensure no G-code runs unverified
Verify automatic head changes, kinematic transforms, and large-envelope ISO code on PAMA Speedram and Speedmat machines with Eureka G-Code

