Skip to content
Wiki
Main site

Extruder board (extruder_board MCU)

The extruder_board is a custom Ginger Additive board — named Ginger.Extruder on the assembly drawings — carrying an Arduino Nano (ATmega328P) flashed with Klipper, mounted inside the panel box (the green PCB). It is a second Klipper MCU alongside the main Octopus board.

It has a twin. The panel box also holds Ginger.Feeding, a board of the same family carrying the same Arduino Nano, which runs the auto feeding system. The two are not interchangeable in service: they run entirely different firmware, and only this one is wired to the Raspberry Pi. See Flashing the control boards.

What the extruder_board does

Section titled “What the extruder_board does”

The extruder_board handles only the following:

  • The 3 heater relays (one per heating zone) — and it passes the 220V through to the heater bands
  • The servo that actuates the bed-leveling probe
  • The part cooling fan
  • The feeder switch and its status output
  • The buzzer

Architecture

Section titled “Architecture”
Raspberry Pi (host, runs Klipper + Mainsail)
    ├── USB_2 ── mcu (Octopus Pro v1.1, STM32H723) — motion, all NTC sensing, bed heater output
    └── USB_1 ── extruder_board (Ginger.Extruder, Arduino Nano) — 3 zone heater relays + 220V,
                     probe servo, part fan, feeder switch, buzzer
                         │
                         └── GCOM ── Ginger.Feeding (Arduino Nano) — vacuum relay, level probe, buzzer
                                     no USB to the Pi; Klipper cannot see it

The feeder board hangs off the extruder_board, not off the Pi. That is why the FEEDER toggle works through Klipper even though Klipper has no idea the feeding board exists — the signal travels the short GCOM link between the two Ginger boards.

Both MCUs connect to the Raspberry Pi over USB. The USB plugs into the port on the panel box that routes to the Raspberry Pi. Both MCUs must be running for the printer to operate.

Not the same as the extruder breakout

Section titled “Not the same as the extruder breakout”

Common error: “Lost communication with MCU ‘extruder_board’”

Section titled “Common error: “Lost communication with MCU ‘extruder_board’””

If the board is not connected, Klipper raises this error. There are two cases:

  • Hardware (most common): the USB connection has come loose or failed. Re-seat the USB at the panel box port and do a firmware restart.
  • Software: the serial ID is wrong in printer.cfg (the [mcu extruder_board] serial: path no longer matches the device). Correct the serial path.

See Klipper MCU communication lost for the full diagnosis guide.

Other contributing factors:

  • Voltage dip on the supply (e.g. vacuum pump startup on the same circuit)
  • Extruder_board firmware not matching the Klipper host version — this one is a flashing job: Flashing the control boards

Firmware version

Section titled “Firmware version”

The extruder_board runs its own Klipper binary, in its own flash. Two things follow from that, and both are easy to get wrong:

  • The Update Manager does not flash it. Updating the klipper row replaces the Klipper host software on the Raspberry Pi; the board keeps the binary it already has. Neither does writing a new SD card
  • It therefore only needs reflashing when a host update crosses a protocol change and Klipper refuses to start, saying the MCU firmware does not match

See Flashing the control boards — including why it is almost never the fix you want.

Checking board status

Section titled “Checking board status”

In Mainsail Console:

STATUS

Output shows both mcu and extruder_board — both should show Connected. If extruder_board shows Disconnected or is absent: check the USB connection (hardware) or the serial: path in printer.cfg (software), then do a firmware restart.

Section titled “Related notes”