M30 makes two promises: end the program, and rewind to the top so the next cycle start runs it again. A machine hanging at M30 has usually kept the first promise and broken the second, and the break is almost never mysterious, because rewind is a file-and-mode operation with a five-item suspect list, most of it checkable from a text editor without touching the machine.
What “stuck” usually looks like
The symptom wears a few costumes worth recognizing as the same complaint: the cycle finishes and the cursor sits at the bottom instead of returning to the top; the next cycle start does nothing, or restarts mid-file; the screen reports the program end but the control never re-arms for the next part. In a production setting the cost is rhythm, an operator hand-resetting between every part on a job that should loop, which is why this small failure generates disproportionate frustration. All the costumes share one anatomy: the end executed, the return-to-top did not, and something between the file’s last bytes and the control’s run mode is responsible.
The five causes, cheapest check first
| Suspect | The mechanism | The check |
|---|---|---|
| Missing end-of-block after M30 | The final line never terminates, so end-of-program handling stalls | Open the file’s tail: does the M30 line end like every other line? |
| Missing percent terminator | Tape-style controls expect a file-end marker and mishandle its absence | Is the closing marker present on controls that use it? |
| DNC or streaming mode | No stored program exists, so rewind has nothing to rewind | Was this run drip-fed rather than from memory? |
| M02 doing M30’s job | M02 ends without rewinding on some controls | Is the ender actually M30, or an inherited M02? |
| Control settings | Rewind behavior is configurable on some controls | The machine’s documentation, parameter side |
The top two are the file-format pair, and they dominate real cases because they are exactly what gets lost in transfers: a file edited on a PC whose editor dropped the final newline, a transfer that clipped the last bytes, a program assembled by concatenation that lost its closing marker. The fix costs one character; finding it costs opening the file’s last lines, which is also where percent-sign questions get their full answer, since the marker that opens a file has a closing twin whose absence is this exact symptom.
Why a 1960s tape convention still stops machines
Rewind is not a metaphor: on the punched-tape machines this language grew up on, M30 physically rewound the tape reader to the start marker, and the percent signs bracketing a program told the reader where the program lived on the physical medium. Modern controls inherited the choreography along with the language: memory replaced tape, but the end-of-program handling still walks the old sequence, end, then return-to-top, and on control families that kept the marker conventions, the markers still participate. It is the same inheritance that gives programs their N-number habits, and it ages well precisely because it is simple: one character at each end of the file, one M-code at the end of the work.
The M02-versus-M30 wrinkle rides the same history: M02 was program end in an era where rewind was a separate luxury, M30 was end-with-rewind, and controls diverged on how faithfully to preserve the distinction. Programs inherited from old sources sometimes carry M02 enders, documented per dialect in references like LinuxCNC’s M-code list, and an operator expecting M30 behavior from an M02 file gets exactly this complaint.
The DNC case, which is not a malfunction
Drip-feed and streaming runs end differently by nature: the control consumed the program as it arrived, holds no stored copy, and has no top to rewind to, so end-of-stream behavior belongs to the transfer configuration rather than to M30. Shops that mix memory runs and DNC runs see this asymmetry regularly, and the operational answer is knowing which mode the run used before judging the ending, one more entry in the situational awareness that mid-program operations demand generally.
The two-minute diagnostic
In practice: open the program’s last lines off the machine and inspect the ender and the markers, that is suspects one, two, and four in one look. Confirm how the program ran, memory or stream, that is suspect three. What remains is suspect five, the settings layer, which the machine’s documentation owns. The reading habit underneath, treating file structure as part of the program rather than invisible plumbing, is the same one that makes comment and format conventions legible, and it runs on the standard vocabulary being automatic, which the free 60-second drills on the G-code practice page keep current. A machinist who reads file tails diagnoses this one from a chair.
Sources
Frequently asked questions
Why is my CNC machine stuck on M30 and won’t rewind?
Work the suspect list: missing end-of-block after M30, missing percent terminator on tape-convention controls, DNC streaming mode where rewind has no meaning, an M02 doing M30’s job without rewind, or a control setting. The file-format pair covers most cases and is visible in a text editor.
What is the difference between M30 and M02?
Both end the program; M30 conventionally adds the rewind, while M02’s end behavior varies by control. Programs inherited from old sources sometimes carry M02 enders, and the machine’s documentation owns the fine print.
Does the percent sign at the end of the file matter for M30?
On controls that honor tape-era markers, yes: a missing closing marker can confuse end-of-program handling, including rewind. It costs one character to be correct.
Why does rewind fail when running a program through DNC?
Because rewind means returning to the top of a stored program, and streaming modes consume the program as it arrives: there is no top. End-of-stream behavior belongs to the transfer configuration.