Der Thread hier findet vorläufig ein Ende. Die ursprüngliche Prämisse, Slicer würden die Ecken falsch berechnen, ist widerlegt.
Die Story (na, habt ihr was anderes erwartet?):
Ich hatte noch 2023, am 31. Dez., auf der
slic3r github-Seite einen Bug-Bericht wegen der falschen Ecken-Berechnung eingereicht. Mehrere Wochen tat sich nichts (verdienter Weihnachtsurlaub?). Dann endlich eine eMail mit dem Hinweis, die Lösung wäre bereits implementiert, samt einem Link (
90b129e).
Der Link führte tatsächlich zu einem Abschnitt des Quellcodes, wo das Problem an den Ecken behandelt wird. Dieser Code wurde bereits 2020 geschrieben ('committed'). Damit, dachte ich, müsste es in slic3r 1.3.0 und in praktisch allen PrusaSlicer Versionen vorhanden sein. Bloß konnte ich es in PrusaSlicer nicht finden oder nachweisen. Also slicete ich mein Probestück ein weiteres Mal, extra in slic3r 1.3.0, und prüfte den GCode. Wieder erfolglos. Allerdings stand im Quellcode auch
external_perimeter_cut_corners setting
it reduce the flow around corners, depending of the angle.
experimental status! not tested yet!
Also musste eine eMail an die Person gesendet werden, die vorhin antwortete, mit der Frage, wie ich denn so eine Einstellung aktivieren könnte. Nach einem Tag die Antwort: "Implementiert, aber nur in 'superslicer'. Dort kann man es testen." (
It's implemented in the 'superslicer' side of slic3r. You can test it with superslicer.)
So kam ich an
SuperSlicer. Ich stolperte zwar in meinen Recherchen bzgl. Eckenberechnung einmal über den Namen, wusste aber nichts Näheres.
Also wurde SuperSlicer heruntergeladen und gestartet. Obwohl es auf slic3r und PrusaSlicer aufbaut, beides Slicer mit denen ich bekannt bin, war die zusätzliche Vielzahl an Einstellungsmöglichkeiten anfangs (und noch immer) etwas verwirrend.
Trotzdem wurde schnell mein Musterstück geladen, geslicet und analysiert: es gab weiterhin
keine Kompensation für die Ecken. OK, denkt man sich, es liegt vermutlich an einer falschen Einstellung. Da habe ich die vielen Optionen durchgeackert und nichts gefunden.
Somit gab es noch eine eMail an
supermerill (vermutlich einer oder 'der' Programmierer von SuperSlicer). Dessen Antwort führte mich endlich an den richtigen Hebel: dieser heißt "
Cutting corners", was eigentlich so viel bedeutet wie Kurven schneiden, Abstriche machen, Einsparungen oder Kompromisse eingehen. Da habe ich beim Durchackern diese Option wegen der Bezeichnung einfach übersehen.
Musterstück wieder geladen und geslicet und siehe da: nach jeder Ecke gab es
zwei zusätzliche Wegstücke! Genau wie es im Quellcode beschrieben war:
//extrude in three steps: one short with big mult, one of nozzle size with the rest and then the normal one.
//it's a very rough approx of a cos.
Damit ist die Lösung in etwa so,
wie ich es mir vorstellte. Auf die Extrusionsmenge pro Millimeter umgelegt, sieht die Behandlung einer Ecke exakt so aus:
SuperSlicerFigures.jpg
Die Werte sind dem generierten GCode entnommen, der auf folgende Vorgaben basiert:
Raupenbreite 0.62mm
Layerhöhe 0.25mm
Filamentdurchmesser 1.753mm
Extrusion Multiplier (Material-Multi) 1.056
In der horizontalen Achse ist der Verfahrweg der Düse in Bezug auf das Druckobjekt aufgetragen. Die angefahrene/umfahrene Ecke ist exakt beim Wert 10 platziert (
willkürlich). Danach sind die Werte aber im Verhältnis zueinander korrekt. Das heißt, von der Ecke weg sind die ersten 0.155mm mit einem um 11% niedrigeren E-Wert versehen. Danach wird 0.31mm weiter verfahren, wo der E-Wert um 6% niedriger als normal ist. Danach steigt der E-Wert auf den normalen Wert an und bleibt so bis zur nächsten Ecke oder dem Ende des Pfads.
Grün gestrichelt dargestellt ist, wie ich mir in etwa vorstelle, wie sich der IST-Extrusionswert verhalten wird, durch die Elastizität und der Hysterese im System. (Das ist bloß eine Annahme! Kann auch total daneben liegen.).
Der senkrechte gelbe Strich stellt den Punkt dar, der im Verfahrweg der halben Raupenbreite nach der Ecke entspricht. Eigentlich ist bei einer 90°-Ecke das Überlappungsproblem exakt nach der halben Raupenbreite vorbei. Interessanterweise hat der Programmierer hier eine Formel eingearbeitet, die um einiges länger wirkt oder 'aktiv' ist.
Noch viel interessanter ist, dass ich
noch immer keinen Unterschied im gedruckten Teil sehe, egal ob die Option aktiviert ist oder nicht.
Generell sehe ich stärkere Beulen bei größeren Layerhöhen (es wurden 0.25mm und 0.5mm getestet). Aber auch da, für die jeweilige Layerhöhe, sind die Beulen jeweils ziemlich gleich, egal ob 'Kurve Kratzen' aktiviert ist oder nicht.
In den folgenden Bildern sieht man ein Ergebnis. Von links nach rechts sind jeweils 3x ohne Kurve Kratzen, 3x mit Kurve Kratzen, dann wieder 3x mit und 3x ohne, jedoch doppelter Layerhöhe. Das bildliche Einfangen der Beulen ist schwierig. Daher 4x dieselben Teile, immer aus leicht geänderter Blickrichtung.
#1_IMG_20240126_123152.jpg
#2_IMG_20240126_123156.jpg
#3_IMG_20240126_123207.jpg
#4_IMG_20240126_123211.jpg
Es wurde jeweils gleichzeitig 3x das gleiche Objekt gedruckt mit:
2 Umrissen (aber ohne Füllung, Boden oder Deckel).
Düse 0.6mm, einmal mit 0.25mm, einmal mit 0.5mm Layerhöhe.
Raupenbreite durchwegs mit 0.62mm.
Die Geschwindigkeit war zwar mit 50mm/s angegeben, aber die kurze Layerzeit (trotz der 3 Stück gleichzeitig) war mit 13 Sekunden recht kurz und dürfte bereits vom Slicer im Vorhinein verlangsamt worden sein.
Beschleunigungswerte X&Y waren beim Druck mit 4000mm/s/s vorgegeben (Leerfahrten mit 5000mm/s/s).
Als Material kam PETG zum Einsatz.
Die Temperatur war mit 254°, wie bei mir üblich, recht hoch (deswegen vielleicht die gelegentlichen Pickel an der Oberfläche).
Die Teile in den Bildern sind alle gleich ausgerichtet. Die vordere Ecke, die auf dem Tisch aufliegt, war dort, wo der Pfad jeweils begann. Somit ist die Ecke zuoberst im Bild immer die zweite Ecke, die abgefahren wurde.
Für die besonders pingeligen unter euch: Interessant ist, wie sich die Ecken bei 0.5mm Layerhöhe nach oben ziehen. Zu Bedenken gilt: bei 0.6mm Düse entsprechen 0.5mm Layerhöhe bereits
mehr als 83% des Düsendurchmessers.
Abschließend ist noch zu bemerken, dass ich doch nicht der erste war, dem der Rechenfehler auffiel
. Andererseits dauerte es bis 2020 bis irgendeiner daran dachte. Also haben zig Programmierer, User und sogar Physiker das Problem jahrelang einfach übersehen (ein Jahrzehnt zumindest).
Nachdem ich von 2011 bis 2020 (und sogar bis spät in 2023) fleißig gedruckt habe, ohne zu schnallen, dass es hier einen Rechenfehler gibt, sollte ich mir vielleicht in den Hintern beißen, oder?
Leider gibt es bis dato nur SuperSlicer, der den Rechenfehler programmtechnisch zu beseitigen sucht. Bleibt zu hoffen, dass slic3r und PrusaSlicer diese Änderung irgendwann in ihre Versionen einarbeiten. Die Sorge besteht besonders deshalb, da mhier treffende Argumente
angibt, wieso das längerfristige Bestehen von SuperSlicer in Frage gestellt werden könnte.
Na ja, die Hoffnung lebt. Nur dieser Thread dürfte damit gestorben sein.
mjh11