Firmware Settings

You don't set homing direction, max travel, and direction invert separately — the signed per-axis Travel in the Axes section derives them. Its magnitude becomes GRBL's max travel ($130–$132), its sign sets the homing direction mask ($23 — negative travel homes toward the axis maximum, the usual plasma Z), and the per-axis Rev checkbox maps to the direction-invert mask ($3). With soft limits enabled, GRBL then enforces that same envelope once the machine is homed. The full convention is covered in Travel Limits & Bounds Check.

FluidNC has no numbered $ settings — its configuration is a config.yaml file on the controller. GcodePilot generates it from the machine profile (axes and motors, pins, spindle, user I/O, probe, THC tuning) and on connect runs a semantic diff against the file actually on the device. A real value difference prompts a two-way sync: Use JetCad3 config pushes the generated file and reboots, or Import from controller autofills the machine profile from the device. Settings JetCad3 doesn't model are left alone, so a hand-edited section never trips a false prompt — and the connection-badge menu can edit the controller's live config.yaml directly or force a push at any time.

A machine's User I/O section lists its inputs and outputs separately, and each row carries the P number your G-code addresses it by: M62 P0 fires the torch, M66 P1 waits on arc-OK. Inputs and outputs are numbered independently, so input P1 and output P1 are different pins — that's the FluidNC convention, and both controllers follow it. Because they do, the bundled fire_torch and torch_off subroutines run unchanged on a FluidNC or a JetFlight machine: there's no second copy to keep in step, and a table can move between controllers without its G-code being rewritten. Give a pin a number that's already taken in its list and the dialog says so immediately, rather than leaving it ambiguous which relay a command would click.

Each pin also carries a role — torch, arc-OK, floating head, ohmic, breakaway, arc voltage — which is what drives touch-off, the readouts beside the DRO and the arc-OK gate. Inputs add a debounce time and an active-low setting for the usual normally-closed-to-ground switch wiring.

Any user input or output can be pinned to the GcodePilot toolbar as a live indicator: tick Toolbar indicator on that pin in the machine's User I/O section and give it a short name. Inputs light yellow, outputs green, and the controller itself reports the state — so an output that the firmware drops on a reset or an alarm goes dark on screen at the same moment it goes dark in the panel.

Output badges are switches as well as lamps. With the machine sitting Idle, click one to drive that output and JetCad3 asks you to confirm first; hold Shift and the click switches it straight away, which is what you want when you're flipping a clamp valve or a work light back and forth while setting up. Badges stop accepting clicks while a program is running — hover one and the tooltip tells you its state, what a click will do, and why it's inert if it isn't currently switchable. Inputs are read-only, since a physical input is driven by the machine, not by you.

JetFlight machines get a full Homing node in Machine Config: enable the cycle, set the fast seek and slow re-approach rates, pull-off distance, switch settle time, and one- or two-pass approach — all in your machine's units. Each axis is assigned a cycle group (groups home in order; axes in the same group home together), a direction, and the machine coordinate established at its switch. A Run Homing Cycle button tests it on a connected machine without leaving the dialog.

Switch wiring is per motor, not per axis, and you pick it right there: each motor gets a switch input chosen from your configured inputs, plus its polarity. On a dual-motor gantry each motor stops on its own switch, which is what squares the gantry. Any input can serve any motor, and two motors may share one switch as long as they home in different cycles — that's what lets a table with only two switch inputs home each axis in turn and still square. The one arrangement that can't work is two motors homing in the same cycle on the same switch: both would stop on the first trip and the gantry would never square. The dialog flags that as you configure it, and the controller refuses the cycle rather than homing crooked.

The DRO counts while the machine seeks. Each homing axis starts at zero and counts as it travels — the convention you'll know from LinuxCNC — and machine coordinates re-zero when the cycle finishes. A touch-off shows real machine position the whole way down.

Stop (or Escape) ends a homing or touch-off cycle. The machine decelerates at its own acceleration limit rather than stopping dead, and a stopped homing cycle simply leaves the machine unhomed — it isn't reported as a failure, because you asked for it.

Editing a connected JetFlight machine's configuration takes effect the moment you press OK — no disconnect/reconnect. Tuning changes (speeds, accelerations, cornering, travel limits, homing rates) apply seamlessly: position, work offsets, and the homed state are all preserved. Hardware changes (pins, motors, wiring) briefly cycle the board link on their own — a one- or two-second badge blip — and then light the NOT HOMED badge, exactly like a fresh power-up, since rewiring invalidates machine coordinates. A change made while a program is running waits and applies itself when the run ends; it never touches a machine mid-cut.