Mit funktionierender Haftung wurde die Druckzeit interessant. Der Ausgangsstand lag bei 1 h 41 m 21 s. Die Rollenaufschlüsselung zeigte sofort, wo es hingeht:
| Rolle | Zeit | Anteil | mittlerer Fluss |
|---|---|---|---|
| Außenwand | 32 m 53 s | 32,4 % | 4,2 mm³/s |
| nicht extrudierend | 30 m 47 s | 30,4 % | – |
| Innenwand | 20 m 13 s | 19,9 % | 8,4 mm³/s |
| massive Füllung | 10 m 10 s | 10,0 % | 12,5 mm³/s |
| Füllung | 4 m 50 s | 4,8 % | 9,3 mm³/s |
Fast ein Drittel der Zeit wird nichts extrudiert. Bei achtzig getrennten Inseln pro Schicht und 124 Schichten sind das rund neuntausend Verfahrwege. Und die Außenwand lief bei 4,2 mm³/s – ein Bruchteil dessen, was das Hotend kann. Bremse war dort nicht der Fluss, sondern die Geschwindigkeit.
Der teuerste Fund: Z-Hop
Der Blick in die Maschinengrenzen erklärt die dreißig Prozent:
machine_max_acceleration_z: 300 # mm/s^2Die Z-Achse bewegt das Bett und beschleunigt entsprechend träge. Ein Hub von 0,2 mm kostet damit rund eine Zehntelsekunde – nicht wegen der Strecke, sondern wegen Anfahren und Abbremsen. Neuntausend Mal.
| Z-Hop | Gesamtzeit | Aufpreis | Schutz |
|---|---|---|---|
| aus | 3713 s | – | keiner |
| 0,1 mm, Auto | 3950 s | +237 s | halb |
| 0,1 mm, Slope | 3944 s | +231 s | halb |
| 0,2 mm, Slope | 3986 s | +273 s | voll |
„Slope" legt den Hub schräg in die Verfahrbewegung, statt anzuhalten, zu heben, zu fahren und zu senken. Für 42 Sekunden Aufpreis gegenüber dem halben Hub bekommt man die volle Hubhöhe – bei einem Modell aus achtzig losen Kettengliedern ist das die richtige Seite des Handels. Den Z-Hop ganz abzuschalten hätte vier Minuten gebracht und die Düse neuntausendmal über lose Glieder schleifen lassen.
Die Hebel in der Reihenfolge ihrer Wirkung
| Änderung | Ersparnis | Begründung |
|---|---|---|
| Schichthöhe 0,28 → 0,32 | ~12 min | 124 statt 142 Schichten; Gelenke vorher geprüft |
| Außenwand 40 → 100 mm/s | ~7 min | kleine Umfänge von 50 % auf 85 % |
| Fluss 15 → 26 mm³/s | ~5 min | Innenwand war flussbegrenzt, nicht geschwindigkeitsbegrenzt |
| Gyroid → Lightning | 4 m 13 s | direkt gemessen: 273 s → 20 s Füllzeit |
| Z-Hop Auto → Slope | ~2,5 min | Hub in die Verfahrbewegung gelegt |
| Retraktion 30 → 45 mm/s, Schalen 4→3 / 3→2 | ~2 min | – |
Ab einem gewissen Punkt half Geschwindigkeit nicht mehr: Außenwand von 90 auf 130 mm/s brachte 3 % Zeit, die Innenwand wurde sogar minimal langsamer. Bei achtmillimetrigen Tonnen ist die Beschleunigung die Grenze, nicht die Geschwindigkeit – und dann ist Schluss mit Drehen an Zahlen.
Anzeige · Affiliate-Link – kaufst du darüber, erhalte ich ggf. eine Provision. Für dich ändert sich am Preis nichts.
Ich hatte einen Vorbehalt notiert: OrcaSlicer rechnet mit dem Jerk aus dem Maschinenprofil (9 mm/s), Klipper fuhr mit square_corner_velocity: 5 – die reale Zeit müsse also über der geschätzten liegen.
Der Vorbehalt war falsch herum. Die Schätzung lag anderthalb Minuten auf der sicheren Seite. Aus 1 h 41 m sind real 1 h 06 m geworden – 34 % weniger.
Nur messen, wo gedruckt wird
Der Oktopus belegt 120 × 120 mm. Das Mesh tastete 388 × 320 mm ab – also gut zehnmal mehr Fläche, als bedruckt wird, mit 169 Punkten.
Klipper kann das über BED_MESH_CALIBRATE ADAPTIVE=1 selbst herleiten, allerdings nur, wenn die EXCLUDE_OBJECT_DEFINE-Zeilen im G-Code vor dem Startmakro stehen. Das ließ sich ohne Herunterladen der kompletten G-Code-Datei nicht prüfen, also habe ich den Weg gewählt, der nicht von der Reihenfolge abhängt: Der Slicer übergibt die Grundfläche als Parameter, das Makro rechnet daraus Bereich und Punktzahl.
# machine_start_gcode in OrcaSlicer
START_PRINT HOTEND=[nozzle_temperature_initial_layer] BED=[bed_temperature_initial_layer_single] \
MESH_MIN={first_layer_print_min[0]},{first_layer_print_min[1]} \
MESH_MAX={first_layer_print_max[0]},{first_layer_print_max[1]}
# im Makro: Rand, Klemmung auf den konfigurierten Bereich,
# Referenzpunkt immer enthalten, Punktzahl aus der Fläche
{% set m = 5.0 %}
{% set x0 = [[params.MESH_MIN.split(',')[0]|float - m, zx]|min, cfg.mesh_min[0]|float]|max %}
{% set x1 = [[params.MESH_MAX.split(',')[0]|float + m, zx]|max, cfg.mesh_max[0]|float]|min %}
{% set nx = [[(((x1 - x0) / 25.0)|round(0,'ceil')|int) + 1, 3]|max, cfg.probe_count[0]]|min %}
BED_MESH_CALIBRATE MESH_MIN={x0},{y0} MESH_MAX={x1},{y1} PROBE_COUNT={nx},{ny}Wichtig ist der Teil, der leicht vergessen wird: Nur MESH_MIN/MESH_MAX zu setzen bringt nichts – Klipper misst dann weiterhin 13×13 Punkte, nur enger beieinander. Die Punktzahl muss mit.
| Fall | Ergebnis | Schutz |
|---|---|---|
| Objekt mittig | 7×7 = 49 Punkte | – |
| Teil in der Ecke | 9×6 = 54 | Bereich bis zum Referenzpunkt aufgezogen |
| Teil unter mesh_min y | 6×6 = 36 | auf 84 geklemmt, kein Klipper-Fehler |
| Teil größer als das Mesh | 13×13 = 169 | auf die konfigurierten Grenzen geklemmt |
| Parameter fehlen | 13×13 = 169 | gewöhnliches BED_MESH_CALIBRATE |
Der Referenzpunkt muss zwingend im Messbereich liegen – sonst hat das Mesh keinen gültigen Nullbezug.
Und dann tat es nichts
Der erste Testlauf mit genau dem Befehl, den das Makro absetzt, lieferte ein Mesh über das ganze Bett. 13×13 Punkte, wie immer. Keine Fehlermeldung, keine Warnung, Rückmeldung ok.
Der Grund stand in vier Zeilen, die zur Eddy-Installation gehören und Klippers Originalbefehl überschreiben:
[gcode_macro BED_MESH_CALIBRATE]
rename_existing: BTT_BED_MESH_CALIBRATE
gcode:
BTT_BED_MESH_CALIBRATE METHOD=rapid_scan # <- kein {rawparams}Der Wrapper ruft das Original mit einem festen Parameter auf und reicht nichts weiter. MESH_MIN, MESH_MAX und PROBE_COUNT wurden verworfen – ohne Fehler, ohne Hinweis. Beim nächsten Druck hätte schlicht nichts anders ausgesehen.
Genau davor schützt ein Testlauf und keine Codeprüfung: Der Befehl war korrekt, die Syntax war korrekt, die Rückmeldung war ok. Nur das Ergebnis war das alte. Ein Fehler, der sich als Erfolg meldet, ist von einem Erfolg nur am Ergebnis zu unterscheiden.
Die Reparatur reicht durch und behält das ursprüngliche Verhalten, wenn niemand ein eigenes METHOD mitgibt:
{% if 'METHOD' in (rawparams|upper) %}
BTT_BED_MESH_CALIBRATE {rawparams}
{% else %}
BTT_BED_MESH_CALIBRATE METHOD=rapid_scan {rawparams}
{% endif %}Nach der Reparatur bestätigt der Testlauf, was gewollt war: 49 Punkte über 135–265 mm, Mittelwert +0,005 mm, 19 der 49 Punkte im Minus. Der Nullbezug hält also auch im Teilbereich.
Und der Nebeneffekt ist der eigentliche Gewinn: Weil die Punktzahl mit der Fläche wächst, sinkt der Punktabstand von 32,3 auf 21,6 mm. Man misst gleichzeitig weniger und feiner.
Lohnt ein feineres Mesh?
Wenn adaptives Messen die Auflösung schon verbessert – wäre noch feiner noch besser? Das lässt sich messen statt schätzen, denn 7×7, 5×5 und 3×3 sind exakte Teilmengen eines 13×13-Gitters. Man interpoliert aus den groben Punkten und vergleicht mit den tatsächlich gemessenen feinen.
| Gitter | Punkte | Abstand | RMS-Fehler | größter Fehler |
|---|---|---|---|---|
| 7×7 | 49 | 64,7 mm | 0,0067 mm | 0,0130 mm |
| 5×5 | 25 | 97,0 mm | 0,0077 mm | 0,0191 mm |
| 4×4 | 16 | 129,3 mm | 0,0122 mm | 0,0223 mm |
| 3×3 | 9 | 194,0 mm | 0,0192 mm | 0,0371 mm |
Selbst mit nur jedem zweiten Punkt liegt der Fehler bei 6,7 µm. Aber das allein reicht als Argument nicht: Vielleicht ist dort echte Struktur, die man einfangen sollte. Also die zweite Frage – ist diese Feinstruktur überhaupt reproduzierbar? Zwei unabhängige Vermessungen desselben Betts, zerlegt in den Anteil, den ein grobes Gitter schon sieht, und den Rest:
| Anteil | Betrag |
|---|---|
| Bettwölbung | 108 µm |
| gespeicherter Offset | 100 µm |
| Feinstruktur | 5,5 µm |
| davon echt | 2,7 µm |
Von der Feinstruktur, die ein 13×13-Gitter gegenüber 7×7 zusätzlich erfasst, ist die Hälfte von Messung zu Messung eine andere. Ein feineres Mesh fängt nicht mehr Bettform ein, sondern backt bei jedem Druck ein anderes Rauschmuster in die Korrektur.
Gemessen an einer 0,32 mm dicken ersten Schicht: Die Bettwölbung macht 33,8 % aus – dafür ist das Mesh da, und ein grobes Raster erfasst sie vollständig. Die reproduzierbare Feinstruktur macht 0,9 % aus. Ein gespeicherter Z-Offset, der zu diesem Zeitpunkt unbemerkt in der Konfiguration stand, war mit 100 µm siebenunddreißigmal größer als sie.
Das ist die eigentliche Lehre aus dieser Rechnung, und sie gilt weit über Bed Meshes hinaus: Bevor man die Auflösung einer Messung erhöht, lohnt der Blick darauf, ob der größte Fehler überhaupt in dieser Messung steckt. Hier steckte er woanders – in einer Zahl, die seit Monaten unbemerkt in einer Textdatei stand.
Dazu kommt, dass mesh_pps: 5 zwischen je zwei gemessenen Punkten ohnehin fünf interpolierte einfügt. Die aufgetragene Korrekturfläche ist längst glatt und dicht; mehr Messpunkte machen sie nur zappeliger. Wer wirklich an der Genauigkeit drehen will, erhöht samples – das bekämpft das Rauschen, statt es abzutasten.
Drucker: HevORT, Klipper v0.13.0-743, BTT Eddy USB, Phaetus Rapido 2, 0,4-mm-Düse. Slicer: OrcaSlicer 2.4.2. Profil: PLA auf PEI, 0,32/0,32 mm, 230/60 °C, 26 mm³/s, 8 % Lightning, Z-Hop 0,2 mm Slope.
Alle Zahlen stammen aus Messungen an dieser Maschine. Sie gelten für diesen Drucker und dieses Modell, nicht allgemein.
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 – dieser Artikel
- Sieben Fehlschlüsse bei der Klipper-Fehlersuche
Anzeige · Affiliate-Link – kaufst du darüber, erhalte ich ggf. eine Provision. Für dich ändert sich am Preis nichts.
