Learn/GcodePilot/Connection & firmware
Machine Connection
At a glance
- GRBL 1.1 over USB serial; FluidNC (ESP32) over serial or WiFi — same protocol, one driver layer
- Machines using a GcodePilot post appear under Motion automatically, no separate setup
- Port, baud, and firmware are per-machine settings with live port enumeration
- Single-owner port arbitration — contention is a clear message, never a cryptic OS error
There is no separate "add a machine" step for machine control: any machine whose post declares
Controller: GcodePilot (the bundled GRBL and FluidNC posts do) shows up under MOTION as a
GcodePilot workspace, and stays a CAM post target at the same time. The machine's Connection settings
hold the serial Port (enumerated live from what's plugged in), Baud (115200 default), and the
firmware — auto-detected from the selected post, so picking a FluidNC post puts the machine on the
FluidNC driver. Connect from the workspace toolbar.
GRBL and FluidNC
GRBL 1.1 over USB serial is the reference target. FluidNC (ESP32) keeps GRBL's runtime protocol — the
same status reports, acks, jogging, and realtime bytes — so the FluidNC driver inherits the whole GRBL
runtime and adds what's actually different: a USB Serial or WiFi transport choice (WiFi is telnet
to a host/IP you enter), config.yaml configuration, and the plasma AVTHC features. The bundled
"noradio" serial firmware builds are the recommended images because they include firmware-native
jogging; WiFi builds work too and fall back to host-planned jog automatically. See
Firmware Settings for how configuration reaches each firmware.
One owner per port
Every part of the app that opens a serial port — the connection, the firmware flasher — goes through a single-owner arbiter, so grabbing a port that's already in use produces a plain-language message naming the holder instead of a cryptic OS access error. Once connected, the connection badge's menu is the hub for the rest: the Serial Monitor on any firmware, plus the FluidNC config push/edit and reboot actions. A job runs in the background, so switching workspaces or setting up the next cut never drops the stream.