klipper-multiboard

Eine eigene Firmware-Config pro Board — statt der einen .config, die Klipper bei jedem make menuconfig überschreibt.

English version

---

Das Problem

Klipper legt seine Kconfig-Auswahl in ~/klipper/.config ab und baut nach ~/klipper/out/. Beides ist einmal vorhanden. Wer mehr als einen MCU betreibt — Mainboard plus Toolhead-Boards, ein Multi-Toolhead-Setup, eine zweite Maschine am selben Host — klickt sich nach jedem git pull für jedes Board erneut durch menuconfig und hofft, dabei nichts zu vergessen.

Das ist der eigentliche Ärger: nicht das Bauen, sondern das Reproduzieren der Auswahl.

Die Lösung

Klippers Makefile kann beides umbiegen:

KCONFIG_CONFIG   # Pfad der Config-Datei   (Standard: ~/klipper/.config)
OUT              # Build-Verzeichnis       (Standard: out/, Slash am Ende!)

Damit bekommt jedes Board seine eigene, dauerhaft gespeicherte Config und sein eigenes Build-Verzeichnis. Ein Update ist danach:

cd ~/klipper && git pull
./klipper-build.sh flash all

menuconfig brauchst du nur noch, wenn sich an der Hardware etwas ändert. Neue Kconfig-Optionen aus dem Update übernimmt olddefconfig automatisch.

Configs und Builds liegen außerhalb von ~/klipper. Das Repo bleibt sauber, git pull läuft nie in einen Konflikt.

Was das Script sonst noch macht

• Flasht über Katapult statt über make flash und umgeht damit einen Timing-Fehler in Klippers flash_usb.py, der sich als No DFU capable USB device available meldet, obwohl das Board einwandfrei im Bootloader sitzt. Details in der Anleitung.
• Ein Board-Typ, beliebig viele Geräte. Sechs baugleiche Toolhead-Boards teilen sich eine Config und eine Firmware. Die Zuordnung läuft über die Chip-ID im by-id-Pfad — der einzige Schlüssel, der bei identischen Boards eindeutig bleibt.
• Der Klipper-Dienst kommt immer zurück. Auch wenn ein Board scheitert oder du mit Strg-C abbrichst. Ein fehlgeschlagenes Board bricht nicht den ganzen Lauf ab, sondern wird am Ende gesammelt gemeldet.
• status zeigt Versions-Drift. Welche Version ist gebaut, welche liegt auf welchem Chip, und welche MCUs am Host verwaltet das Script gar nicht.

Installation

git clone https://github.com/Droidenwerkstatt/klipper-multiboard-flash.git ~/klipper-multiboard
chmod +x ~/klipper-multiboard/klipper-build.sh

Voraussetzungen: Klipper unter ~/klipper, bash, python3 mit pyserial (hat jede Klipper-Installation), und für den Katapult-Weg ~/klipper/lib/katapult/flashtool.py — das bringt Klipper selbst mit.

Schnellstart

cd ~/klipper-multiboard

# 1. Welche MCUs hängen am Host?
./klipper-build.sh usb

# 2. Config für ein Board anlegen (öffnet menuconfig)
./klipper-build.sh new octopus

# 3. Geräte eintragen
echo /dev/serial/by-id/usb-Klipper_stm32f446xx_XXXX-if00 \
     > ~/klipper_boards/octopus.devices

# 4. Erstmal nur zuschauen
DRY_RUN=1 ./klipper-build.sh flash octopus

# 5. Ernst machen
./klipper-build.sh flash octopus

Die ausführliche Fassung steht in der Anleitung.

Kommandos

Kommando	Wirkung
new <board>	Neue Config anlegen (öffnet menuconfig)
menu <board>	Bestehende Config ändern
build <board>|all	olddefconfig + Build
flash <board>|all	Build + auf alle Geräte des Boards flashen
usb	Angeschlossene USB-MCUs auflisten
list	Bekannte Boards und Gerätezahl
status	Host- vs. Firmware-Version je Chip
clean <board>|all	Build-Verzeichnis löschen (Configs bleiben)
version	Script-Version

Umgebungsvariablen

Variable	Standard	Wirkung
KLIPPER_DIR	~/klipper	Klipper-Quellverzeichnis
CONFIG_DIR	~/klipper_boards	Wo die .config-Dateien liegen
BUILD_DIR	~/klipper_builds	Wo gebaut wird
KLIPPER_SERVICE	klipper	systemd-Dienst, der zum Flashen pausiert
FLASH_METHOD	auto	auto | katapult | make
BOOTLOADER_WAIT	20	Sekunden Wartezeit auf den Bootloader
DRY_RUN	0	1 = nichts flashen, nur zeigen

Ablage

~/klipper_boards/
    octopus.config       Kconfig-Auswahl        <- sichern / versionieren
    octopus.devices      by-id-Pfade
    nhk36.config
    nhk36.devices
~/klipper_builds/
    octopus/klipper.bin  Build-Ausgabe
    octopus/.flashed     was wann auf welchen Chip ging

Die .config-Dateien sind das Wertvolle. Sie in ein eigenes Git zu legen — zusammen mit printer.cfg — ist die halbe Miete für einen reproduzierbaren Drucker.

Getestet mit

BigTreeTech Octopus (STM32F446, Katapult über USB) und LDO Nitehawk-36 (RP2040, Katapult über USB) an einem Voron 2.4 mit Stealthchanger.

Der Ansatz ist nicht hardwarespezifisch: KCONFIG_CONFIG und OUT gelten für jedes von Klipper unterstützte Board. Rückmeldungen zu anderer Hardware sind willkommen — besonders zu CAN-Setups, für die es den .flash-Haken gibt, der bisher wenig Praxis gesehen hat.

Lizenz

MIT — siehe LICENSE.

Klipper und Katapult sind eigenständige Projekte unter GPLv3. Dieses Script ruft sie auf, enthält aber keinen Code daraus.