Status Repetier Firmware v2?
geschrieben von Legion 2.3
|
Re: Status Repetier Firmware v2? 30. May 2021 16:41 |
Inzwischen habe ich Marlin v2 ans laufen gebracht und ein Test-Benchy gedruckt.
Im direkten Vergleich mit dem Druck, den ich zuvor mit Repetier gemacht habe, konnte ich aber nicht die geringste Verbesserung feststellen.
Ich hatte eigentlich erwartet, dass die Kantenschwingungen ("Ringing") mit den S-förmigen Beschleunigungsrampen reduziert würden. Tatsächlich sieht der Druck mit Marlin eher noch etwas unruhiger aus als mit Repetier. Also habe ich erst mal wieder alles auf Anfang gesetzt und Repetier zurück installiert.
Der nächste Anlauf wäre jetzt Klipper.
Ich habe Klipper mit Octoprint bereits auf dem Rasperry und einem zweiten Arduino-Due, was ich noch hier liegen habe, installiert.
Allerdings muss ich zugeben, dass ich erhebliche Schwierigkeiten damit habe, mich in die Funktionsweise und die Art der Konfiguration von Klipper hereinzudenken.
Bei Repetier ist es dagegen total einfach: Es gibt einen Konfigurator, den man mit seinen Daten füttert und raus kommt eine Firmware mit vollständiger Konfig-Datei, die man mit der Arduino-Software mit einem Klick hochladen kann. Bei Marlin verhält sich das ganze, wenn man von meinen Startproblemen mit der Visual Studio Code absieht, recht ähnlich. Hier gibt es zwar keinen Konfigurator, aber es ist innerhalb der Konfig fast jeder Parameter in Klartext nachvollziehbar erklärt und auch alles vollständig enthalten.
Bei Klipper brauche ich mindestens 2 Programme (BelenaEtcher und PuTTY), muss alles ans Netz anschließen und die Firmware über Konsolenbefehle herunterladen.
In der Config selber ist nichts dokumentiert und das fieles scheint irgendwie zu fehlen.
So sieht die Konfig bei mir aus:
Die Konfig von Repetier hat dagegen über 600 Zeilen.
Bei Klipper muss man scheinbar für zusätzliche Features die entsprechenden Zeilen manuell in der Konfig ergänzen und hoffen, dass die Syntax richtig ist.
Zum Beispiel habe ich bei meinem Drucker 2 Motoren für den Extruder verbaut.
Dafür müsste ich laut dieser Dokumentation noch so etwas in der Art in der Konfig ergänzen:
Jetzt wird für mich als Programmierlaie erst mal nicht ersichtlich, was ich jetzt genau ich hier auskommentieren muss.
Vermutlich muss dass dann so aussehen:
Sicher bin ich mir da aber nicht. Ich muss mich erst mal durch die gewaltige Doku von Klipper wälzen.
Wie es aussieht, kann ich auch nicht mein Rapsberry Pi 4 als USB-Slave mit meinem Steuerungs-PC verbinden, weil das PI selbst der USB-Master ist. Die Verbindung muss also über Ethernet hergestellt werden. Da mein Tablet-PC keine Ethernet-Schnittstelle hat, brauche ich dafür noch einen USB-Ethernet-Adapter.
Ich habe auch noch nicht so ganz herausgefunden, ob und wie ich Klipper mit der Repetier Server-Oberfläche ans Laufen bringe.
Die Anleitung zur Installation bezieht sich hier nur auf Octo-Print und dessen Bedienoberfläche finde ich deutlich schlimmer als die von Repetier.
Es soll wohl möglich sein, erst Repetier-Server auf dem Pi zu installieren und danach Klipper darauf zu installieren. Allerdings hatte ich früher schon mal versucht, ein RPi mit Repetier Server direkt per Ethernet-Kabel mit meinem PC zu verbinden, aber die Verbindung hat ohne Router dazwischen nie funktioniert. Mit Octoprint dagegen funktioniert das immerhin sofort.
Alles ziemlich kompliziert
Im direkten Vergleich mit dem Druck, den ich zuvor mit Repetier gemacht habe, konnte ich aber nicht die geringste Verbesserung feststellen.
Ich hatte eigentlich erwartet, dass die Kantenschwingungen ("Ringing") mit den S-förmigen Beschleunigungsrampen reduziert würden. Tatsächlich sieht der Druck mit Marlin eher noch etwas unruhiger aus als mit Repetier. Also habe ich erst mal wieder alles auf Anfang gesetzt und Repetier zurück installiert.
Der nächste Anlauf wäre jetzt Klipper.
Ich habe Klipper mit Octoprint bereits auf dem Rasperry und einem zweiten Arduino-Due, was ich noch hier liegen habe, installiert.
Allerdings muss ich zugeben, dass ich erhebliche Schwierigkeiten damit habe, mich in die Funktionsweise und die Art der Konfiguration von Klipper hereinzudenken.
Bei Repetier ist es dagegen total einfach: Es gibt einen Konfigurator, den man mit seinen Daten füttert und raus kommt eine Firmware mit vollständiger Konfig-Datei, die man mit der Arduino-Software mit einem Klick hochladen kann. Bei Marlin verhält sich das ganze, wenn man von meinen Startproblemen mit der Visual Studio Code absieht, recht ähnlich. Hier gibt es zwar keinen Konfigurator, aber es ist innerhalb der Konfig fast jeder Parameter in Klartext nachvollziehbar erklärt und auch alles vollständig enthalten.
Bei Klipper brauche ich mindestens 2 Programme (BelenaEtcher und PuTTY), muss alles ans Netz anschließen und die Firmware über Konsolenbefehle herunterladen.
In der Config selber ist nichts dokumentiert und das fieles scheint irgendwie zu fehlen.
So sieht die Konfig bei mir aus:
# This file contains common pin mappings for RADDS (v1.5) boards. To # use this config, the firmware should be compiled for the Arduino # Due. # See docs/Config_Reference.md for a description of parameters. # Temp sensor pins: PA16..PA6 # Mosfet Pins: PC23 (Heatbed), PC22, PC21, PD7, PD8, PB27 [stepper_x] step_pin: PA15 dir_pin: PA14 enable_pin: PD1 microsteps: 64 rotation_distance: 39.9 endstop_pin: ^PD3 #endstop_pin: ^PC2 position_endstop: 0 position_max: 440 homing_speed: 50 [stepper_y] step_pin: PA12 dir_pin: !PA13 enable_pin: PB26 microsteps: 64 rotation_distance: 39.9 endstop_pin: ^PD9 #endstop_pin: ^PC4 position_endstop: 0 position_max: 335 homing_speed: 50 [stepper_z] step_pin: PB25 dir_pin: PC28 enable_pin: PD5 microsteps: 128 rotation_distance: 2 endstop_pin: ^PD10 #endstop_pin: ^PC6 position_endstop: 0 position_max: 500 [extruder] step_pin: PA2 dir_pin: PA3 enable_pin: PB17 microsteps: 128 rotation_distance: 22.46 nozzle_diameter: 0.400 filament_diameter: 1.750 heater_pin: PB27 sensor_type: ATC Semitec 104GT-2 sensor_pin: PA16 control: pid pid_Kp: 7.5 pid_Ki: 0.54 pid_Kd: 25.5 min_temp: 0 max_temp: 285 #[extruder1] #step_pin: PB19 #dir_pin: PB18 #enable_pin: PB20 #[extruder2] #step_pin: PC12 #dir_pin: PB14 #enable_pin: PC14 [heater_bed] heater_pin: PC23 sensor_type: EPCOS 100K B57560G104F sensor_pin: PA24 control: watermark min_temp: 0 max_temp: 130 [fan] pin: PC21 #[heater_fan nozzle_cooling_fan] #pin: PC22 [mcu] serial: /dev/ttyACM0 [printer] kinematics: cartesian max_velocity: 500 max_accel: 2000 max_z_velocity: 10 max_z_accel: 100 # "RepRapDiscount 2004 Smart Controller" type displays #[display] #lcd_type: hd44780 #rs_pin: PA19 #e_pin: PA20 #d4_pin: PC19 #d5_pin: PC18 #d6_pin: PC17 #d7_pin: PC16 #encoder_pins: ^PB21, ^PC13 #click_pin: ^!PC15 # "RepRapDiscount 128x64 Full Graphic Smart Controller" type displays #[display] #lcd_type: st7920 #cs_pin: PA19 #sclk_pin: PC19 #sid_pin: PA20
Die Konfig von Repetier hat dagegen über 600 Zeilen.
Bei Klipper muss man scheinbar für zusätzliche Features die entsprechenden Zeilen manuell in der Konfig ergänzen und hoffen, dass die Syntax richtig ist.
Zum Beispiel habe ich bei meinem Drucker 2 Motoren für den Extruder verbaut.
Dafür müsste ich laut dieser Dokumentation noch so etwas in der Art in der Konfig ergänzen:
[extruder_stepper my_extra_stepper] #extruder: extruder # The extruder this stepper is synchronized to. The default is # "extruder". #step_pin: #dir_pin: #enable_pin: #microsteps: #rotation_distance: # See the "stepper" section for the definition of the above # parameters.
Jetzt wird für mich als Programmierlaie erst mal nicht ersichtlich, was ich jetzt genau ich hier auskommentieren muss.
Vermutlich muss dass dann so aussehen:
[extruder_stepper my_extra_stepper] extruder: extruder step_pin: PB19 dir_pin: PB18 enable_pin: PB20 microsteps: 128 rotation_distance: 22.46
Sicher bin ich mir da aber nicht. Ich muss mich erst mal durch die gewaltige Doku von Klipper wälzen.
Wie es aussieht, kann ich auch nicht mein Rapsberry Pi 4 als USB-Slave mit meinem Steuerungs-PC verbinden, weil das PI selbst der USB-Master ist. Die Verbindung muss also über Ethernet hergestellt werden. Da mein Tablet-PC keine Ethernet-Schnittstelle hat, brauche ich dafür noch einen USB-Ethernet-Adapter.
Ich habe auch noch nicht so ganz herausgefunden, ob und wie ich Klipper mit der Repetier Server-Oberfläche ans Laufen bringe.
Die Anleitung zur Installation bezieht sich hier nur auf Octo-Print und dessen Bedienoberfläche finde ich deutlich schlimmer als die von Repetier.
Es soll wohl möglich sein, erst Repetier-Server auf dem Pi zu installieren und danach Klipper darauf zu installieren. Allerdings hatte ich früher schon mal versucht, ein RPi mit Repetier Server direkt per Ethernet-Kabel mit meinem PC zu verbinden, aber die Verbindung hat ohne Router dazwischen nie funktioniert. Mit Octoprint dagegen funktioniert das immerhin sofort.
Alles ziemlich kompliziert
|
Re: Status Repetier Firmware v2? 04. June 2021 15:49 |
Ich habe die Ursache für den Fehler "Klippy-State: Startup" oder "Klippy-State: Error" gefunden: In der Firmware-Konfiguration hatte ich als Com-Interface "USB" eingetragen (was ja erst mal absolut logisch klingt).
Einfach mal versuchsweise habe ich dann die Einstellung auf "Serial" geändert und siehe da, der Fehler ist weg und die Kommunikation über MainsailOS steht.
Dann musste ich noch rausfinden, dass der Thermistor vom Heizbett nicht an PA24 (Standard-Wert in der Konfiguration für das RADDS), sondern an PA6 hängt, und schon werden mir auch die Temperaturen korrekt angezeigt.
Inzwischen ist der geflashte Arduino auch im Drucker eingebaut.
So, bis jetzt hatte ich die ganze Konfiguration von meinem Desktop-PC aus erledigt. Die tatsächliche Steuerung sollte aber von dem am Drucker verbauten Windows-Tablet-PC aus erfolgen. Dieser hat keinen LAN-Port, also habe ich mir einen USB-LAN-Konverter besorgt. Der Konverter an sich funktioniert auch grundsätzlich, einmal mit dem Router verbunden habe ich damit Internetzugriff, so wie es sein soll.
Allerdings schaffe ich es nicht, mit dem Tablet-PC über LAN das Raspberrry anzusprechen. Wenn ich es direkt per LAN-Kabel ohne Router dazwischen mit dem Tablet verbinde, bekomme ich weder über den Browser noch über PuTTY eine Verbindung hergestellt. Mit meinem Desktop-PC hatte das funktioniert.
Wenn ich das Raspberry per LAN mit dem Router verbinde und das Tablet per WLAN mit dem Router verbinde, bekomme ich zwar per PuTTY eine Verbindung zum Raspberry aufgebaut, aber wenn ich "mainsailos.local" aufrufen möchte, zeigt mir der Browser den Fehler "403 - FORBIDDEN" an.
Es ist doch echt zum verrückt werden. Kaum ist ein Problem gelöst, steht das nächste in der Tür.
Hat jemand eine Idee?
Einfach mal versuchsweise habe ich dann die Einstellung auf "Serial" geändert und siehe da, der Fehler ist weg und die Kommunikation über MainsailOS steht.
Dann musste ich noch rausfinden, dass der Thermistor vom Heizbett nicht an PA24 (Standard-Wert in der Konfiguration für das RADDS), sondern an PA6 hängt, und schon werden mir auch die Temperaturen korrekt angezeigt.
Inzwischen ist der geflashte Arduino auch im Drucker eingebaut.
So, bis jetzt hatte ich die ganze Konfiguration von meinem Desktop-PC aus erledigt. Die tatsächliche Steuerung sollte aber von dem am Drucker verbauten Windows-Tablet-PC aus erfolgen. Dieser hat keinen LAN-Port, also habe ich mir einen USB-LAN-Konverter besorgt. Der Konverter an sich funktioniert auch grundsätzlich, einmal mit dem Router verbunden habe ich damit Internetzugriff, so wie es sein soll.
Allerdings schaffe ich es nicht, mit dem Tablet-PC über LAN das Raspberrry anzusprechen. Wenn ich es direkt per LAN-Kabel ohne Router dazwischen mit dem Tablet verbinde, bekomme ich weder über den Browser noch über PuTTY eine Verbindung hergestellt. Mit meinem Desktop-PC hatte das funktioniert.
Wenn ich das Raspberry per LAN mit dem Router verbinde und das Tablet per WLAN mit dem Router verbinde, bekomme ich zwar per PuTTY eine Verbindung zum Raspberry aufgebaut, aber wenn ich "mainsailos.local" aufrufen möchte, zeigt mir der Browser den Fehler "403 - FORBIDDEN" an.
Es ist doch echt zum verrückt werden. Kaum ist ein Problem gelöst, steht das nächste in der Tür.
Hat jemand eine Idee?
|
Re: Status Repetier Firmware v2? 13. June 2021 16:47 |
... hmmm ... einige Stromspar-Einstgellungen schalten nach einer vorgegebenen Zeit den Bildschirm oder I/O-Ports ab -- bei Mausbewegungen oder Tastenklicks wird das jeweils neu zurückgesetzt - evtl. da mal nachschauen
Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]
Call for the project "garbage-free seas" - [reprap.org]
Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]
Call for the project "garbage-free seas" - [reprap.org]
|
Re: Status Repetier Firmware v2? 26. June 2021 14:51 |
Ich weiß nicht genau, wieso, aber jetzt steht die Verbindung zu MainsailOS auf einmal.
Dabei habe ich eigentlich nichts geändert, ich habe nur ein paar mal die USB-Adapter hin und her gesteckt.
Vielleicht hatte ich irgendwo im USB-Kabelstrang einen Wackelkontakt. Der ganze Aufbau für Klipper ist etwas improvisiert und ich habe deshalb 3 USB-Hubs und Verlängerungen zwischen dem Tablet ist dem Ethernet-Adapter.
Vielleicht hat auch das letzte Windows-Update irgendetwas geändert... wer weiß.
Ein paar Sachen musste ich dann noch anpassen: Ein paar Pins waren falsch konfiguriert und die Richtung der Motoren hatte nich gepasst. Alles halb so wild.
Dann kamen die ersten Bewegungen. Homing in allen Achsen funktionierte tadellos und auch die manuelle Bewegung in X und Y ging ohne Probleme.
Als ich dann aber die Z-Achse bewegen wollte, hing sich Klipper nach wenigen Millimetern immer auf: Fehlermeldung "MCU shutdown: Stepper too far in past".
Offensichtlich schafft Klipper es nicht, für meine Z-Achse ausreichend viele Steps zu generieren, um mit 10 mm/s zu verfahren. Als ich die Geschwindigkeit auf 9mm/s reduziert hatte, gab es keine Fehlermeldung mehr.
Ich habe dann ein bisschen recherchiert und scheinbar liegt es an dem Step delay, was ich auf 3 ys eingestellt habe. Damit können wohl rechnerisch nicht mehr ausreichend Steps generiert werden. Für Repetier ist das kein Problem, Klipper ist in der Hinsicht wohl zickiger.
Insgesamt konnte ich auch noch feststellen, dass MainsailOS deutlich träger auf manuelle Befehle reagiert als Repetier Server.
Auf jeden Fall konnte ich jetzt endlich meinen ersten Testdruck mit einem Benchy machen.
Ich hatte das Input-Shaping noch nicht aktiviert und deshalb bin ich auch nicht überrascht, dass sich an den Kantenschwingungen nicht viel geändert hat. Vielleicht ist es an der einen oder anderen Stelle etwas besser geworden, aber die Unterschiede sucht man mit einer Lupe.
Dafür gibt es recht viel Stringing, was an der Firmware liegen kann oder auch vielleicht an zu viel Feuchtigkeit im Filament.
Dem geschulten Betrachter mag vielleicht aufgefallen sein, dass dem Benchy ein bisschen was oben rum fehlt.
Das lag aber nicht an einem Abbruch des Drucks, sondern an einem krassen Schrittverlust in Z-Richtung, der zu einem Versatz von fast 1 mm geführt hat.
Ich weiß noch nicht so ganz, woran das liegen kann. Die Beschleunigung der Z-Achse ist mit gerade mal 100 mm/s² sehr verhalten eingestellt. Den Wert hatte ich von Repetier genau so wie alle anderen Beschleunigungswerte 1:1 übernommen.
Was mir in der Konfig fehlt, ist ein Wert für den Z-Jerk, den es in Repetier gibt. Dazu habe ich in der Doku von Klipper nichts gefunden. Es gibt einen Wert für die "square corner Velocity", was wie ich es verstehe quasi dem Jerk in Repetier entspricht. Den habe ich auf 5mm/s eingestellt .
Wenn diese Geschwindigkeit nicht nur für X und Y, sondern auch für Z gilt, würde das natürlich erklären, dass die Achse springt.
Es kann natürlich auch noch eine andere Ursache, z.B. fehlerhafte Kommunikation zwischen dem Raspberry und dem Arduino liegen. Ich weiß jetzt nicht, wie robust und fehlersicher das Protokoll von Klipper hier ist.
Hatte jemand schon mal das Problem gehabt?
1-mal bearbeitet. Zuletzt am 26.06.21 14:52.
Dabei habe ich eigentlich nichts geändert, ich habe nur ein paar mal die USB-Adapter hin und her gesteckt.
Vielleicht hatte ich irgendwo im USB-Kabelstrang einen Wackelkontakt. Der ganze Aufbau für Klipper ist etwas improvisiert und ich habe deshalb 3 USB-Hubs und Verlängerungen zwischen dem Tablet ist dem Ethernet-Adapter.
Vielleicht hat auch das letzte Windows-Update irgendetwas geändert... wer weiß.
Ein paar Sachen musste ich dann noch anpassen: Ein paar Pins waren falsch konfiguriert und die Richtung der Motoren hatte nich gepasst. Alles halb so wild.
Dann kamen die ersten Bewegungen. Homing in allen Achsen funktionierte tadellos und auch die manuelle Bewegung in X und Y ging ohne Probleme.
Als ich dann aber die Z-Achse bewegen wollte, hing sich Klipper nach wenigen Millimetern immer auf: Fehlermeldung "MCU shutdown: Stepper too far in past".
Offensichtlich schafft Klipper es nicht, für meine Z-Achse ausreichend viele Steps zu generieren, um mit 10 mm/s zu verfahren. Als ich die Geschwindigkeit auf 9mm/s reduziert hatte, gab es keine Fehlermeldung mehr.
Ich habe dann ein bisschen recherchiert und scheinbar liegt es an dem Step delay, was ich auf 3 ys eingestellt habe. Damit können wohl rechnerisch nicht mehr ausreichend Steps generiert werden. Für Repetier ist das kein Problem, Klipper ist in der Hinsicht wohl zickiger.
Insgesamt konnte ich auch noch feststellen, dass MainsailOS deutlich träger auf manuelle Befehle reagiert als Repetier Server.
Auf jeden Fall konnte ich jetzt endlich meinen ersten Testdruck mit einem Benchy machen.
Ich hatte das Input-Shaping noch nicht aktiviert und deshalb bin ich auch nicht überrascht, dass sich an den Kantenschwingungen nicht viel geändert hat. Vielleicht ist es an der einen oder anderen Stelle etwas besser geworden, aber die Unterschiede sucht man mit einer Lupe.
Dafür gibt es recht viel Stringing, was an der Firmware liegen kann oder auch vielleicht an zu viel Feuchtigkeit im Filament.
Dem geschulten Betrachter mag vielleicht aufgefallen sein, dass dem Benchy ein bisschen was oben rum fehlt.
Das lag aber nicht an einem Abbruch des Drucks, sondern an einem krassen Schrittverlust in Z-Richtung, der zu einem Versatz von fast 1 mm geführt hat.
Ich weiß noch nicht so ganz, woran das liegen kann. Die Beschleunigung der Z-Achse ist mit gerade mal 100 mm/s² sehr verhalten eingestellt. Den Wert hatte ich von Repetier genau so wie alle anderen Beschleunigungswerte 1:1 übernommen.
Was mir in der Konfig fehlt, ist ein Wert für den Z-Jerk, den es in Repetier gibt. Dazu habe ich in der Doku von Klipper nichts gefunden. Es gibt einen Wert für die "square corner Velocity", was wie ich es verstehe quasi dem Jerk in Repetier entspricht. Den habe ich auf 5mm/s eingestellt .
Wenn diese Geschwindigkeit nicht nur für X und Y, sondern auch für Z gilt, würde das natürlich erklären, dass die Achse springt.
Es kann natürlich auch noch eine andere Ursache, z.B. fehlerhafte Kommunikation zwischen dem Raspberry und dem Arduino liegen. Ich weiß jetzt nicht, wie robust und fehlersicher das Protokoll von Klipper hier ist.
Hatte jemand schon mal das Problem gehabt?
1-mal bearbeitet. Zuletzt am 26.06.21 14:52.
|
Re: Status Repetier Firmware v2? 13. July 2021 14:29 |
Ich bin bei den Tests mit Klipper ein wenig weiter gekommen:
Wie sich raus gestellt hat, hatte ich ein ganz erhebliches Kontaktproblem in der Elektronik!
Wie bin ich drauf gekommen?
Im weiteren Verlauf der Tests mit der neuen Firmware stand ich auf einmal vor dem Problem, dass sich die Z-Achse nur noch in eine Richtung bewegen wollte: nach unten!
Da lag die Vermutung erst mal nahe, dass es an Klipper lag. Also habe ich fix wieder Repetier aufgespielt, und es alles lief wieder wie gehabt... für kurze Zeit, bis auch hier die Z-Achse sporadisch die Richtung willkürlich wechseln wollte.
Die erste Vermutung war, dass der Treiber einen weg hat oder nicht richtig sitzt. Also habe ich etwas daran gewackelt und tatsächlich festgestellt, dass sich an der Z-Achse dadurch etwas tat. Sah also alles nach einem Kontaktproblem vom Treiber aus, speziell vom DIR-Pin. Also habe ich den Treiber ausgebaut, die Pins vorsichtig mit Isopropanol gereinigt und wieder eingebaut.
Mit dem Gedanken, den Fehler gefunden zu haben, gings zurück zu Klipper... bis die nächsten Fehler anklopften:
Erst mal wollte das Heizbett nicht mehr heizen. Der erste Verdacht fiel auf eine fehlerhafte Konfiguration, also habe ich für die Heizung alle Pins durchgetestet: Jeder Leistungsausgang außer der vom Heizbett ließ sich ansprechen... bis ich mal ein bisschen auf die Platine gedrückt habe und die LED vom Heizbett zu flackern begann. Dazu zeigte mir der Temperatursensor vom Heizbett auch ganz wilde Werte an, die ich mit Druck auf die Platine beeinflussen konnte ... also wieder ein Kontaktproblem.
Um dem bei zu kommen, habe ich dass RADDS vom Arduino gelöst und vorsichtig mit einem Isopropanol-getränkten Wattestäbchen sämtliche Kontaktpins sorgfältig gereinigt.
Danach alles wieder zusammen gebaut und siehe da: Alle Signale, wie sie sein sollten.
Scheinbar war ich beim Einbau unvorsichtig und habe mit meinen Fettfingern die Kontaktpins schön isoliert
Dann konnte es ja endlich mal mit der Kalibrierung des Input-Shaping-Moduls losgehen. Den Sensor hatte ich schon eine Weile hier liegen und passend verdrahtet. Die Kalibrierung selber war relativ simpel. Als Frequenzen kamen bei der X-Achse 48 Hz und auf der Y-Achse 38,8Hz mit Shaper-Type "MZV" heraus.
Dann folgten die Testdrucke mit Vergleich zur Repetier-Firmware. Es ist nicht absolut perfekt, aber eine deutliche Verbesserung
Links: Repetier, Rechts Klipper mit Input Shaping
Die Teile sind mit PETG gedruckt, was natürlich durch den hohen Reflexionsgrad alle Vibrationen gnadenlos zeigt.
Auf der vorderen linken Seite am Ring sieht es deutlich besser aus, während sich rechts weniger getan hat. Die Schwingungen auf der Rückseite sind noch sichtbar, aber deutlich weniger stark ausgeprägt.
Sieht also erst mal alles ganz gut aus, das kann meine neue Firmware werden... DACHTE ICH
Denn dann kam das:
Das gedruckte Türmchen oben SOLLTE eigentlich gerade sein. Das Teil habe ich in einem Durchgang 50x gedruckt, was insgesamt ca. 10h gedauert hat. Ich habe das selbe Teil danach nochmal mit Repetier gedruckt, ohne dass es sich schief weglehnt.
Nach dem Druck habe ich allerdings noch festgestellt, dass sich die Halteklammer vom Hotend (die aus PETG gedruckt war) etwas verzogen hat und die Schrauben nicht mehr ganz fest waren. Das Gegenstück der Klammer besteht aus ABS und war noch fest. Das Türmchen wurde im geschlossenem Bauraum mit ABS gedruckt, für das PETG war es wohl etwas zu heiß.
Nun kann ich nicht mit absoluter Sicherheit sagen, ob das schiefe Türmchen von Pisa eine Folge der verzogenen Klammer oder eines Fehlers in Klipper war.
Ich hätte die Angelegenheit noch weiter untersucht, wenn nicht noch weitere Probleme aufgetaucht wären.
Immer wieder nach einigen Stunden (bisher nur nach einem Druck, nicht während eines Drucks) hat sich Klippy aufgehangen. Der Drucker ließ sich nicht mehr ansprechen, die Firmware, Klippy und was sonst noch alles mitläuft ließ sich softwareseitig nicht neu starten. Der einzige Weg ist ein harter Reset: Schalter aus - Schalter ein - geht wieder... für einige Zeit.
Als wäre das noch nicht genug, steigt der USB - LAN-Adapter immer wieder aus und lässt sich nur durch einen Neustart von Windows wieder zum Dienst überreden.
Allgemein sind, selbst wenn alles funktioniert, die Reaktionszeiten von MainsailOS im Browser katastrophal: Häufig muss ich mehrere Sekunden nach einen Tastedruck warten, bis der entsprechende Befehl umgesetzt wird.
Bei Repetier Server dagegen läuft alles ohne Verzögerung.
Alles in Allem, auch wenn die Druckergebnisse sicher für sich sprechen, will ich doch hier das Thema Klipper erst mal für mich abhaken.
In der Summe sind es zu viele Fehler, zu viele Unwägbarkeiten, die dem dauerhaften, störungsfreien Betrieb entgegenstehen.
Vielleicht findet irgendwann das Input-Shaper-Feature noch seinen Weg in Marlin oder Repetier, was dann ohne Raspberry funktioniert.
Wie sich raus gestellt hat, hatte ich ein ganz erhebliches Kontaktproblem in der Elektronik!
Wie bin ich drauf gekommen?
Im weiteren Verlauf der Tests mit der neuen Firmware stand ich auf einmal vor dem Problem, dass sich die Z-Achse nur noch in eine Richtung bewegen wollte: nach unten!
Da lag die Vermutung erst mal nahe, dass es an Klipper lag. Also habe ich fix wieder Repetier aufgespielt, und es alles lief wieder wie gehabt... für kurze Zeit, bis auch hier die Z-Achse sporadisch die Richtung willkürlich wechseln wollte.
Die erste Vermutung war, dass der Treiber einen weg hat oder nicht richtig sitzt. Also habe ich etwas daran gewackelt und tatsächlich festgestellt, dass sich an der Z-Achse dadurch etwas tat. Sah also alles nach einem Kontaktproblem vom Treiber aus, speziell vom DIR-Pin. Also habe ich den Treiber ausgebaut, die Pins vorsichtig mit Isopropanol gereinigt und wieder eingebaut.
Mit dem Gedanken, den Fehler gefunden zu haben, gings zurück zu Klipper... bis die nächsten Fehler anklopften:
Erst mal wollte das Heizbett nicht mehr heizen. Der erste Verdacht fiel auf eine fehlerhafte Konfiguration, also habe ich für die Heizung alle Pins durchgetestet: Jeder Leistungsausgang außer der vom Heizbett ließ sich ansprechen... bis ich mal ein bisschen auf die Platine gedrückt habe und die LED vom Heizbett zu flackern begann. Dazu zeigte mir der Temperatursensor vom Heizbett auch ganz wilde Werte an, die ich mit Druck auf die Platine beeinflussen konnte ... also wieder ein Kontaktproblem.
Um dem bei zu kommen, habe ich dass RADDS vom Arduino gelöst und vorsichtig mit einem Isopropanol-getränkten Wattestäbchen sämtliche Kontaktpins sorgfältig gereinigt.
Danach alles wieder zusammen gebaut und siehe da: Alle Signale, wie sie sein sollten.
Scheinbar war ich beim Einbau unvorsichtig und habe mit meinen Fettfingern die Kontaktpins schön isoliert
Dann konnte es ja endlich mal mit der Kalibrierung des Input-Shaping-Moduls losgehen. Den Sensor hatte ich schon eine Weile hier liegen und passend verdrahtet. Die Kalibrierung selber war relativ simpel. Als Frequenzen kamen bei der X-Achse 48 Hz und auf der Y-Achse 38,8Hz mit Shaper-Type "MZV" heraus.
Dann folgten die Testdrucke mit Vergleich zur Repetier-Firmware. Es ist nicht absolut perfekt, aber eine deutliche Verbesserung
Links: Repetier, Rechts Klipper mit Input Shaping
Die Teile sind mit PETG gedruckt, was natürlich durch den hohen Reflexionsgrad alle Vibrationen gnadenlos zeigt.
Auf der vorderen linken Seite am Ring sieht es deutlich besser aus, während sich rechts weniger getan hat. Die Schwingungen auf der Rückseite sind noch sichtbar, aber deutlich weniger stark ausgeprägt.
Sieht also erst mal alles ganz gut aus, das kann meine neue Firmware werden... DACHTE ICH
Denn dann kam das:
Das gedruckte Türmchen oben SOLLTE eigentlich gerade sein. Das Teil habe ich in einem Durchgang 50x gedruckt, was insgesamt ca. 10h gedauert hat. Ich habe das selbe Teil danach nochmal mit Repetier gedruckt, ohne dass es sich schief weglehnt.
Nach dem Druck habe ich allerdings noch festgestellt, dass sich die Halteklammer vom Hotend (die aus PETG gedruckt war) etwas verzogen hat und die Schrauben nicht mehr ganz fest waren. Das Gegenstück der Klammer besteht aus ABS und war noch fest. Das Türmchen wurde im geschlossenem Bauraum mit ABS gedruckt, für das PETG war es wohl etwas zu heiß.
Nun kann ich nicht mit absoluter Sicherheit sagen, ob das schiefe Türmchen von Pisa eine Folge der verzogenen Klammer oder eines Fehlers in Klipper war.
Ich hätte die Angelegenheit noch weiter untersucht, wenn nicht noch weitere Probleme aufgetaucht wären.
Immer wieder nach einigen Stunden (bisher nur nach einem Druck, nicht während eines Drucks) hat sich Klippy aufgehangen. Der Drucker ließ sich nicht mehr ansprechen, die Firmware, Klippy und was sonst noch alles mitläuft ließ sich softwareseitig nicht neu starten. Der einzige Weg ist ein harter Reset: Schalter aus - Schalter ein - geht wieder... für einige Zeit.
Als wäre das noch nicht genug, steigt der USB - LAN-Adapter immer wieder aus und lässt sich nur durch einen Neustart von Windows wieder zum Dienst überreden.
Allgemein sind, selbst wenn alles funktioniert, die Reaktionszeiten von MainsailOS im Browser katastrophal: Häufig muss ich mehrere Sekunden nach einen Tastedruck warten, bis der entsprechende Befehl umgesetzt wird.
Bei Repetier Server dagegen läuft alles ohne Verzögerung.
Alles in Allem, auch wenn die Druckergebnisse sicher für sich sprechen, will ich doch hier das Thema Klipper erst mal für mich abhaken.
In der Summe sind es zu viele Fehler, zu viele Unwägbarkeiten, die dem dauerhaften, störungsfreien Betrieb entgegenstehen.
Vielleicht findet irgendwann das Input-Shaper-Feature noch seinen Weg in Marlin oder Repetier, was dann ohne Raspberry funktioniert.
In diesem Forum dürfen leider nur registrierte Teilnehmer schreiben.