Ziel des letzten Beitrags war, die populäre und meist verbreitete Variante von Klipper zu installieren. Hiermit soll es nun möglich sein, diverse Optimierungen für den Druck unter Klipper zu nutzen. Eine davon ist das adaptive Meshing und Purging.

Ich hatte schon versucht Klipper Adaptive Meshing and Purging unter Octoprint zu installieren. Leider hatte ich da keinen Erfolg, was eventuell auch daran liegt, dass ich die Zusammenhänge bisher zu wenig kenne. Gerade die Mechanismen der Übergabe der GCODE-Dateien an Klipper beziehungsweise an das Betriebssystem habe ich noch nicht analysiert.

Probieren wir es unter Klipper mit Mainsail auf dem RaspberryPi.

Im GitHub findet man die notwendigen Informationen um Adaptive Meshing und auch das spezielle angepasste Purging zu installieren. Beide Funktionen basieren auf der Fähigkeit Klippers nicht nur das gesamte Druckbett zu betrachten, sondern gezielt einzelne Areale zu verarbeiten. Im Speziellen geht es um den Bereich, in dem sich das zu druckende Objekt befindet. Klipper kann diese Objekte durch einen Kennzeichnung der einzelnen Objekte im GCODE  erkennen. Ein solcher gekennzeichneter Ausschnitt ist dies hier:

; printing object Staender.stl id:0 copy 0

Kommt beispielsweise der gleiche „Staender“ nochmals vor, sieht das so aus:

; stop printing object Staender.stl id:0 copy 0
; printing object Staender.stl id:1 copy 0

Zum Einen wird ein Objekt ordnungsgemäß „abgemeldet“ und zum Anderen ein neues Objekt gestartet. So geht das dann Layer für Layer weiter.  Die Funktion exclude_object wird hierzu verwendet. Es wäre sogar möglich mit einem fertigen GCODE-File für mehrere Objekte, genau die auszuwählen, die gedruckt werden. Andere werden in dem Fall ignoriert.

Ein weiterer Nutzen ist der, dass das Meshing, also das Höhenabtasten des Druckbettes, nur in einem begrenzten Bereich, nämlich dem mit dem Objekt, durchgeführt wird. Dieses begrenzte Abtasten erhöht die Genauigkeit in diesem Bereich. Man könnte stattdessen ein beliebig enges Abtastnetz, beispielsweise 20 x 20 Punkte,  nutzen. Das würde aber lange dauern und hätte außerhalb des zu druckenden Objektes keinerlei Vorteile.

Genau hier setzt das KAMP ein. Zu finden ist es hier.

Die englische Anleitung führt dazu ausführlich durch die einzelnen Installationsschritte. Meine Installation enthält bereits alle Einstellungen um mit dem BL-Touch das Druckbett abzutasten. Soweit sollte das schon funktionieren.

In die printer.cfg ist der schon weiter oben genannte Abschnitt exclude_object einzubauen. Die Position im File scheint mir nicht entscheiden zu sein.

Wie ich schon erwähnt habe, ist es notwendig, dass das ganze Klipper-System vollen Zugriff auf die Druckdatei bekommt.  Das muss in der moonraker.conf eingetragen werden.

[file_manager]
enable_object_processing: True

Damit Klipper auch die Kennzeichnungen der Objekte in der gcode-Datei erkennen kann, muss das im Slicer aktiviert werden. Im PRUSA-Slicer geht das an der Stelle Objekte benennen.

Leider ist auch etwas Arbeit im Terminal auf Betriebssystemebene notwendig. Dazu baut man eine Verbindung  zum RaspberryPi über putty auf. Innerhalb des root-Verzeichnisses sind ein paar Befehle abzusetzen:

git clone https://github.com/kyleisah/Klipper-Adaptive-Meshing-Purging.git

Dieser Befehl holt aus dem GitHub das gesamte Softwarepaket für KAMP und kopiert den Ordner an die richtige Stelle. Eine echte Installation läuft hier nicht.

ln -s ~/Klipper-Adaptive-Meshing-Purging/Configuration printer_data/config/KAMP

Linux lebt von symbolischen Links, die hilfreich für diverse Aktionen sind. Hier wird der Link auf den vorhin kopierten Ordner KAMP angelegt, damit er auch über das config-Verzeichnis greifbar wird. Das ist unter anderem auch für das Paket-/Updatemangement wichtig, aber auch um die Makros innerhalb der printer.cfg greifbar zu machen. In einzelnen Fällen scheint es aber mit dem Befehl Probleme zu geben und der Link wird nicht sauber angelegt. Nicht nur dazu ist auch das Video unter diesem Link hilfreich.

In der letzten Zeile wurde der KAMP-Ordner eingebunden. Theoretisch würde es auch reichen, nur die benötigten Dateien einzubinden. Dann kann man sich die einzelnen includes auswählen.

[include KAMP/Adaptive_Mesh.cfg]
[include KAMP/Voron_Purge.cfg]
[include KAMP/Line_Purge.cfg]

Ich bevorzuge die erste Lösung und binde den ganzen Ordner ein. Siehe obiges Bild.

Es wäre unkomfortabel, wenn man jedes Update von KAMP immer umständlich selbst einspielen müsste. Von der umständlichen ständigen Kontrolle mal ganz abgesehen. Also nutzt man am besten den Updatemanager, so wie es alle anderen Komponenten unter Klipper (bzw. Mainsail) auch tun. Dazu ist der entsprechende Eintrag in der moonraker.conf notwendig:

[update_manager Klipper-Adaptive-Meshing-Purging]
type: git_repo
channel: dev
path: ~/Klipper-Adaptive-Meshing-Purging
origin: https://github.com/kyleisah/Klipper-Adaptive-Meshing-Purging.git
managed_services: klipper
primary_branch: main

Startet man jetzt das ganze System neu, sieht man im Update Manager unter Mainsail die Einbindung von KAMP.

Leider sind wir immer noch nicht fertig. Damit die neuen Funktionen überhaupt genutzt werden, müssen sie durch unseren gcode aufgerufen werden. Ich habe unter Marlin die entsprechenden Eintragungen für die Druckvorbereitung, den sogenannten Startcode, über den Slicer mitgegeben. Unter Klipper hat es sich eingebürgert, dass der eigentliche Startcode in der printer.conf als Makro eingetragen wird. Über diesen ganzen „Umbau“ könnte man einen eigenen Beitrag schreiben, was aber hier zu weit führt. Mir hat für den Einstieg diese Seite ganz gut geholfen.

Zu Beginn des neuen Drucks muss KAMP initialisiert werden. Das erreicht man, indem im Startcode zwei Eintragungen vorgenommen werden: (Achtung Update:)

SETUP_KAMP_MESHING [parameters]
SETUP_VORON_PURGE [parameters]

Die Parameter kann man zunächst mal inklusive der Klammern weglassen.

Update: Offensichtlich muss man SETUP_KAMP_MESHING mittlerweile komplett weglassen. In den neuen Konfigurationsdateien ist dieses Macro nicht mehr vorhanden und im Druck wirft es Fehler.

Im zweiten Schritt wird dann das eigentliche Makro zur Verarbeitung aufgerufen.

BED_MESH_CLEAR

BED_MESH_CALIBRATE

VORON_PURGE

Es ist durchaus möglich, dass bereits in der printer.cfg an anderer Stelle der Befehl BED_MESH_CALIBRATE aufgerufen wird. Das darf aber keinesfalls sein und muss auskommentiert werden.

Kleiner Einschub zum Thema PURGE:
Jeder kennt vermutlich die PURGE-Linie am Rand des Druckbettes, damit der Extruder bzw. das Hotend befüllt werden. Das wird normalerweise immer an der gleichen Stelle aufgebracht.

KAMP bietet auch ein LINE_PURGE an. Das wird dann relativ zum Druckobjekt angelegt, d.h. die Linie läuft neben dem Druckobjekt.

Beide Linien-Purges haben aber einen erheblichen Nachteil speziell auf strukturierten PEI-Druckflächen. Da die Linie sehr dünn und nur einlagig ist, ist sie nach dem Druck kaum zu beseitigen.

VORON_PURGE macht es anders: Es wird eher ein dreiteiliger Klecks angelegt. Die Funktion ist die gleiche, aber der Klecks ist leichter zu beseitigen!

Mein Startcode sieht aktuell so aus:

Im Slicer wird das folgendermaßen adressiert:

Die M117 wird übrigens vom KAMP-Autor empfohlen, um bestimmte Unzulänglichkeiten zu beheben. Auch wenn Klipper meckert, dass es den Code nicht kennt, – es funktioniert.

Bei mir zeigte sich dann noch ein weiterer Fehler:

Schuld daran ist ein irgendwo aus der Installationsdokumentation entnommener Wert für max_extrude_cross_section. Ich habe ihn einfach in der pinter.cfg auf 5 hochgezogen und schon war Ruhe. 

Zum Schluss noch ein kurzes Video, wie das dann bei Benutzung aussieht.