Ein Abend Fehlersuche an einem 3D-Drucker, und die eigentliche Ausbeute sind nicht die Einstellungen, sondern die Irrtümer auf dem Weg dorthin. Zwei davon sind ausführlich genug, dass sie eigene Abschnitte verdienen – der Rest folgt als Liste am Ende.
Der CAN-Ausfall, der keiner war
Mitten in der Fehlersuche fing das Toolboard an, sich zu verabschieden: Lost communication with MCU 'toolboard0', achtmal über mehrere Betriebstage. Die erste Sendewarteschlange, die ich mir ansah, bestand zu 96 von 100 Nachrichten aus neopixel_update und neopixel_send – die LED-Effekte am Werkzeugkopf liefen mit 24 Bildern pro Sekunde, also 48 Nachrichten pro Sekunde über den CAN-Bus.
Das sah nach einem klaren Fall aus. Ich senkte die Bildraten auf 2 (für Effekte, die einen Wert anzeigen) und 6 (für bewegte Effekte). Die Buslast fiel von rund 46 auf 21,6 Nachrichten pro Sekunde.
Beim nächsten Homing starb das Board wieder.
Erst da habe ich richtig hingesehen – und dabei zuerst noch die falsche Statistik erwischt. Klipper wirft beim Abschalten die Zähler aller MCUs nacheinander aus; ich hatte die letzte im Log genommen, die des Raspberry Pi, und daraus geschlossen, die Verbindung sei kerngesund gewesen. Die Zeilen des Toolboards standen vierhundert Zeilen weiter oben und sagten etwas anderes.
| Zeitpunkt | Nachrichten bis dahin | offen | retransmit | Heizer | LED-Rate |
|---|---|---|---|---|---|
| t = 3088 | 111 667 | 7 | 227 B | aus | 44/s |
| t = 12685 | 135 232 | 7 | 209 B | aus | 44/s |
| t = 16408 | 3 234 | 7 | 239 B | Bett 100 % | 44/s |
| t = 17133 | 2 369 | 7 | 221 B | Bett 100 % | 6/s |
Immer genau sieben unbeantwortete Nachrichten, immer rund 220 Byte Wiederholung. Die Wiederholungen sammeln sich also nicht über die Laufzeit an – sie entstehen alle in den letzten Sekunden. Einmal überlebte die Verbindung 135 232 Nachrichten, einmal starb sie nach 2 369. Der letzte Ausfall passierte bei bereits halbierter LED-Rate.
Und dann die Zeile, die alles entscheidet – der CAN-Controller auf dem Toolboard selbst:
canbus_status rx_error=0 tx_error=0 tx_retries=0 canbus_bus_state=activeEin überlasteter Bus wird langsam, verliert aber keine Verbindung geräuschlos. Wenn der Controller „Bus aktiv, keine Fehler" meldet und der Host trotzdem fünf Sekunden nichts hört, hat nicht die Verbindung versagt – das Board war weg.
Das ist keine Bandbreitenfrage, sondern ein Reboot oder ein Hänger: kurzer Spannungseinbruch auf der 24-V-Zuleitung, ein Crimp im Schleppkabel, oder ein Firmware-Fehler. Das Toolboard läuft auf v0.13.0-255, Host und die beiden anderen MCUs auf -743 – rund fünfhundert Commits Unterschied. Die Ursache ist zum Zeitpunkt dieses Artikels noch nicht abschließend geklärt.
Die LED-Reduzierung habe ich trotzdem behalten. Sie hat die Buslast halbiert, das schadet nicht. Sie war nur nicht die Ursache – sie war das, was sich staut, wenn ein Board stumm wird.
Anzeige · Affiliate-Link – kaufst du darüber, erhalte ich ggf. eine Provision. Für dich ändert sich am Preis nichts.
Konfiguration ohne Wirkung
Auf der Suche nach einem unerklärlichen Z-Offset fand ich in lineux/btc.cfg eine Zeile, die alles erklärt hätte:
SET_VELOCITY_LIMIT ACCEL={move_accel} # move_accel nirgends definiert -> 1000Sie stand in einem Toolchanger-Einstiegspunkt, wurde nirgends zurückgenommen, und war die einzige SET_VELOCITY_LIMIT-Anweisung im gesamten Konfigurationsverzeichnis. Für mich war damit klar: Der Drucker läuft ab jedem Druckbeginn auf 1000 mm/s² statt 4900.
Das war falsch. Die Datei wird nie geladen – printer.cfg bindet den ganzen lineux/-Ordner nicht ein. Es sind Reste eines Toolchangers, den es nicht mehr gibt.
Ärgerlich ist weniger der Irrtum als dass ich das Gegenteil vorher schon gemessen hatte: toolhead.max_accel stand nach einem vollen Homing-Durchlauf auf 4900. Diese Zahl hätte die Behauptung sofort widerlegt.
Konfigurationsdateien im Ordner sind kein Beweis dafür, dass sie wirken. Die einzige belastbare Quelle ist die laufende Instanz – bei Klipper printer.configfile.config über die Moonraker-API. Dort standen die Toolchanger-Sektionen schlicht nicht drin.
Die übrigen fünf
Ich habe zwei Dinge gleichzeitig geändert
Bei einem Druck wurden Geometrie und Betttemperatur (70 auf 60 °C) zusammen verändert. Danach war nicht mehr zuzuordnen, was gewirkt hatte. Bei Druckversuchen, die je über eine Stunde dauern, ist das besonders teuer.
Ich habe meiner eigenen Messung nicht geglaubt
Der gemessene Wert max_accel = 4900 stand da, bevor ich annahm, ein Makro drossle auf 1000. Wenn Messung und Hypothese sich widersprechen, ist die Hypothese fällig – nicht die Messung.
Ich habe die Richtung geraten, statt den Mechanismus zu suchen
Die erste Schicht saß zu locker, also wollte ich mit einem Babystep nach unten gegensteuern, mit einem plausiblen Startwert. Erst dann fiel mir auf, dass ich den angezeigten Offset von +0,1014 mm nie eingestellt hatte – woher kam er also? Genau diese Frage führte zur richtigen Korrektur, die dreimal größer war als mein geschätzter Startwert. Eine Zahl, die man nicht erklären kann, ist kein Detail, das man wegjustiert.
Ich hätte eine Änderung ausgeliefert, die nichts tut
Ein adaptives Bed Mesh war fertig gebaut, in allen Randfällen trockengetestet und syntaktisch einwandfrei. Es wäre wirkungslos geblieben, weil ein überschreibendes Makro die Parameter verwarf und dabei ok zurückmeldete. Nur der Testlauf auf der echten Maschine hat es gezeigt – kein Lesen des eigenen Codes hätte das je gefunden, denn der eigene Code war richtig.
Ich hätte fast eine Toleranz gesetzt, die Drucke abgebrochen hätte
Für die Portalausrichtung wollte ich zunächst 7,5 µm Restspanne ansetzen. Erst Klippers eigener Kommentar in der Konfigurationsdatei – „if you are probing more points than steppers…" – machte klar, dass vier Messpunkte mit drei Motoren einen Rest hinterlassen, den keine Neigung wegnimmt. Gemessen sind es 14 bis 26 µm. Mit meinem ersten Wert wäre Z_TILT_ADJUST nach fünf Versuchen mit einem Fehler ausgestiegen, mitten im Druckstart.
Was in all diesen Fällen half, war dasselbe: eine Zahl suchen, die die eigene Erklärung widerlegen könnte, und nicht eine, die sie stützt. Der CAN-Fall ist dafür das sauberste Beispiel – die LED-Hypothese war plausibel, gut belegt und trotzdem falsch. Widerlegt hat sie nicht ein besseres Argument, sondern eine einzelne Zeile mit vier Nullen darin.
Wo aber keine widerlegende Zahl zu haben ist, hilft nur Ausführen. Die beiden letzten Punkte konnte kein noch so sorgfältiges Lesen finden – beim Wrapper war der eigene Code korrekt, und die Restspanne der Portalausrichtung ist eine Eigenschaft dieser Maschine, die in keiner Datei steht. Beide sind erst aufgefallen, als etwas lief.
Drucker: HevORT mit BTT OctopusPro, Toolboard über CAN, Klipper v0.13.0-743 (Toolboard: -255), BTT Eddy USB. Slicer: OrcaSlicer 2.4.2.
Alle Zahlen stammen aus klippy.log und der Moonraker-API dieser Maschine. Die Ursache der Toolboard-Ausfälle ist weiterhin offen.
Diese Serie
Ein Abend Fehlersuche an einem Kettenoktopus hat vier Themen ergeben, die sich unabhängig voneinander lesen lassen:
- Klipper Bed Mesh: fehlender Nullbezug kostet 0,14 mm
- Print-in-Place: Schichthöhe entscheidet über die Gelenke
- OrcaSlicer & Klipper: 34 % weniger Druckzeit
- Sieben Fehlschlüsse bei der Klipper-Fehlersuche – dieser Artikel
Anzeige · Affiliate-Link – kaufst du darüber, erhalte ich ggf. eine Provision. Für dich ändert sich am Preis nichts.
