Es hätte so schön sein können. Alles funktioniert auf Anhieb und Drucke entstehen dabei, die man sich …

Leider nein! Ein paar Arbeiten waren dann schon noch notwendig, bis alles lief.

Nach mehrmaliger Kontrolle aller Leitungen, Stecker und Steckplätze sollte zumindest ein elektrischer Fehler auszuschließen sein. Der Raspi wurde zuerst eingeschaltet und lief natürlich ohne Probleme. Zwar meldeten sich diverse News mit Updatehinweisen, aber das ist ja bei OctoPi normal.

Etwas mehr Gedanken machte ich mir beim Einschalten des OctopusPro-Boards. Da hingen nun diverse Komponenten dran und einige Jumper wurden angepasst. Trotzdem auch hier: Kein Problem. Da ich die Riemen noch nicht wieder aufgelegt hatte, konnte ich die X- und Y-Achse nicht fahren, da man dafür ja ein Homing benötigt, was eben nicht möglich war ohne Riemen. Das gilt dann auch identisch für die Z-Achse, die ebenfalls ein Homing benötigt, was aber seinerseits vom Homing der Druckebene abhängt. Zumindest die Heizungen konnte ich kurz mal einschalten. Das war von Erfolg gekrönt. Im OctoPi wurde erwartungsgemäß die steigende Temperaturkurve gezeigt und das beheizbare Druckbett nahm spürbar an Temperatur zu.

Es wurde Zeit, die Riemen wieder aufzulegen. Die hatte ich bei den ganzen Arbeiten entfernt, um sie zu schonen. Da kam mir dann wieder ein Problem unter, dass ich schon beim alten Tronxy hatte. Die Ritzel auf den Steppern für X und Y haben unterschiedliche Höhen, weil die Riemen übereinander liegen. Der untere Riemen und damit auch sein Ritzel macht kein Problem. Der obere Riemen sorgt allerdings in dem Fall, dass man horizontal laufende Riemen haben, will für ein Problem. Das Ritzel muss dann schon am äußersten Punkt der Achse montiert werden. Immerhin liegen 12mm Höhenunterschied zwischen beiden Riemen. Ich entschied mich dafür eine kleine Adapterplatte zu fräsen, damit der Stepper höher montiert werden kann, nämlich genau 12mm höher.

In dieser Art gefertigt und angebracht beeinflusst das auch nicht die Stabilität.

Hardwareseitig war ich also wieder soweit mit den Klipper-Tests fortzufahren. Zu meinem Erstaunen reagierte der Drucker  in einer überhaupt nicht nachvollziehbaren Art und Weise. Bestimmte Stepper liefen gar nicht. Andere wiederum waren kaum steuerbar. Irgendwie hatte ich doch tatsächlich die falsche printer.cfg auf dem System. Ich kann nicht nachvollziehen, warum das so war.

Ich habe dann meine eigene printer.cfg aus den ersten Beiträgen dieser Reihe auf das System gespielt. Das geht sehr leicht, wenn man in OctoPi das Klipper-Plugin geladen hat. Dann kann man dort einen Editor aufrufen und das File direkt bearbeiten. 

Dies sind nur beispielhafte Meldungen des Klipper-Logs, das OctoPi präsentiert. Zunächst mal fehlten ein paar Definitionen. Das meldet Klipper aber nicht etwa bei der Fileanalyse und auch nicht beim Neustart, sondern erst, wenn man eine Funktion ausführt.

Irgendwann nach ein paar Anpassungen kam kein Fehler mehr. Leider funktionierte es aber immer noch nicht. Beim Homing in der Ebene fuhr das System den Druckkopf in die Anschläge und lies die Riemen tanzen. Nur Ausschalten half. Ich konnte aber keinen Fehler in der Konfiguration finden. Dann entsann ich mich eines Konfigurationsfiles, das ich schon mal erwähnt hatte. Der Kollege Speckenheuer hatte für sein SKR1.4-Board am Tronxy schon mal ein printer.cfg erstellt und im Netz geteilt. Da habe ich dann nochmal reingeschaut. Auf den ersten Blick kein wesentlicher Unterschied. Doch dann fiel mir auf, dass er bei den Parametern run_current und driver_SGTHRS deutlich andere Werte hatte. Der erste ist ja noch leicht aus dem Namen abzuleiten.: Der Strom um den Motor zu bewegen. Der zweite Wert zeigt die Empfindlichkeit, mit der der Treiber registriert, ob ein erhöhter Widerstand auftritt, – also beispielsweise der Endpunkt der Achse.

[tmc2209 stepper_x]
#DRIVER0
uart_pin: PC4
run_current: 0.8
hold_current: 0.500
#stealthchop_threshold: 0
driver_SGTHRS: 100
diag_pin: ^PG6

Ich habe die Werte dann bei mir übernommen. Danach lief die Ebene sofort. Sehr schön. Ein bisschen Anpassung wird aber noch nötig sein.

In den Z-Einstellungen zeigte sich, dass die Parameterwiederholung im Z1-Abschnitt nicht erfolgen sollte. Zudem war liefen die Stepper in die falsche Richtung, was mit dem Ausrufezeichen (Negation) bei
dir_pin: !PF10 und dir_pin: !PG3
schnell behoben war.

Der BL-Touch-Abschnitt bekam pro forma einen Satz weitere Parameter, teilweise, weil sie verlangt wurden:
x_offset: -41
y_offset: -13
z_offset: 0

Sicherheitshalber hatte ich mir auch noch mal die Zuordnung von Control und Z- -PIN angesehen. Die war aber richtig.

Auch der Extruder lief in die falsche Richtung. Ein Ausrufezeichen an der richtigen Stelle, und auch das war behoben. Der Bereich des SMART-Filament-Sensors wurde aus schon genannten Gründen auskommentiert um beim Einfahren nicht zu stören.

Hier die komplette Datei. Die txt-Erweiterung ist natürlich im Einsatz zu entfernen und dient hier nur zur Passivierung:

Jetzt lassen sich die Achsen in der Ebene mit sensorless Homing bewegen. Das Druckbett wird mit Hilfe des BL-Touch zuverlässig in Grundstellung gebracht. Die Heizungen funktionieren und der Extruder fördert Filament und beherrscht auch ein Retract des selbigen.

Der nächste Schritt besteht nun in der Kalibrierung der Achsen und des Filamentvorschubes. Zudem muss der Nozzle-Abstand eingestellt werden. Die Flächenmessung bezüblich der Ausrichtung des Druckbettes und seiner Ebenheit fehlt auch noch. Das sind aber alles Schritte, die schon mal irgendwo aufgetaucht sind und keine Spezialität an diesem Drucker darstellen.