Unsaubere Ecken beim Drucken (alle Slicer betroffen?)

[rf1k_mjh11]

Hallo allerseits,

Die inhaltliche Erklärung gibt's wie gesagt in Post #13.

Für alle die sich das zu Herzen nehmen, bitte auch die Entgegnung dazu in Post #15 durchlesen.

Danke,

mjh11

[rf1k_mjh11]

Hallo,

Es geht weiter mit der mathematischen Beweisführung.

Für jene, die es gerne einmal selbst nachrechnen wollen, habe ich eine neue Testdatei kreiert. Diese STL-Datei hat einige 50mm lange Seiten, einige mit 1mm und einige mit 51mm. Ich wollte sehen, ob die Extrusionsmenge für die Gerade mit 51mm so viel ausmacht, wie die Summe von der 50mm Geraden zusammen mit der 1mm Geraden. Das würde mehrfach bestätigt. Es gibt eine Diskrepanz von 0.00001mm, wo ich einen Rundungsfehler vermute.
Alle die das gerne nachprüfen möchten, können gerne die STL slicen oder einfach den GCode aus PrusaSlicer durchackern. Oder noch einfacher, die Textdatei durchlesen, die auch dabei ist (mit Namen SecondCalculationTest.txt).

SecondCalculationTest.zip

In der Textdatei wurde der GCode eines Layers herauskopiert (der 2. Layer) und jede Zeile von mir kommentiert, und der E-Wert errechnet.

Falls man selbst slicen möchte, sollte man alle gefinkelten Sachen deaktivieren (Retract, Füllung, unterste und oberste Lage, Elefantenfuß, usw.) und Perimeter auf 1 stellen. Da tut man sich viel leichter.

mjh11

[AtlonXP]

Hallo rf1k_mjh11,
ich bin bei diesem Thema raus, da ich keinen Mehrwert sehe.

LG AtlonXP

[mhier]

Hallo allerseits,

Die inhaltliche Erklärung gibt's wie gesagt in Post #13.

Für alle die sich das zu Herzen nehmen, bitte auch die Entgegnung dazu in Post #15 durchlesen.

Danke,

mjh11

Du gehst in #15 nicht darauf ein, dass es diese Überschneidung in Wirklichkeit gar nicht gibt.

[rf1k_mjh11]

Hallo,

Ich mache noch einen Versuch, da ich der Mathematik vertraue. Aber einen Gedankenfehler kann man nie ausschließen.
Ich habe nochmals versucht, aus mhiers Beitrag herauszulesen, wo sich unsere Meinungen unterscheiden.

Da ich bei mhiers Beitrag nur auf seine schriftliche Beschreibung bauen kann, wird es etwas schwierig. Ich vermute aber, der Unterschied liegt daran, wie man sich die Raupe am Ende eines Pfads (bzw. der Ecke) vorstellt.
Hier spielen zwei Aussagen (für mich) eine Rolle:

Wenn das Hotend eine infinitesimale Strecke fährt, wird eine infenitisemiale Menge Material an die bisher gedruckte Raube in Fahrtrichtung drangedruckt. Das ist so, wenn das Hotend ganz normal gleichmäßig geradeaus fährt, und das ist genauso, wenn es gerade um eine 90-Grad-Kurve gefahren ist.

(wobei ich denke, er meinte 90° Ecke, denn Kurven werden in diesem Thread nicht angesprochen)

und

Stell dir vor, das Material wird nicht in einem Kreis um den Mittelpunkt der Düse extrudiert, sondern auf einer Linie (infinitesimale Fläche!) senkrecht zur Fahrtrichtung, deren Länge dem Düsendurchmesser entspricht und deren Mitte mit dem Mittelpunkt der Düse zusammenfällt.

Mit der ersten Aussage stimme ich, ohne nachdenken zu müssen, überein. Mit der zweiten bedurfte es mehr Hirnschmalz, da gedanklich schwerer nachvollziehbar. Inzwischen habe ich mich damit ein wenig angefreundet. Es handelt sich bei der zweiten Aussage um eine Vereinfachung, ein Werkzeug, dass ich auch häufig einsetze.

Vereinfachungen helfen, komplexe Zusammenhalte leichter 'verdaulich' zu machen. Leider können Vereinfachungen gelegentlich auch zu Problemen führen. (So wie ein jeder Vergleich auch hinken möge.) Man muss einfach Vorsicht walten lassen. Und noch was: auch meine Darstellung ist im Prinzip eine Vereinfachung, womit sie, wie alle anderen Vereinfachungen, der 'Hinkgefahr' ausgesetzt ist. Keine der beiden Ansichten ist völlig richtig. In Wirklichkeit läuft es komplexer ab. Aber Vereinfachungen sind zulässig.

Widmen wir uns also der vereinfachten Darstellung.
Da ich im Herzen Techniker bin, und mir im Studium eingebläut wurde "Die Zeichnung ist die Sprache des Technikers", kommt jetzt eine Zeichnung zur Verdeutlichung der Situation.
Laut der Vereinfachung würde das Ende einer geraden Raupe, am Ende eines Pfads, egal ob vor einer Ecke oder tatsächlich am Ende eines Umrisses, ungefähr so aussehen müssen (Hinweis: dunkelrot ist der Pfad, rosa die Raupe):

Simplification_1.jpg

Die Raupe muss, der Vereinfachung nach, exakt am Ende des Pfades aufhören. (Bitte ignoriert den Anfang des Pfades, das tut hier nichts zur Sache, oder stellt euch vor, sie liegt unendlich weit entfernt.) Die Raupe muss dort, exakt am Ende des Pfades, aufhören, denn das Material wird "auf einer Linie (infinitesimale Fläche!) senkrecht zur Fahrtrichtung" deponiert. Soweit habe ich kein Problem damit. Aber, dafür müsste das Ende der Raupe aussehen, wie im obigen Bild, wenn man der Vereinfachung konsequent folgt.
Wie ich mir die Raupe vorstelle, sah man bereits im ersten Beitrag im Thread. Sie hat ein rundes Ende:

Horiz_bead.jpg

Ich habe GCode Daten vom Slicer, die diese Form unterstützen. Die GCode Daten unterstützen die vereinfachte Form jedoch keinesfalls. Macht aber nichts.

Im vereinfachten Modell käme neues Material so hinzu:

Simplification_1a.jpg

Bei mir, mit einem runden Ende, sähe das so aus:

Horiz_bead_a.jpg

Die zwei Flächen (bzw. multipliziert mit der Layerhöhe ergäbe das das Volumen) sind gleich groß. Sie haben nur eine andere Form.

Nun aber zurück zur vereinfachten Darstellung des Extrusionsvorgangs (das erste Bild im Beitrag).

Jetzt geht es mit der Raupe um 90° gedreht weiter, also ‚um die Ecke‘. Wie gesagt, das vereinfachte Extrusionsmodell schreibt eine Deponierung "senkrecht zur Fahrtrichtung" vor. Und wir müssen konsequent bleiben mit der Vereinfachung. Damit sieht die zweite Raupe dann so aus (hier ist nur die Raupe (in grün) gezeichnet, den Pfad muss man sich vorstellen – hoffentlich keine zu große Aufgabe!):

Simplification_2.jpg

Auch hier gibt es, wenn man genau hinsieht, eine Überschneidung. OK,

... das Material quetscht sich dann aber schon an die richtige Stelle …

Also keine Sorge. Ich habe auch schon die richtige Stelle gefunden! Diagonal gegenüber. Sieht dann so aus (hellblau):

Simplification_3.jpg

Leider bezweifele ich, dass irgendein FDM Drucker imstande ist, solche scharfen Außenecken abzubilden wie hier im Bild. Da wird auch Pressure Advance nichts helfen (falls aber doch, sattele ich sofort auf Klipper um).

Unbestritten ist, dass es mit der FFF (FDM) Methode keine scharfen Außenecken gibt. Damit sind wir wieder dort, wo wir schon einmal waren (bitte das gelbe Stück beachten!):

Simplification_4.jpg

In gelber Farbe ist also das Stück dargestellt, dass unbestritten mit der hier angewendeten Fertigungsmethode nicht möglich ist. Somit muss es sich um eine Überextrusion handeln, die anderweitig ihren Platz suchen muss.

Interessanterweise ist das gute (gelbe) Stück flächen- und formmäßig ident mit dem meiner aufgedeckte Überschneidung, bloß an anderer Stelle dargestellt.

Womit ich abschließend behaupte: auch die Vereinfachung kommt auf meine Überschneidung exakt hin, bzw. beweist diese.

Sicherheitshalber zitiere ich mich hier jedoch selbst wieder:

Aber einen Gedankenfehler kann man nie ausschließen.

Auch ich bin dagegen nicht gefeit. Vielleicht denke ich hier doch noch immer falsch?

mjh11

[rf1k_mjh11]

Hallo,

Zurück zum ursprünglichen Problem.

Einige weitere Bemerkungen. Den Korrekturwert, den ich am Ende von diesem Beitrag angab (bei 0.4mm Raupenbreite, 90° Ecke) mit dem Betrag von 0.00858 entspricht der Fläche, die doppelt belegt ist, keinesfalls in irgendeiner Weise einem E-Wert.

Um auf die eigentliche Korrektur zum angegebenen E-Wert zu kommen benötigen wir zusätzlich:
a) Die Layerhöhe
b) Den Filamentdurchmesser
c) Den Extrusion Multiplier (=Material Multi)

Die Fläche von 0.00858 muss mit der Layerhöhe multipliziert werden, um auf ein Volumen zu kommen. Das Volumen muss durch die Fläche des Filaments dividiert werden, um auf eine Extrusionslänge zu kommen. Diese Länge wird mit dem Extrusion Multiplier multipliziert um auf einen pseudo-E-Wert zu kommen.
Was macht man mit dem pseudo-E-Wert?
Diesen E-Wert kann man nicht einfach vom bereits vom Slicer errechneten E-Wert abziehen, denn da würde der Drucker den geringeren Wert einfach über die gesamte Strecke verteilen und es bliebe immer noch ein Großteil des Problems vorhanden, abgesehen davon, dass auf der restlichen Strecke jetzt eine Spur Material fehlen würde.

Nein, man müsste die bisherige Strecke zwei-, drei- oder vierteilen. Den letzten Teil der Strecke würde ab der halben Raupenbreite vom Eckpunkt beginnen und könnte (beinahe) unverändert bis zur nächsten Ecke laufen. Es müsste nur der errechnete E-Wert auf die verkürzte Länge angepasst werden (Klar oder? Die Strecke wird kürzer, da muss auch weniger extrudiert werden.). Für den Beginn der Strecke, unmittelbar nach der Ecke, könnte man 1, 2 oder mehrere Stufen vorsehen, mit jeweils zunehmendem E-Wert, deren Summe nicht größer ist als "(E-Wert für die ‘Strecke von der halben Raupenbreite‘ minus dem pseudo-E-Wert)". Mit nur einem Korrekturwert (eine Stufe) würde die Extrusionsmenge über den Verfahrweg in etwa so aussehen (mit der dunkelblauen Linie dargestellt):

CornerCorrection_1Step.jpg

Nur eine Stufe entspricht einer Zweiteilung der Strecke. Mit diesem Ansatz wäre es nur wenig besser als wenn man gar nichts tut. Dafür ließe es sich aber sehr leicht in die Slicer-Mathematik einbinden. Schon zwei Stufen könnten der ansteigenden Kurve viel gerechter werden, verlangen aber mehr Mathematik.

Nachträglich was zu machen verbietet der Aufwand; sämtliche Perimeterecken müssten nachgerechnet und korrigiert werden. Die Eckenkorrektur ist auf jeden Fall die Aufgabe des Slicers.

mjh11

[mhier]

Ok jetzt verstehe ich langsam was du meinst. Du sprichst nur von dem kleinen Zwickel. Deine Annahme ist, das Material landet nicht in der äußeren Ecke sondern woanders (wo eigentlich genau und warum?).

Was ich erstmal nicht verstehe: Wie willst du derart kleine Effekte denn überhaupt sehen? Das was Advance da kompensiert, ist locker 10 bis 20 mal so viel, du benutzt Advance aber ja anscheinend gar nicht. Da geht das doch komplett unter, wie willst du das auseinander halten? Ich vermute, das sind selbst mechanische Ungenauigkeiten noch größer, oder auch die Ungenauigkeiten in den Stepper-Motoren (hast du noch die Original-Wantei-Motoren verbaut?). Bezogen auf das Quadrat in der Ecke (90 Grad angenommen) hat der Zwickel eine Fläche von knapp 7%. Pressure Advance kann locker über 100% Unterschied machen! Selbst wenn du sehr gemütlich beschleunigst, wird das immer noch größer sein.

Meiner Beobachtung nach können Ecken bei korrekt eingestelltem Advance sehr sauber und eckig werden, insbesondere ohne irgendwelche Ausbeulungen. Die Schlussfolgerung wäre also, dass Material aus dem kleinen Zwickel, den du hier als Überlapp deklarierst, weitestgehend korrekt in der äußerem Ecke landet. Vergiss nicht, dass das Material beim Extrudieren flüssig ist und dass weitere Effekte wie z.B. Oberflächenspannung eine Rolle spielen. Im Bereich der Größe der Düsenöffnung ist es nicht wirklich durch die Düsenposition bestimmt, wo das Material landet. Wenn von den knapp 7% sagen wir die Hälfte in der besagten Ecke korrekt landet und die andere sich unsauber irgendwo außen verteilt, wird die Raupe an der Stelle halt 1% nach außen zu breit oder so. Das ist die Größenordnung, über die wir hier sprechen. 1% von 0.4mm sind 0.004mm = 4um. Lass es 10um sein, so genau arbeitet der Drucker ohenhin nicht, schon gar nicht mit den Wantei-Motoren (sofern meine Exemplare denn keine Ausreißer sind). Deine "Simulation" im Eingangspost übertreibt den Effekt also vermutlich so um einen Faktor 100.

Du deklarierst hier ständig Pressure Advance als off-topic, aber die Probleme sind nun mal verbunden. Solange du den großen Effekt nicht im Griff hast, bringt es doch nichts, dich um den kleinen zu kümmern. Solange du das nicht sauber im Griff hast, wird auch kein Slicer-Entwickler die Problematik ernst nehmen.

Wenn du dich der Pressure-Advance-Problematik mal annimmst, wirst du schnell feststellen, dass deine realen, beobachtbaren Probleme gelöst sind und dieses hier entweder nicht existent oder wenigstens bedeutungslos ist.

[rf1k_mjh11]

Hallo,

Nachdem es um den Thread wieder recht ruhig geworden ist, hier wieder ein paar unnütze Informationen.
Die Überschneidungsfläche (aus dem, mit der Layerhöhe und dem Extrusion Multiplier, ein Extrusionsvolumen wird) kann für jeden beliebigen Winkel wie folgt errechnet werden:

Vorgaben:
B: die Raupenbreite
α: Eingeschlossener Winkel (bei stumpfem Winkel ist dieser >90°, bei spitzem <90°)
ÜF: Überschneidungsfläche (diese wird gesucht)

ÜF = 2*((B/2)² * tan(90- α/2)/2 – B² * π/4/360*(90- α/2))
(Ich behaupte nicht, dass es sich hier um die ‘sauberste’, eleganteste oder kürzeste Formel handelt – sie entstand einfach aus der Betrachtung der Überschneidungsfläche.)

Sehen wir uns eine Überschneidung an. Hier unter einem leicht spitzen Winkel:

Overlap_Area.jpg

Die Überschneidungsfläche ist gelb umrissen. Der eingeschlossene Winkel α liegt etwas unter 90°.

Legt man eine Symmetrielinie an, kann man zwei kongruente rechtwinklige Dreiecke erkennen:

baseTriangle.jpg

Oder hier, etwas deutlicher hervorgehoben:

2Triangles.jpg

Eine der Dreiecksseiten, die Ankathete, wird durch die halbe Raupenbreite ‘B‘ gebildet. Die Gegenkathete entpricht dem Tangens des Winkels (90°- α/2) mal der halben Raupenbreite.

Die Fläche eines Dreiecks errechnet sich aus ‘Seite mal Höhe durch 2‘. Da es sich um ein rechtwinkliges Dreieck handelt, ist die Fläche des Dreiecks leicht zu errechnen: Ankathete mal Gegenkathete durch 2.

Damit hätte man die Fläche des Dreiecks. Davon muss noch die Fläche des Kreissektors (oder Kreisausschnitts) abgezogen werden.

Die Fläche des Kreissektors errechnet sich aus der Kreisfläche durch 360° mal dem Winkel, in diesem Fall (90°- α/2).

Nach Abzug des Kreissektors hätte man exakt die Hälfte der Überschneidungsfläche. Daher ist das Ergebnis zu verdoppeln.
So habe ich die obige Formel erarbeitet.

Man kann mit der Formel die Überschneidungsfläche an Ecken mit einem beliebigen Winkel errechnen, theoretisch. Man muss sich jedoch bewusst sein, dass Slicer ab einem gewissen spitzen Winkel die Pfade nicht mehr so rechnet, wie man erwartet. Auch hängt es von der verwendeten Slice-Methode ab. PrusaSlicer (und Slic3r?) erlauben den Einsatz der ‘Arachne-Engine‘ beim Slicen. Da kann ganz was unerwartetes herauskommen.
Hier, zum Beispiel, ein spitzer Winkel konvetionell geslicet:

SlicedConvetional.jpg

Und dasselbe, mit der Arachne-Engine:

SlicedArachne.jpg

Mit der Arachne-Engine wird eine kleine zusätzliche Ecke eingebaut. Ob dabei die Überschneidung berücksichtigt wurde, ist mir nicht bekannt.
‘Schlimmer‘ wird es bei noch spitzerem Winkel:

AcuteAnglesSliced.jpg

Man sieht, dass mit der Arachne-Engine bei sehr spitzen Winkeln sogar eine eigene Spitze dazu extrudiert wird, wo die Raupenbreite stufenweise abnimmt (siehe Ecke mit ‘20°‘ bezeichnet).

Sich nicht auf das Gesehene verlassen

---

Man darf sich auf die grafische Darstellung der Raupen, weder im Slicer, noch unter Repetier-Host, verlassen. Die Darstellung ist eine Vereinfachung und entspricht nicht unbedingt der Wirklichkeit. Zur Sicherheit sollte man immer den GCode selbt betrachten. Siehe dazu auch diesen Beitrag

Bei spitzen Winkeln steigt die Überschneidungsfläche rapide an. Bei einem Winkel von 70°, zum Beispiel, ist die Fläche bereits mehr als doppelt so groß wie bei 90°, bei 50° sogar fast das fünffache an Fläche (und damit an Volumen).

Falls ich hier mathematisch einen Bock geschossen habe, lasse ich mich gerne belehren.

mjh11

[rf1k_mjh11]

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

[AtlonXP]

Ok, somit steht es 1:0 für dich!
Da du leider in der Praxis keinen Unterschied nachweisen kannst, steht es so mit 1:1.

Aber nun hast du mich neugierig gemacht.
Deine Einstellungen für diesen Test bezeichne ich mal wieder als brachial!
So würde ich nie drucken!

Dennoch werde ich mich der Sache bei Gelegenheit annehmen, mit Druckparametern,
wie ich sie verwende.

Mal schauen, ob bei mir ein Unterschied zu erkennen ist.

LG AtlonXP