Learn/Laser/Post-processing & output
Posts & controllers
At a glance
- G-code posts for common motion controllers—arc-aware output when your machine supports it
- Ruida-oriented posts emit controller-ready binaries plus optional network send workflows
- Dedicated output path memory for Laser—Post, Post As, and editor launch stay isolated from Plasma jobs
Pick your post under Machine → Post in the machine configuration — the list is filtered to laser-type posts by the machine's type, and each post exposes its own properties there. Post writes to the remembered output path, Post As... picks a new one, and Edit G-code... opens the result in the editor. All three use a Laser-specific output path, so posting a laser job never clobbers the file your plasma table is watching.
G-code posts
The GRBL Laser post targets GRBL-style motion controllers: laser on/off with M4/M5, XY-only
motion, a configurable S value for full power (default 1000), selectable work offset (G54–G59), and
arcs emitted with either R or I/J words to match what your firmware accepts.
Ruida posts
For CO₂ machines on Ruida controllers, Ruida Laser writes a binary .rd file (RDLC-V8
baseline) the controller loads directly — layer speeds and powers, cut moves, and real engrave
raster motion included. A machine home corner property (default top-right) maps JetCad3's
Y-up coordinates onto your controller's homing corner, and arc linearization deviation defaults to
a tight 0.00025 in for LightBurn-like vector smoothness. Since .rd is binary, Edit G-code...
is blocked for these posts. Ruida Laser Network skips the file entirely: Post → Send to
Machine uploads the job into controller memory over UDP with a job name you choose, asks before
overwriting an existing file on the controller, and never auto-starts the job — you still press go
at the machine. Controller IP, ports, timeouts, and chunk sizing are all tunable post properties.
Generate toolpaths first — see Toolpath generation — then post; the operation order on the sheet is exactly what runs.