Klipper Architecture / Ecosystem

[Sineos]

Klipper Architecture / Ecosystem

Calling Klipper a 3D printer firmware is not complete to its full extent. In fact it is a 3D printing application with an associated ecosystem.

The following overview shows how the different aspects interact. Only the red boxes is Klipper in its original sense, the other boxes are independent products forming the entire ecosystem.

Klipper Host

• The core of the Klipper environment
• Typically running on a Single Board Computer (SBC), e.g. RPi etc, but runs on basically any Linux machine
• Manages the entire “3D-printing-logic”, like (not comprehensive):
  • Reading the gcode file
  • Creating the steps (path planning) from the gcode taking into account computational intensive features like Pressure Advance or Input Shaping
  • Compressing the generated steps and sending them to the printer-board
  • Reading and reacting upon sensor values from the printer board, e.g. temperature etc.
  • Executing macros
• Interfaces to the rest of the ecosystem

Klipper Firmware

• The Firmware is running on the printer board or on any supported Micro Controller Unit (MCU)
• It connects to the Klipper Host via USB, direct serial connection (UART) or CAN-Bus
• Manages the hardware of the printer or any connected peripherals like sensors etc
• One or multiple Klipper Firmwares can be managed by one Klipper Host process
• The managed Klipper Firmware instances are reflected in the printer.cfg within the [mcu] blocks

Klipper Host MCU

• The above mentioned SBCs, on which the Klipper Host is running, can also act as an MCU. For example one can connect an Accelerometer to the SBC for Input Shaping
• Managing such hardware interfaces is the responsibility of the Klipper Host MCU
• It connects to the Klipper Host over the /tmp/klipper_host_mcu pseudo-tty
• In the printer.cfg this is typically reflected via the [mcu rpi] configuration block

Moonraker

• Moonraker (developed by @Arksine) is a multipurpose interface and information broker process
• Among its capabilities are
  • Providing an interface between User Interfaces (see below) and the Klipper Host
  • Interfaces to other IOT services like MQTT, Home Assistant, GPIO devices, smart sockets etc
  • Distributes update notifications across the ecosystem
  • Distributes announcements across the ecosystem
  • A lot more
• Typically connects to the Klipper Host via the Unix Domain Socket (UDS) /tmp/klippy_uds
  • Can be changed in the moonraker.cfg configuration file
  • Changes need to be reflected in the Klipper service file as well

User Interfaces

• One of the core features of Moonraker is the ability to interface with modern and powerful User Interfaces
• Most common but again not comprehensive are:
  • Mainsail by Mainsail-Crew
  • Fluidd by @Cadriel
  • KlipperScreen by jordanruthe
  • mooncord by eliteSchwein
• These application connect to Moonraker via JSON RPC over Websockets

OctoPrint

• OctoPrint is kind of the veteran among the 3D printer interfaces
• Support in Klipper has been established long before Moonraker and others have been thought of
• While the other User Interfaces can be considered more modern, the support and functionality is very mature and there are a lot of plugins to customize basically every aspect
• OctoPrint connects to the Klipper Host via the pseudo-tty /tmp/printer

Diagram was created with Diagrams.net. Source attached for future convenience: Klipper Architecture.zip (1.9 KB)