Mein HevORT schaltet sich nach einer Viertelstunde Leerlauf selbst ab. Bis zu einem bestimmten Tag kam er danach auch zuverlässig wieder hoch. Dann nicht mehr: Nach jedem Wiedereinschalten der 24 V blieb Klipper im Startup hängen, und das Toolboard meldete sich erst, wenn ich auf seinen RESET-Taster drückte. Ein Kaltstart am Netzschalter dagegen funktionierte.
Die Ursache saß nicht in der Firmware und nicht auf dem CAN-Bus, sondern in einer Leitung, die ich selbst gelegt hatte. Auf dem Weg dorthin habe ich sechs Hypothesen und einen untauglichen Test ausgeschlossen – und die sind der eigentlich interessante Teil.
Der Aufbau
- CoreXY-Drucker (HevORT) mit Klipper
- Mainboard: BTT Octopus
- Toolboard: BTT EBB36 (STM32G0B1) am CAN-Bus, angebunden über einen U2C-Adapter
- Eddy-Sonde an USB, Raspberry Pi 4 als Host
- Moonraker schaltet das 24-V-Netzteil über einen GPIO des Pi; das Relais sitzt auf der Netzseite, nicht auf der DC-Seite.
Der relevante Teil der moonraker.conf:
[power <gerätename>]
type: gpio
pin: gpio24
bound_services: klipper
restart_klipper_when_powered: TrueUnd ein Makro, das nach 15 Minuten Leerlauf die 24 V abschaltet:
UPDATE_DELAYED_GCODE ID=delayed_printer_off DURATION=900Wie es sich zeigte
„Bis heute ging es immer“ – das war mein Ausgangspunkt. Seitdem dasselbe Bild nach jedem 24-V-Zyklus:
- Klipper bleibt beim Start hängen.
- Das Toolboard ist nicht erreichbar.
- Erst nach Druck auf RESET am EBB36 meldet es sich.
- Wird stattdessen der ganze Drucker am Netzschalter aus- und wieder eingeschaltet, startet alles normal.
Was ich untersucht habe
Der Blick auf den Bus
Zuerst die üblichen Abfragen auf dem Pi: Welche Knoten antworten, was sagt Katapult, wie sieht das CAN-Interface aus?
<klipper-pfad>/scripts/canbus_query.py can0
<katapult-pfad>/scripts/flashtool.py -q
ip -details -statistics link show can0Im Hängezustand lieferten die Abfragen nichts. Das sah zunächst dramatisch aus, ist aber – dazu gleich mehr – das normale Verhalten eines Knotens, der bereits eine Node-ID zugewiesen bekommen hat.
Was hat sich geändert?
Von can0 und moonraker.conf hatte ich Sicherungen, also habe ich einen Git-Diff gegen den aktuellen Stand gemacht. Neu war nur eine Zeile: bound_services: klipper. Außerdem fiel auf, dass restart-ms am laufenden Interface auf 0 stand, in der Konfigurationsdatei aber auf 100.
Eine Messreihe statt Bauchgefühl
Statt nur einzelne Versuche zu machen, habe ich den Zyklus ferngesteuert über die Power-API von Moonraker gefahren und danach jeweils über printer/info abgefragt, ob Klipper ready meldet:
| Durchgang | Bedingung | 24 V aus | Ergebnis |
|---|---|---|---|
| 1 | can0 down | 15 s | kam hoch |
| 2 | Gegenprobe: can0 oben | 15 s | kam hoch |
| 3–5 | – | je 12 s | alle drei gescheitert |
| 6 | aus dem Hängezustand | 60 s | gescheitert |
In den Quellcode
Um die Firmware- und Protokoll-Hypothesen sauber zu prüfen, habe ich beide Seiten gelesen:
- Firmware:
src/generic/canserial.cundsrc/stm32/fdcan.c. Dort stehtcan_filter(0, CANBUS_ID_ADMIN)– der Admin-Kanal bleibt also immer im Hardwarefilter. - Host:
klippy/serialhdl.py. Klipper wiederholtSET_NODEIDan die UUID des Boards 90 Sekunden lang.
Der entscheidende Hinweis
Der kam nicht aus einem Log, sondern vom Hinsehen: Bei abgeschalteten 24 V leuchteten die LEDs am Werkzeugkopf weiter – und eine LED auf dem EBB36 selbst auch.
Die Irrwege
Bevor ich bei den LEDs ankam, habe ich eine ganze Reihe plausibler Erklärungen verfolgt. Jede davon ließ sich mit einer konkreten Beobachtung widerlegen.
1. Katapult hängt stumm im Bootloader
Die Idee: Durch das schnelle Aus und Ein erkennt Katapult mit CONFIG_ENABLE_DOUBLE_RESET einen Doppel-Reset und bleibt im Bootloader, statt Klipper zu starten.
Widerlegt: Nach einem Reset meldete die Abfrage Detected UUID: …, Application: Klipper. Auf dem Board lief also Klipper. Die leeren Antworten davor waren kein Zeichen für einen hängenden Bootloader, sondern das normale Verhalten eines Knotens mit zugewiesener Node-ID – der taucht in der Suche nach unzugewiesenen Knoten schlicht nicht auf.
2. Rückspeisung über den getriebenen CAN-Bus
Die Idee: Solange can0 am Pi oben ist, treibt der U2C die Busleitungen und hält das Toolboard über die CAN-Pegel halb am Leben.
Widerlegt durch die Gegenprobe in der Messreihe: Mit can0 oben kam das Board genauso hoch wie mit can0 unten.
3. Restladung – die Aus-Zeit ist zu kurz
Die Idee: Die Kondensatoren entladen sich in 12 Sekunden nicht weit genug.
Widerlegt: Aus dem Hängezustand half auch eine volle Minute ohne 24 V nicht.
4. Alte Node-ID oder Hardwarefilter blockieren die Wiederverbindung
Die Idee: Das Board behält eine veraltete Node-ID oder filtert die Admin-Nachrichten des Hosts aus.
Widerlegt durch den Quellcode beider Seiten: Der Admin-Kanal bleibt in der Firmware immer im Filter, und der Host wiederholt SET_NODEID 90 Sekunden lang an die UUID. Ein laufendes Klipper auf dem Board hätte das gehört.
5. Prellendes Relais auf der DC-Seite
Ausgeschlossen: Das Relais schaltet auf der Netzseite.
6. Fehlende oder falsche 120-Ω-Terminierung
Das war meine eigene Vermutung.
Widerlegt: bus-errors 0, und das Verhalten war binär – entweder kam das Board hoch oder gar nicht. Eine schlechte Terminierung äußert sich in Fehlern auf dem Bus, nicht in einem sauberen Entweder-oder.
7. Ein Test, der nichts unterscheiden konnte
Zwischendurch gab es noch einen ACK-Test mit cansend und candump. Im Nachhinein war er schlecht entworfen: Er hätte bei jeder der offenen Hypothesen dasselbe Ergebnis geliefert. Ein Test, der keine Hypothese ausschließen kann, kostet nur Zeit.
Die Ursache
Ich hatte irgendwann zusätzlich 5 V auf die 5-V-Pins des Octopus gegeben – „um die Spannung zu stabilisieren“.
Bei abgeschaltetem 24-V-Netzteil passiert damit Folgendes: Der 5-V-Abwärtswandler auf dem Octopus wandelt normalerweise 24 V nach 5 V. Liegen aber von außen 5 V an seinem Ausgang und fehlen die 24 V am Eingang, leitet die Body-Diode des oberen Schalttransistors rückwärts. Die 24-V-Schiene wird dadurch auf einige Volt angehoben – genug, um nicht null zu sein. Diese Spannung gelangt über die Nabelschnur zum Toolboard.
Die Größenordnung von rund 4,4 V auf der 24-V-Schiene ist eine Abschätzung, keine Messung.
Damit wurde der STM32 auf dem EBB36 nie wirklich stromlos. Ohne echten Spannungsverlust gibt es keinen Power-on-Reset – das Board kam beim Wiedereinschalten der 24 V nicht sauber neu hoch und blieb in einem Zustand hängen, aus dem nur der RESET-Taster half.
Die weiterleuchtenden LEDs waren genau dieses Symptom: Strom, wo keiner sein sollte.
Die Lösung
- Die externe 5-V-Einspeisung am Octopus entfernt.
- Die 15-Minuten-Abschaltung wieder aktiviert (Sicherung:
printer.cfg.vor-idleon).
Keine Firmware-Änderung, keine neue Bus-Konfiguration.
Der Nachweis
Derselbe Test wie in der Messreihe: drei Durchgänge, jeweils 12 Sekunden ohne 24 V, danach Abfrage über die Moonraker-API.
- Vorher: 0 von 3
- Nachher: 3 von 3, jeweils nach 8 Sekunden
ready
Was offen bleibt
- Flashen über CAN scheitert weiterhin am
CONNECT– bei 1 Mbit, 500 kbit und 250 kbit. Mein Verdacht geht in Richtung USB-Katapult. - Sporadische Toolboard-Ausfälle im laufenden Betrieb gibt es weiterhin. Die sind ein anderes Problem und mit dieser Lösung nicht erledigt; meine aktuelle Vermutung ist das Board selbst.
- Ob die Rückspeisung über Wochen den Spannungswandler des Toolboards beschädigt hat, weiß ich nicht. Das ist bisher nur eine Vermutung.
Was ich daraus mitnehme
Wenn ein Board nach dem Abschalten nicht sauber neu startet, ein Reset-Taster aber hilft, ist die erste Frage nicht die Firmware, sondern: Wird das Board überhaupt stromlos? Eine LED, die bei abgeschalteter Versorgung weiterleuchtet, ist ein lauter Hinweis – man muss nur hinsehen.
Und zweitens: Jede zusätzliche Einspeisung „zur Stabilisierung“ ist ein zweiter Pfad, über den Strom auch in die falsche Richtung fließen kann. Ein Abwärtswandler ist keine Diode in Sperrrichtung.
HevORT-CoreXY, BTT Octopus, BTT EBB36 (STM32G0B1) über CAN mit U2C, BTT Eddy an USB, Raspberry Pi 4, Klipper mit Moonraker-Power-Steuerung über GPIO, Netzteil-Relais auf der Netzseite.
Anzeige · Affiliate-Link – kaufst du darüber, erhalte ich ggf. eine Provision. Für dich ändert sich am Preis nichts.
