Skip to content

cnc_shared

The cnc_shared module (main/display/cnc/) is the shared CNC user-interface layer of the pendant firmware. It implements every screen and component that is common to all three supported CNC firmware targets — FluidNC, grblHAL, and grbl — so that the firmware-specific modules (fluidnc_module, grbl_module, grblhal_module) only have to supply their protocol-specific behavior (status parsing, command dialects, file/probe workflows).

It contains:

  • The application screens (screens/) — the operator-facing UI: jogging, real-time status, macros, settings, information, and firmware status
  • The firmware status component (components/firmware_status.*) — the shared connection/state indicator fed by the real-time value system
  • Shared definitions — esp3d_firmware_states.h (the canonical machine-state enumeration mapped to colors/labels) and esp3d_system_translations_defs.inc (screen translations)
  • Per-resolution resources (res_320_240/, res_480_272/, res_480_320/, res_800_480/) — fonts, images, and layout constants for each supported display size

Parent module: UI_Framework_&_Screens — cnc_shared builds on the generic screen framework (ui_core, ui_components) and the reusable components it provides (virtual buttons, circular menu, list menus, message boxes).


state / connection feedback

commands / queries

commands / queries

commands / queries

commands / queries

parsed status reports

firmware-specific modules

fluidnc_module

grbl_module

grblhal_module

main_screen

navigation hub (circular menu)

jog_screen

multi-axis jogging

status_screen

real-time machine status

macros_screen + macro_manager

user G-code macros

settings_screen + settings_list_screen

firmware settings

information_screen

system information

firmware_status component

connection & state indicator


The shared component (components/firmware_status.*) that tracks the connected CNC firmware’s state — connection lifecycle, machine state enumeration (esp3d_firmware_states.h), and the visual state indicator reused across screens. It normalizes what each firmware target reports so the UI reacts identically whether the machine runs FluidNC, grblHAL, or grbl.

The operator’s live view of the machine: axis positions (work/machine coordinates), feed and spindle overrides, active state, and running job progress. It subscribes to the real-time value system, so it updates continuously as status reports stream in from the firmware — no polling loop in the UI itself.

Multi-axis jogging interface: axis selection, jog distance steps, continuous vs. incremental moves, and rate controls. Designed to be driven both by touch (virtual buttons) and by the physical rotary encoder/buttons on boards that have them, with on-screen input emulation on touch-only boards.

User-defined G-code macros: macro_manager.* handles storage and execution of named macro sequences, and macros_screen.* provides the list-menu UI to browse, launch, and manage them. Macros are sent to the firmware through the same command pipeline as manual input.

Firmware settings management: settings_screen.* for individual setting editing (with validation) and settings_list_screen.* for browsing the full settings table exposed by the firmware (e.g. via the ESP400 command on ESP3D-style targets). Values are read on screen entry and written back through the active transport.

The navigation backbone: main_screen.* — the central hub shown after boot, from which every feature screen is reached (circular menu) — and information_screen.*, which reports system and firmware information (versions, IP addresses, build options).


Relationship with the firmware-specific modules

Section titled “Relationship with the firmware-specific modules”

cnc_shared deliberately contains no protocol logic. Command formatting, status-report parsing, file transfer, probing, and tool-change workflows live in the per-target modules:

The shared screens emit commands and consume status through the common G-code handler and client transport layers (see gcode_host and Communication_Transports), which is what allows one screen implementation to serve all three firmware dialects.