# HelixScreen: a native touchscreen UI for Klipper printers

> HelixScreen is a C++17 touchscreen interface for Klipper 3D printers built on LVGL 9 with XML layouts, sized to run on the printer's own SoC or a spare Raspberry Pi and to reach the printer over Moonraker.

**prestonbrown/helixscreen** — A modern, lightweight touchscreen interface for Klipper 3D printers

- Repository: https://github.com/prestonbrown/helixscreen
- Stars: 371 · Forks: 74
- Language: C++
- License: GPL-3.0
- Published: 2026-08-27 · Updated: 2026-08-27 · Language: en
- Canonical page: https://hysenlabs.com/projects/prestonbrown-helixscreen

## The interface runs on the printer's own hardware

The starting point is that a Klipper printer can expose bed mesh visualization, input shaper graphs, multi-material management, and print history, yet all of it is normally reached through a browser tab on a phone or laptop. HelixScreen moves that control onto a local touchscreen. It can run directly on the printer's onboard system-on-chip, on a Raspberry Pi, or on any newer board, and it can also run on a separate device, such as a spare Pi, a mini PC, or a desktop, acting as a remote screen that points at the printer's Moonraker instance over the network. That last mode is the interesting one for a floor-standing printer whose screen sits far from the machine, because the display does not have to live on the printer chassis. The project targets Klipper specifically, speaking to Moonraker as the interface layer.

## Memory footprint is the governing constraint

The headline budget is roughly 15MB of RAM on embedded targets and about 75MB of disk, with a few times more on a 64-bit Raspberry Pi but still well under what other touchscreen interfaces consume. The stated comparison puts KlipperScreen at around 50MB of RAM and GuppyScreen in the 15 to 20MB band, while HelixScreen's disk footprint of roughly 75 to 115MB sits above KlipperScreen's ~50MB and GuppyScreen's ~60 to 80MB. The point of the exercise is that a Creality K1 or a Flashforge AD5M can host it without new hardware, and an older Pi in a drawer is enough. A multi-page grid with dozens of widgets, 3D previews, and live graphs is unusual at that budget, which is why the resource figures, not the feature list, are the load-bearing claim.

## XML layouts and reactive bindings replace hand-coded widgets

The UI layer is built on LVGL 9 with a declarative approach: layouts are defined in XML with reactive bindings, rather than assembled in code. The scale is large. There are more than 300 XML layouts, over 30 panels, over 20 overlays, and over 20 modals. The home dashboard is a multi-page grid with drag-to-reposition, edge resize, and a catalog of more than 30 widgets, including temperature graphs, fan arcs, power toggles, camera feeds, an active spool indicator, and favorite macros. Layouts persist per breakpoint, so a rearrangement made for one screen size does not scramble another. Widgets are added or hidden to taste, and the arrangement is remembered rather than reset. This is the technical line that separates the project from the two alternatives in its comparison table: KlipperScreen is Python only, GuppyScreen is C only, and HelixScreen is the one describing the whole surface in XML.

## Seven multi-material backends map to named hardware

Multi-material support is where the printer database meets real fleets of filament hardware, and the project names the backends rather than gesturing at them. There are seven. AFC covers Box Turtle and ViViD. Happy Hare covers ERCF, 3MS, Tradrack, and Night Owl. ACE covers the Anycubic ACE Pro. AD5X IFS and Creality CFS are each supported, as is the Snapmaker U1 with RFID spool recognition. The seventh slot is tool changers, including MedusaHC hotend changers, whose dock sensors and filament feeder are driven on top of klipper-toolchanger. Multi-unit and multi-backend setups are handled, and Spoolman is integrated with a spool creation wizard. That granularity, naming specific feeders and RFID, is what makes the feature list usable rather than aspirational.

## Auto-detection spans 80+ printers and nine languages

The first-run wizard is a guided setup that discovers the printer's capabilities, and a database of more than 80 printer models auto-detects the hardware and configures itself. Display handling is similarly automatic. The layout system detects screen sizes from 480x320 through 1024x600 and also covers ultrawide and portrait panels, with display rotation settable at 0, 90, 180, or 270 degrees. On top of that sit themes, with light and dark modes, 17 presets, a live theme editor, and GPU-accelerated backdrop blur. The interface ships in nine languages, English, German, Spanish, French, Italian, Japanese, Portuguese, Russian, and Chinese, selectable per app. Configuration is versioned and migrated between releases, so a setup survives an upgrade instead of needing to be rebuilt.

## The build refuses to be driven by raw compiler calls

The developer build is opinionated. The top of the Makefile carries a warning to always use make and never to invoke gcc or g++ directly, because the build system handles dependency management for libhv, LVG, and SDL2, detects the platform between macOS and Linux, picks the right core count for parallel builds, and applies patches for multi-display support. The common entry points are minimal:

```bash
make -j
make build
make help
```

Running make with a variable set to 1 prints the full compiler commands. The Makefile also sets a flag that deletes a target when its recipe fails, so a broken link does not leave a truncated artifact that the next build mistakes for up-to-date. Supporting tooling pins clang-format to an exact version so formatting is identical everywhere, and the Python test dependencies include pytest-asyncio, which the Moonraker plugin tests require because they drive async endpoint handlers.

## The release cadence is a stream of 1.1 betas

The project announced its first stable 1.0 release after eleven months and 203 builds from the first commit, and noted at the time that the stable update channel pointed at it. Since then the line has moved into betas: v1.1.0-beta.1, v1.1.0-beta.2, and v1.1.0-beta.3 landed on consecutive days in the last week of September 2026, and the most recent push to the main branch is dated 1 October 2026. Installers are handled through KIAUH, and there is an in-app updater that offers new versions, alongside manual update checks against the project's own releases. That cadence, a stable base with a rolling beta line on top, is the honest reason to treat any specific feature as subject to change between point releases.

## Conclusion

HelixScreen suits Klipper owners who want bed mesh, input shaper graphs, and multi-material control on a local screen instead of a browser tab, and who already own a spare Pi or a printer board with a spare SoC. It is a poor fit for anyone on Marlin or a stock vendor screen, because it speaks Moonraker rather than the printer's own firmware UI. Before installing, confirm your printer is in the 80-model database and matches a tested architecture, read the RAM and disk figures against your board, and expect the 1.1 beta line to still change between releases.

## FAQ

### What is HelixScreen?

A touchscreen interface for Klipper 3D printers written in C++17 on LVGL 9 with declarative XML layouts, which connects to a printer's Moonraker and can run on the printer's own board or on a separate device over the network.

### What hardware does HelixScreen run on?

It is listed as tested on Raspberry Pi 3, 4, 5, CM4 and Zero 2 W, BTT Pad and CB boards, Creality K1 and K2 series units, the Creality Sonic Pad, and Flashforge AD5M models, across aarch64, armhf, armv7 and MIPS32 architectures.

### How much memory does HelixScreen need?

The stated budget is about 15MB of RAM on embedded targets and about 75MB of disk, rising to a few times more on a 64-bit Raspberry Pi, which is still well under what other touchscreen interfaces use.

### Which multi-material systems does HelixScreen support?

Seven backends: AFC, Happy Hare, the Anycubic ACE, AD5X IFS, Creality CFS, the Snapmaker U1 with RFID spool recognition, and tool changers including MedusaHC hotend changers, with Spoolman integration on top.

## Sources

- [Official README](https://github.com/prestonbrown/helixscreen#readme)
- [Project repository](https://github.com/prestonbrown/helixscreen)
- [Release notes](https://github.com/prestonbrown/helixscreen/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/prestonbrown-helixscreen