--- title: "SheetCam Post Processor G-Code Edits That Make Sense" description: "SheetCam's post processors are editable scripts that decide every emitted line. Here is when to edit the post versus the output, and the safe workflow for both." url: https://gcodepractice.com/journal/sheetcam-post-processor-g-code-edit/ canonical: https://gcodepractice.com/journal/sheetcam-post-processor-g-code-edit/ author: "Lawrence Arya" authorUrl: https://www.linkedin.com/in/vibecoding/ published: 2026-06-04 updated: 2026-06-04 category: "Practice" tags: ["sheetcam", "post-processor", "plasma", "g-code"] lang: en --- # SheetCam Post Processor G-Code Edits That Make Sense > **TL;DR** SheetCam emits G-code through editable post processor scripts, so recurring output problems, missing safety blocks, wrong torch M-codes, units, end-of-job parking, belong in the post, fixed once for every future job, while one-off tweaks belong in the output file. Edit posts safely: copy and rename before touching, change one thing at a time, and prove the result with a dry run above the material. [SheetCam](https://www.sheetcam.com/) drives thousands of [plasma](https://en.wikipedia.org/wiki/Plasma_cutting), 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](/journal/autocad-to-g-code-manual-editing/). 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](/journal/how-to-safely-test-a-g-code-program-without-crashing/) 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](https://linuxcnc.org/docs/html/gcode/g-code.html); 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](/journal/torch-height-control-g-code-commands-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](/g-code-practice/), and a shop that owns its post owns its output. ## Sources - [SheetCam (post processors)](https://www.sheetcam.com/) - [Wikipedia: Plasma cutting](https://en.wikipedia.org/wiki/Plasma_cutting) - [LinuxCNC G-code reference](https://linuxcnc.org/docs/html/gcode/g-code.html) ## 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.* --- Source: https://gcodepractice.com/journal/sheetcam-post-processor-g-code-edit/ Author: Lawrence Arya — https://www.linkedin.com/in/vibecoding/