The semicolon at the end of every line on a Fanuc screen is one of the most misread characters in machining, because it is not punctuation at all: it is how the control displays the end-of-block character, EOB, the terminator that tells the parser a block is complete. Understand that one fact and the missing-EOB error stops being mysterious, because it becomes what it always was: a line-ending problem, almost always manufactured somewhere between a PC editor and a transfer cable.
One character, two opposite jobs
The confusion is earned, because the dialects genuinely disagree:
| World | What the semicolon is | What ends a line |
|---|---|---|
| Fanuc-family controls | The displayed EOB character: the terminator itself | The EOB, shown as a semicolon |
| LinuxCNC, GRBL, printer dialects | A comment marker: text to the line’s end is ignored | The ordinary newline |
| A PC text editor | Just a character you can type anywhere | Invisible line-ending bytes |
The LinuxCNC documentation defines the semicolon-comment form openly, which is exactly why programs and habits migrating between worlds produce both failure directions: semicolon comments written for a hobby machine mean something else entirely on a Fanuc, and Fanuc-formatted files read oddly in tools expecting the comment convention. Same glyph, opposite jobs, and the comment rules on Fanuc-family iron stay with parentheses for precisely this reason.
Where missing-EOB errors are manufactured
The EOB in a file is carried by the line ending, and line endings are the most invisible bytes in computing: conventions differ across systems, editors translate silently, and some drop the final newline of a file without a word. The production line for this error is therefore familiar: a program leaves the machine or the post correct, gets opened on a PC for a small edit, and comes back with its terminators changed or its last line unterminated. On screen, identical; in bytes, different; at the control, an EOB complaint, or its sibling symptoms, the last block ignored, or M30 misbehaving at the file’s end, since end-of-program handling lives exactly where the missing terminator does.
Manual input at the control adds the keyboard version: the EOB is its own keystroke on a Fanuc panel, inserted deliberately, and operators new to the panel sometimes end blocks with nothing, or with characters that look right and are not. The same muscle-memory mismatch appears in reverse when Fanuc-trained hands type semicolons into PC files expecting them to end lines.
The fix and the prevention
The fix is at the file level, two minutes in any editor that can show line endings: confirm consistent terminators throughout, confirm the final line ends properly, re-save, re-transfer. The prevention is configuration and habit: posts set up for the target control emit correct endings, transfer software configured for the machine preserves them, and the editing workflow that round-trips files deliberately keeps one canonical copy instead of letting variants accumulate. Files assembled by hand, headers pasted, programs concatenated, deserve a tail check alongside their percent-marker check, because boundary characters fail at boundaries.
The EOB itself is one more tape-era survivor: blocks on tape needed an explicit end mark for the reader, the character stayed when the tape left, and modern controls still parse by it. The format’s whole family of edge characters, EOB, percent signs, the optional spaces between words, makes sense together as the fossil record of a physical medium, and reading it that way converts trivia into a mental model.
The transferable lesson
This error teaches the habit that prevents its whole family: treat file structure as part of the program. The visible code is not all the bytes; terminators, markers, and endings are load-bearing, and the operator who checks a file’s first and last lines after any PC excursion catches this class before the control does. The vocabulary side of that fluency, reading the visible code fast enough to attend to the invisible parts, is what the free 60-second drills on the G-code practice page maintain, and the double-identity semicolon makes a fine first flashcard: one glyph, two dialects, zero forgiveness for mixing them.
Sources
Frequently asked questions
What does the EOB semicolon missing error mean on a Fanuc?
The control expected an end-of-block terminator and did not find one: a line, often the last, never ended properly. The semicolon on screen is the displayed EOB character, so the error is about line endings, usually manufactured by PC editors or transfers.
Is the semicolon in Fanuc G-code a comment marker?
No: on Fanuc-family controls it is the displayed end-of-block character, while in LinuxCNC and GRBL it starts a comment. Same character, opposite jobs. Fanuc comments use parentheses.
How do I fix a missing EOB in a program file?
At the file level: open the program in an editor that shows line endings, confirm every line terminates properly including the last, re-save consistently, re-transfer. At the control, the EOB is its own keystroke.
Why do these errors usually appear after editing on a computer?
Because line endings are invisible and editors disagree about them: a file can come back with changed or dropped terminators while looking identical on screen. The control reads bytes, not appearances.