Foundations

How JetFlight is structured

Host planning, machine-side timing, native applications, and expandable machine I/O.

JetFlight separates the operator computer from the timing-critical machine controller. The host reads the program, plans the motion, runs the machine application, and sends targets to the controller. The controller generates the physical motion and handles its board-level I/O.

One machine, several layers

1. Operator workflow — JetCad3 with GcodePilot, a native JetFlight HMI, or a custom application.
2. JetFlight runtime — program parsing, trajectory planning, machine state, scripting, and communication.
3. Motion controller — board-specific firmware produces step pulses and handles time-sensitive machine signals.
4. Expansion — non-motion I/O can be added through supported Ethernet or USB devices.

This structure lets the computer run Windows, macOS, or Linux without moving the pulse-generation loop into a real-time host kernel. The host still needs to meet the documented operating and network requirements.

Included with JC3; deployable on its own

JetCad3 distributes JetFlight and uses it for motion simulation. The same runtime can be deployed independently for a native HMI, a headless application, or a dedicated machine control. See JC3 Appliance for full CAD/CAM/control at the machine or an OEM HMI that launches at startup.

JetFlight ships as a single native executable for each supported platform—Windows, macOS, or Linux—with its motion and scripting engines embedded. No separate JavaScript runtime is required. Select the build for the target operating system and architecture; one executable is not interchangeable across operating systems.

Bundled libraries are linked into the runtime where supported by the build. Windows and macOS release checks enforce static SDL linkage; the dedicated Linux appliance flavor is verified as fully statically linked. Normal desktop builds can still rely on operating-system and display libraries. The dedicated JetFlight appliance binary and the full JC3 Appliance OS are different artifacts.

Synchronized spindle beta

The source revision reviewed for the JetCad3 Lathe beta adds measured spindle speed, phase and index state to the same motion engine used for simulation. Feed per revolution, constant surface speed and single-point threading use that feedback rather than a separate animation. The complete Lathe acceptance matrix passed through the real daemon in simulation.

This work is newer than the public JetFlight v1.4.9 download. The matching firmware protocol is merged but has not been physically commissioned on the EZ Path or promoted as a released controller combination. Simulation proof does not establish encoder wiring, output polarity, spindle-drive behavior or cutting performance.

Distributed machines

JetFlight is designed toward more than one controller on the same machine network. A large machine can place a controller near a distant joint and run power plus network to that location. That is the architecture; a multi-controller combination becomes supported only after its boards, firmware, synchronization behavior, and failure handling are published together.

Reviewed 2026-11-06. Confirm the hardware catalog and current published release before connecting a machine.