SheetCam drives thousands of plasma, laser, and router tables, and every line of G-code it emits flows through a post processor: an editable script that decides what the header says, which M-codes fire the torch, and how the job ends. That editability is the tool’s quiet superpower, and the craft is knowing which problems belong in the post and which belong in the file.
What does the post processor actually control?
Everything textual about the output. The post is a script with sections that fire at events, job start, pen or torch down, torch up, job end, and each section prints the codes your machine receives:
| Post section fires at | Typically emits | Why you would edit it |
|---|---|---|
| Job start | Header: units, modes, offsets | Add a real safety block |
| Torch / tool on | M03 or table-specific codes | Match your controller |
| Torch / tool off | M05 and friends | Same |
| Move between cuts | Rapids at safe height | Adjust clearance |
| Job end | Shutdown, parking | Park the gantry, kill outputs |
Different controllers want genuinely different lines, which is why SheetCam ships dozens of posts and why the closest one to your machine is the starting point, never a universal one.
Post edit or file edit: how do you decide?
By recurrence, with no exceptions worth keeping. A problem that appears in every output, the header missing G21 and G90, torch codes your table ignores, no end-of-job parking, lives in the post, and one fix inherits forward forever. A problem belonging to this job, a gentler feed for warped material, a relocated start, lives in the output file, the same values-and-arrangement editing that governs any posted code, per the AutoCAD-to-G-code workflow. The failure mode of ignoring the rule is concrete: shops that hand-add the same header line to every Friday’s nest are running an unpaid subscription to their own oversight.
What is the safe post-editing workflow?
Four habits keep post edits boring, in the good sense. Copy first: duplicate the closest shipping post, rename it for your table, and never edit originals, so reverting is renaming. One change per cycle: edit a single behavior, regenerate, and diff the output against the previous file, where one expected line should differ. Dry run the result: the proof is the machine running the new output above the material, torch cold, the prove-out discipline applied to tables. Comment what you did: a dated line inside the post saying what changed and why, because the next editor is you in eighteen months.
The edits themselves are usually small. A header gaining a safety block is a print statement listing the standard mode codes; a torch-code swap is two lines; an end-of-program park is a rapid to a corner plus the off codes. The script syntax around them reads like any scripting language’s print logic, and the G-code being printed is the vocabulary you already drill.
A concrete example with a moral: a four-by-eight plasma table kept finishing jobs with the gantry parked over the cut parts, dripping. One post edit, a final rapid to the far corner before shutdown, and every job since has ended with clear access to the table. Eight months of reaching over the gantry, fixed by three lines that took ten minutes, which is the post-editing experience in miniature.
Where does torch height control fit?
Mostly outside the post’s pay grade, and knowing the boundary prevents over-editing. The pierce-and-cut height moves the post emits are its business; the live arc-voltage corrections during cutting belong to the THC hardware, and the probing handshake that finds the material surface has its own codes, covered in torch height control and G31. When a height problem is live and continuous, stop editing the post; that fix lives in the THC settings.
Bottom line
SheetCam’s post processors are editable scripts deciding every emitted line: fix recurring output problems there once, keep one-off tweaks in the file, and edit posts with the copy-rename-one-change-dry-run ritual. The G-code the post prints is the everyday vocabulary, drillable free on the G-code practice hub, and a shop that owns its post owns its output.
Sources
Frequently asked questions
How do you edit a SheetCam post processor?
Copy the closest shipping post, rename it for your machine, change one behavior at a time, and prove each change with a diff and a dry run above the material.
When should you edit the post versus the G-code file?
By recurrence: every-output problems (headers, torch codes, parking) go in the post once; this-job tweaks (feeds, start points) go in the file.
What are the most common SheetCam post edits?
A real safety block in the header, torch on-off codes matched to the controller, correct units, and an end-of-program parking sequence.
What is the best way to learn enough G-code to edit posts confidently?
Read emitted output until it narrates itself. A free app like G-Code Sprint drills the everyday codes and repeats whichever ones you miss, the exact vocabulary posts manipulate.
G-Code Sprint is a study and practice tool only. Always follow your instructor, employer, machine manual, and shop safety procedures.