Unsaubere Ecken beim Drucken (alle Slicer betroffen?)

[rf1k_mjh11]

Hallo,

Zu AtlonXPs Beitrag komm gleich nachher. Zuerst zu mhiers Argumenten:

Hallo mhier,

Ich kann mir das irgendwie nicht vorstellen, schon gar nicht für alle Slicer.

Eben deswegen warte ich schon darauf, dass jemand hier im Forum das in S3D nachprüft. Es ist ja nicht so, dass ich die Bitte allzu sehr geheim gehalten hätte.

Interessant wäre, ob ein käufliches Programm wie S3D dies tut. Nett wäre es, wenn sich einer mit S3D die Arbeit antut und dies überprüft.

Und

Und noch immer hat sonst keiner nachgerechnet, ob der Slicer falsch arbeitet.

Dann: Es ist ja eine Beobachtung, dass der Effekt geringer wird, wenn die Beschleunigung herabgesetzt wird

Tut mir leid, meine Beobachtung von gestern hat ein gegenteiliges Ergebnis gebracht. Ein möglicher Grund könnte sein, weswegen ich deiner Aussage zugestimmt habe:

Übrigens denke ich, dass es gewisse "magische" Beschleunigungen gibt, bei denen das Problem nicht so deutlich wird wie bei anderen Beschleunigungen.

wobei ich hinzufügen möchte, dass es ebenso "magische" Beschleunigungswerte gibt, wo das Problem deutlich schlimmer wird (obwohl die Werte niedriger liegen). Hiermit kann ich dann deine eigene Aussage an dich richten:

Damit ist deine Erklärung im Grunde widerlegt…

Jedoch gebe ich (und gab ich) zu:

druckt man langsamer oder mit geringerer Beschleunigung, wirken sich gewisse dynamische Effekte anders aus

Dass diese gewissen dynamischen Effekte einmal das Problem verbessern oder beseitigen oder gar verschlimmern können, streite ich nicht ab. Ich bleibe dabei, dass mit Beschleunigungswerten und Pressure Advance bestenfalls ein Symptom (‘Beulen an der Ecke‘) bekämpft wird, nicht aber die Ursache.

Umgekehrt ist physikalisch klar, dass es den Effekt gibt, der mit Advance korrigiert wird. Es geht dabei eben genauso um die Materialmenge, die zur falschen Zeit am falschen Ort gefördert wird. Letztlich wird das Material zeitlich verzögert gefördert, was abhängig von der momentanen Geschwindigkeit sich dann in eine Material-Deposition am falschen Ort übersetzt. Das Symptom ist sehr ähnlich. Du brauchst also sehr gute Argumente, warum sich der von dir beobachtete Effekt nicht durch die Stauchung des Filaments und die daraus resultierende Verzögerung deer Extrusion erklären lässt.

OK, sehen wir uns Pressure Advance an, und wie es ein Problem zu begegnen versucht (wobei das Problem nicht das der Beulen an den Ecken ist), (übrigens ein Dank an die Klipper3d.org-Seite):

PressureAdvanceGraph1.jpg

Die rote und grüne Linie stammt von mir. Die obere Kurve zeigt die Relativbewegung der Düse zum Druckobjekt.

Die Duese faehrt

---

Der Einfachheit halber schreibe ich ab jetzt "die Düse fährt", obwohl beim RFx000 für Bewegungen in Y Richtung sich das Druckobjekt bewegt und nicht die Düse.

Die zweite Kurve zeigt die theoretisch benötigte Filamentmenge.
Die dritte Kurve stellt eine Annahme dar, wie die tatsächliche Filamentmenge (über der Zeit) aussehen könnte. Sie beruht auf der Tatsache, dass das Filamentfördersystem eine gewisse Elastizität aufweist und wie eine Feder wirkt. So weit, so einleuchtend.

Wenn also eine Ecke umfahren wird müsste sich das Folgende abspielen (Hinweis: Die senkrechte rote Linie stellt den Punkt an der Ecke dar, wo die Düse kurzzeitig (fast?) zum Stillstand kommt (im Verhältnis zum Druckobjekt), also die Ecke selbst.
Zuerst fährt die Düse mit konstanter Geschwindigkeit (von links nach rechts entlang der horizontalen Linie, oben) bis sie den Punkt erreicht, ab dem abgebremst wird (die steil abfallende Linie). Bis zum ‘Abbremspunkt‘ wird das Filament mit einer konstanten Geschwindigkeit gefördert. Alles schön konstant, somit alles in Butter.
Ab dem Abbremsen, noch vor der Ecke, kommt (laut der dritten Kurve im obigen Bild) zu viel Filament aus der Düse (siehe den Unterschied zwischen der schwarzen ‘Schi-Schanze‘ und der grünen Linie beim Erreichen der roten Linie). Die Idee dahinter ist, dass sich das System wie eine Feder etwas entspannt.
Der wichtige Punkt dabei: Das geschieht alles noch vor dem Erreichen der Ecke. Es wird somit, laut der Theorie auf dem Pressure Advance beruht, schon vor der Ecke zu viel Material gefördert.
Interessanterweise sind bei mir die Beulen beinahe allesamt nach der Ecke. Gibt es dazu eine verständliche Erklärung?

Klipper, mit Pressure Advance, möchte diesem theoretischen Materialüberschuss begegnen, indem schon vor dem Abbremspunkt der Förderdruck reduziert wird:

PressureAdvanceGraph2.jpg

(Die roten Buchstaben, A, B, C, stammen von mir.)
Hier muss man sich dazu die grüne Kurve ansehen. Wie man erkennen kann, wird noch vor dem ‘Losfahren‘ schon gefördert (damit der Druck aufgebaut wird, bei Punkt ‘A‘) und ebenso vor dem Abbremsen die Fördermenge reduziert, um den Druck abzubauen (bei Punkt ‘C‘ und teilweise bei ‘B‘). Der Kurve nach müsste ich bei meinen Ecken jeweils vor der Ecke eine Lücke oder Einfallsstelle haben und nach der Ecke eine noch größere Beule haben als ich schon habe. Denn es wird nach der Ecke zusätzliches Material gefördert, wo ich doch jetzt, ohne Pressure Advance, schon zu viel Material habe.
Der Punkt ‘B‘ zeigt gut die Situation an einer Ecke. Hier dürfte es sich um eine Ecke mit stumpfen Winkel handeln (vielleicht 120 oder 135°). Noch vor der Ecke wird Druck reduziert, genau an der Ecke dürfte der Druck in etwa entsprechen, aber bereits kurz nach der Ecke wird der Druck übermäßig erhöht (hier kann man jeweils das Wort ‘Druck‘ durch ‘Fördermenge‘ ersetzen).
Hier wird eindeutig nach der Ecke die Fördermenge erhöht, wo doch jetzt schon, ohne Pressure Advance, eine Beule entsteht.

Vielleicht beruht das alles auch auf einen Gedankenfehler?

Mir fällt noch etwas ein: Wenn du ein Rechteck druckst, sollten die 4 Seiten des Rechtecks jeweils einen G-Code-Befehl ergeben (nicht mehrere). Wenn du recht hast und der Slicer nicht berücksichtigt, dass die Ecken einen Überlapp haben, führt das in dem Fall nicht zu einer Überextrusion nur genau in den Ecken, sondern zu einer gleichmäßigen (!) Überextrusion des gesamten Rechtecks, also auch auf der geraden Strecke.

Hier handelt es sich ziemlich sicher um einen Gedankenfehler.

Ja, der Slicer errechnet sich ein Fördervolumen aus, das der Förderstrecke, Raupenbreite und Layerhöhe entspricht. Und es handelt sich im Normalfall dann nicht um eine Überextrusion. Geschehen tut die Überextrusion dann nicht über die gesamte Länge, sondern nur genau dort, wo bereits Material ist (und es somit kein Platz für neues Material gibt) und das extrudierte Material daher von der vorgesehenen Bahn abweichen muss.
(Gedankenfehler: Ich könnte genauso gut sagen, Pressure Advance bringt nichts, denn das zusätzliche oder fehlende Material wird ja eh‘ gleichmäßig über die gesamte Länge aufgeteilt.)

Es gitb also 2-3 Argumente, die gegen deine Theorie sprechen... Selbst wenn deine Theorie richtig ist, kann sie nicht die beschriebenen Symptome erklären.

Habe noch kein richtiges Argument gelesen. Sorry.

Du kannst aber gerne selbst nachrechnen. Meine Idee mit der GCode-Analyse war:
Die Korrektur einer Eckenüberschneidung (wie ich sie gezeigt habe), wäre für einen gewissen Eckenwinkel immer gleich, also ein konstanter Wert. Die Ecken vom Probestück waren alle 90°. Somit müsste der Korrekturwert für alle Ecken gleich sein. Egal ob ich sage, ‘pro Ecke kommt die Hälfte der Korrektur vor und die Hälfte nach der Ecke‘ oder ‘es kommt immer die volle Korrektur nach der Ecke‘ – egal, es käme insgesamt immer nur eine Korrektur pro Seite vor.

Mit diesen zwei Annahmen ( #1: es handelt sich um einen konstanten Wert und #2 diese kommt nur einmal pro Seite vor) kann man rechnerisch feststellen, ob ein Korrekturwert existiert.
Auf der Extrusionsmenge eines langen Pfads (50mm) würde sich ein konstanter Korrekturwert prozentuell weniger stark auswirken wie auf die Extrusionsmenge eines kurzen Pfads (1mm).
Bei meiner Recherche kam ich auf einen Korrekturwert von 0 (Null).

Du kannst gerne selbst nachrechnen. Beim Nachprüfen aber den Anfangspfad/Endpfad nicht zur Berechnung hernehmen, da dieser anders abgearbeitet wird.

mjh11

Abgesehen davon ist Pressure Advance beinahe so Off-Topic wie Beschleunigungswerte oder gar Retract (siehe nächsten Beitrag)

[rf1k_mjh11]

Hallo AtlonXP,

Ich hatte hierzu geschrieben, dass mir am Kringelende Material fehlt.

Tut mir leid. Mein Fehler .
Wenn dir am Ende das Material ausgeht, dann könnte dein 'Coast at end' Wert zu groß sein. Da wird so lange ohne zu fördern gefahren, bis die Düse leer ist und dann noch darüber hinaus.

Falls du dieser Sache weiter nachgehen möchtest, schlage ich dir folgendes vor:
Mach erst mal „deretraction extra length“ mit 0,0002mm heraus.

Hier ein Gedankenfehler deinerseits. De-retraction kommt nur nach einer Retraction vor. Nachdem ich ein Problem anspreche, dass bei 'durchgefahrenen Ecken' vorkommt, gibt es kein Retract oder De-retract und somit hat das gar nichts mit den Beulen an den Ecken zu tun, die ich hier anspreche.

Ich stelle mir hier dir Frage, läuft der Extruder hier noch Synchron zu den Achsen?

Gute Frage. Ich habe elektronisch wenig am Hut. Vermutlich ist daher was ich jetzt sage völliger Blödsinn. Aber ich könnte mir vorstellen, dass es wie ein Bus-System aufgebaut ist. Wenn der Controller das Signal auf den Bus legt, fährt der Motor. Damit wäre sie recht leicht synchron zu halten. (Wie gesagt, kreuzigt mich nicht! Ich weiß wenig darüber.) Vielleicht meldet sich ein anderer, der Bescheid weiß.

Darum empfehle ich nicht schneller wie 28 mm/s zu fahren.

Jetzt verstehe ich wieso du insgesamt 3 RFx000 und einen TronXY dein eigen nennst. Um einen Zahnstocher zu drucken musst du ein Wochenende einplanen.
Ich fahre gefühlsmäßig langsam (mit 50-60mm/s). Allerdings fahre ich mit Ninjaflex tatsächlich so um die 23-35mm/s.
Andererseits ist für mich die 'sichtbare' Qualität selten ein Argument. Funktion geht über Aussehen.

Häh

---

Was, das optische Aussehen ist zweitrangig? Wieso investierst du, mjh11, soviel Zeit in die klitzekleinen Beulen an den Ecken?

Sorry, ich bin nun mal so.

Vergleiche das Druckergebnis der Conrad Version und der Community FW.

Das ist ungefähr das vierfache an Arbeit, die du hättest, mit S3D meine These nachzuprüfen. Soll ich tatsächlich die Firmware aufspielen, stundenlang herumdoktern, nur um zu sehen, dass die Ecken Beulen aufweisen. Und nebenbei, was das Filament kostet! Wenn du mit S3D zwei Ecken nachrechnest, kostet es nur Hirnschmalz und ein klein wenig Zeit.
(Ich schicke dir die STL per PN. Du brauchst es nur zu slicen und mir den GCode zukommen lassen (aber nicht in binär!) - und das wäre dann nur ein zwanzigstel der Arbeit, die ich hätte, meinen Drucker 2 Mal umzuflashen.)

Die Community FW ist sowiso die bessere!

Da wird aber mhier nicht zustimmen.

mjh11

[mhier]

Uff, du schreibst immer sehr lange Posts. Es ist schiwerig, darauf zu antworten, ohne dass der Thread hier komplett explodiert. Verzeihe mir deshalb bitte, dass ich mir nur einige Punkte herauspicke, die ich für wichtig halte, auch wenn ich andere Punkte nicht für unwichtig oder richtig oder was auch immer halte...

OK, sehen wir uns Pressure Advance an, und wie es ein Problem zu begegnen versucht (wobei das Problem nicht das der Beulen an den Ecken ist),

Ich verstehe die Klammer nicht. Die Beulen an den Ecken sind ein Symptom, das aus der Filamentstauchung durch die Extrusionskraft resultiert, und zwar das prominenteste. Ich streite erstmal nicht ab, dass es auch andere Effekte mit dem selben Symptom geben kann, aber dass Beulen aus der Filamentstauchung resultieren, ist doch unbestritten? Pressure Advance ist hierfür die korrekte Lösung. Mir ist nicht ganz klar, wogegen oder wofür du hier argumentieren möchtest.

Der wichtige Punkt dabei: Das geschieht alles noch vor dem Erreichen der Ecke. Es wird somit, laut der Theorie auf dem Pressure Advance beruht, schon vor der Ecke zu viel Material gefördert.

Gerade bei höheren Beschleunigungen aber moderaten Geschwindigkeiten passiert das alles mehr oder weniger in unmittelbarer Umgebung der Ecke. Es ist ja nicht so, dass der Drucker da über 1cm Strecke langsam abbremsen würde.

Interessanterweise sind bei mir die Beulen beinahe allesamt nach der Ecke. Gibt es dazu eine verständliche Erklärung?

Keine exakte, aber irgendwie wird da in der Ecke zu viel Material deponiert und es landet dann halt dort, wo es landet. Bei deiner Erklärung wird ja auch exakt auf der Ecke zu viel Material deponiert, da ist ja auch erstmal nicht klar, wo das landet. Grundsätzlich muss man noch bedenken, dass eine Überextrusion zu einer Stauchung des Filaments führt, was dann wiederum zu einer teilweisen Verzögerung der Überextrusion führt.

Vielleicht beruht das alles auch auf einen Gedankenfehler?

Also erstmal kann ich die Beobachtung anstellen, dass Pressure Advance in Klipper wunderbar funktioniert. Mit der Beobachtung stehe ich bei weitem nicht alleine, Klipper hat eine riesige Community und die meisten fortgeschritteren Nutzer werden Pressure Advance nutzen. Viele moderne Drucker sind auf hohe Geschwindigkeiten (erfordert hohe Beschleunigungen!) getuned und nutzen Klipper ab Werk. Da wird Pressure Advance dann noch deutlich wichtiger.

Ja, der Slicer errechnet sich ein Fördervolumen aus, das der Förderstrecke, Raupenbreite und Layerhöhe entspricht. Und es handelt sich im Normalfall dann nicht um eine Überextrusion. Geschehen tut die Überextrusion dann nicht über die gesamte Länge, sondern nur genau dort, wo bereits Material ist (und es somit kein Platz für neues Material gibt) und das extrudierte Material daher von der vorgesehenen Bahn abweichen muss.

Das ist falsch. Ich glaube wir kommen der Lösung näher. TL;DR: Der Slicer macht alles richtig.

Wir vereinfachen mal zum leichteren Verständnis die Vorgänge in einem einfachen Modell. Es gibt nur eine Geschwindigkeit, die Beschleunigung ist unendlich, und es gibt nur "extrusion" mit einer festen Geschwindigkeit oder "keine extrusion".

Was du sagst, übersetzt sich in unser Modell folgendermaßen:

Ich ziehe eine Linie in X-Richtung, stoppe die Bewegung und die Extrusion, und ziehe dann eine Linie in Y-Richtung. Dadurch habe ich (so deine Aussage) einen Überlapp in der Ecke, weil ich bei der gleichen Koordinate starte wie ich aufgehört habe.

Das ist aber überhaupt nicht anders zu der Situation, wenn ich dabei nicht die Richtung ändere. Also Linie in X-Richtung ziehen, Bewegung und Extrusion stoppen, dann in gleicher Richtung wie vorher weiter die Linie in X-Richtung ziehen.

Das wiederum ist ebenfalls identisch zu der Situation, wenn ich die Bewegung und die Extrusion zwischendurch gar nicht stoppe - das ist ja einfach nur Zeitverzögerung.

Die Extrusion passiert pro gefahrener Wegstrecke in der X/Y-Ebene. Es wird nicht an einem Punkt eine gewisse Menge Material deponiert. Es wird entlang einer Strecke eine gewisse Menge Material deponiert. Betrachtest du exakt den Punkt der Ecke, wird dort auch nur eine infinitesimale Menge Material deponiert (sorry, mathematischer Fachbegriff, ich nehme an, du kennst ihn, andere schlagen bitte bei Wikipedia nach oder denken die vereinfachte Umschreibung "unendlich klein"). Erst wenn eine makroskopische Strecke in X/Y gefahren wird, kann dabei auch eine makroskopische Materialmenge deopniert werden (also bei korrekt arbeitendem Slicer - die Firmware kann schon auch auf der Stelle extrudieren, aber das wird kein Slicer so ausrechnen außer vielleicht in Randfällen, die wir hier mal ausklammern).

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.

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. Quais wie ein unendlich dünner Textmarker, den man immer so hält, dass der Strich senkrecht zur Malrichtung steht (und die Linienbreite dann maximal groß wird). Bei einem harten 90 Grad Winkel passt das Bild nicht ganz, das Material quetscht sich dann aber schon an die richtige Stelle, unsere Düse ist ja kein Textmarker sondern rotationssymmetrisch.

Das ist also alles soweit völlig richtig!

(Gedankenfehler: Ich könnte genauso gut sagen, Pressure Advance bringt nichts, denn das zusätzliche oder fehlende Material wird ja eh‘ gleichmäßig über die gesamte Länge aufgeteilt.)

Pressure Advance arbeitet nicht mit der Granularität der G-Code-Befehle sondern sozusagen "mikroskopisch" innerhalb der fließenden Bewegungen. Das ist vermutlich auch der Grund, warum der Slicer das nicht machen kann sondern die nur Firmware: es müsste wahnsinnig viele G-Code-Befehle geben, wenn man das im Slicer umsetzen wollte.

Abgesehen davon ist Pressure Advance beinahe so Off-Topic wie Beschleunigungswerte oder gar Retract (siehe nächsten Beitrag)

Pressure Advance ist überhaupt nicht off-topic, denn es wird die korrekte Lösung für dein Problem sein, oder zumindest für eines deiner Probleme. Ich will nicht ausschließen, dass es hier mehrere Effekte gibt und nicht alles mit Pressure Advance erschlagen wird! Aber probier das erstmal aus, dann reden wir weiter. Ich kriege damit perfekt scharfe Kanten und sehe keine unerwünschten Nebeneffekte.

[mhier]

Ich hatte hierzu geschrieben, dass mir am Kringelende Material fehlt.

Tut mir leid. Mein Fehler .
Wenn dir am Ende das Material ausgeht, dann könnte dein 'Coast at end' Wert zu groß sein. Da wird so lange ohne zu fördern gefahren, bis die Düse leer ist und dann noch darüber hinaus.

Wie AtlonXP bereits geschrieben hat, hätte er gerne negative Coasting-Werte um das Problem zu kompensieren, das wird aber nicht unterstützt. Es gab mal die Vermutung, dass die Repetier-basierte Firmware (unter gewissen Umständen?) falsch rechnet und am Ende was weglässt. Tatsächlich konnte ich derartige Effekte teilweise früher auch sehen, neuerdings aber nicht mehr. Ich habe allerdings wesentlich mehr geändert als nur auf Klipper zu wechseln, in so fern bin ich da vorsichtig mit Schlussfolgerungen - aber es wäre nicht der erste Fehler im Bewegungscode der Repetier-basierten Firmware...

Ich stelle mir hier dir Frage, läuft der Extruder hier noch Synchron zu den Achsen?

Gute Frage. Ich habe elektronisch wenig am Hut. Vermutlich ist daher was ich jetzt sage völliger Blödsinn. Aber ich könnte mir vorstellen, dass es wie ein Bus-System aufgebaut ist. Wenn der Controller das Signal auf den Bus legt, fährt der Motor. Damit wäre sie recht leicht synchron zu halten. (Wie gesagt, kreuzigt mich nicht! Ich weiß wenig darüber.) Vielleicht meldet sich ein anderer, der Bescheid weiß.

Elektronisch gibt es nichts, was die Achsen desynchronisieren könnte. Die Stepper werden direkt über Step-Pulse vom Microcontroller angesteuert. Ebenfalls sind elektronisch alle Achsen gleich, d.h. es gibt da nichts, was den Extruder von den anderen Achsen unterscheiden würde. Wenn dann wären also alle Achsen unsynchron, mit entsprechenden Folgen die sofort in X/Y sichtbar wären. Ich denke aber auch in Firmware gibt es nichts, was den Extruder asynchron zum Rest laufen lassen würde (auch wenn hier natürlich denkbar), dafür würde ich meine Hand aber nicht ins Feuer legen wollen. Wir reden aber über Effekte, die nur durch Fehler im Bereich vieler Microschritte erklärbar wären. Es geht nicht um einzelne Microschritte. Was mir da gleich wieder einfällt: Die Original-Motoren sind ungenau - das ist im Endeffekt auch eine Asynchronizität zwischen den Achsen, allerdings ist die unkorreliert zu Eigenschaften des Modells wie einer Ecke, in so fern ist das als mögliche Ursache raus (es gibt aber sehr wohl sichtbare Effekte bei glatten Oberflächen, die fast parallel zur X oder Y Achse stehen, also fast aber nicht exakt parallel).

Aber nochmal: der Effekt der Stauchung des Filaments ist sehr sehr ähnlich wie ein Extruder, der etwas hinterher läuft. Wir wissen, dass die Filament-Stauchung stattfindet. Wer behauptet, Problem X produziert genau den selben Effekt wie die Filament-Stauchung, würde aber durch etwas anderes ausgelöst, der muss das sehr gut begründen - für mich gehört zu dieser Begründung hinzu, dass man den Effekt der Filament-Stauchung erstmal korrekt in den Griff bekommen hat, z.B. duch ein sauber eingestelltes Pressure Advance - wobei hier sofort wieder das Problem der Unterscheidung dieser Effekte auftaucht - aber eben genau das müsste man dann erstmal halbwegs fundiert hinbekommen. Passiert das nicht, ist die weitere Argumentation im Grunde hinfällig.

Die Community FW ist sowiso die bessere!

Da wird aber mhier nicht zustimmen.

Doch klar. Klipper ist aber halt noch besser

[rf1k_mjh11]

Hallo nochmals,

Uff, du schreibst immer sehr lange Posts. Es ist schiwerig, darauf zu antworten, ohne dass der Thread hier komplett explodiert.

ditto

Ich habe in einem Beitrag etwas übersehen. Das hole ich hiermit nach:

Ich streite erstmal nicht ab, dass es auch andere Effekte mit dem selben Symptom geben kann, aber dass Beulen aus der Filamentstauchung resultieren, ist doch unbestritten?

Ich weiß was du meinst, aber die Beulen können entstehen, nicht durch die Stauchung, sondern als Folge der Elastizität des Fördersystems (aber sie entstehen nicht ausschließlich dadurch!). Ich nehme an, das wolltest du sagen. Und ja, die Elastizität im System mischt hier sicherlich mit. Übrigens ist von den Direct-Drive Lösungen der Extruder, die RFx000 Lösung, durch den Einsatz der DMS, elastischer als die meisten anderen Direct-Drive Extruder.

Der Thread explodiert weil dauernd Nebenthemen (wie gerade eben), die nichts mit dem eigentlichen Thema zu tun haben, breitgetreten werden. Das Thema, das hier eröffnet wurde hat einzig und allein mit der falschen Berechnung des Fördervolumens durch den Slicer zu tun (ich habe die Überschrift unglücklich gewählt - mea culpa). Diese falsche Berechnung wurde inzwischen auch bei CraftWare und S3D (herzlichen Dank an AtlonXP) von mir mathematisch nachgewiesen. Ich habe keinen Bock, das auch noch bei Cura nachzuweisen, obwohl es kaum 10 Minuten dauert.

Da kann man Tee-Sud lesen, ACC, Jerk, Pressure Advance, Luftfeuchtigkeit und Vollmondstatus hineinbringen. Das hat alles NICHTS mit dem Problem der mathematischen Berechnung zu tun.

Bloß gut, dass es so Killerphrasen gibt, wie

Passiert das nicht, ist die weitere Argumentation im Grunde hinfällig.

Ich komme noch darauf zurück.

Wer behauptet, Problem X produziert genau den selben Effekt wie die Filament-Stauchung, würde aber durch etwas anderes ausgelöst, der muss das sehr gut begründen …

Hier stelle ich fest, die simple Mathematik ist hier ein deutlich besseres Werkzeug zur Begründung als die schwammige Formulierung

dass man den Effekt der Filament-Stauchung erstmal korrekt in den Griff bekommen hat, z.B. duch ein sauber eingestelltes Pressure Advance

Das hört sich in etwa so an, als dass ich die eiernden Z-Spindeln, mit dem dadurch erzeugten charakteristischen Muster, erst dann als ‚eiernd‘ beweisen kann, nachdem ich Nibbels Wobble-Kompensation in der Community FW richtig eingestellt hätte.

Man sollte mir zuerst die mathematische Begründung meiner These widerlegen, die ich bei Slic3r, PrusaSlicer, S3D und CraftWare bestätigt habe. Falls das nicht gelingt, dann bitte den mathematischen Beweis bringen, dass Pressure Advance den Effekt der Stauchung ausgleicht (eigentlich den Effekt der Systemelastizität). Aber auch das würde meine These nicht widerlegen.

Basierend auf Logik und Mathematik biete ich hier den Beweis, dass Slic3r, PrusaSlicer und CraftWare die nötige Materialmenge für Ecken nicht richtig berechnen und es in Folge zu einer lokalen Überextrudierung kommt. Bisher konnte das keiner widerlegen.

Auch wurde auf die (halb-)rhetorische Frage nicht geantwortet, wieso bei mir, ohne Pressure Advance, keine Beule vor der Ecke (in Fahrtrichtung gesehen) aufscheint, wie es mir die Erklärung von Pressure Advance weismachen möchte.

Die Beulen an den Ecken sind ein Symptom

Da stimme ich dir völlig zu. Keine Widerrede.

… ein Symptom, das aus der Filamentstauchung durch die Extrusionskraft resultiert, und zwar das prominenteste

Hier handelt es sich um eine Behauptung, die bestenfalls durch Beobachtung belegt zu sein scheint. Wo ist die mathematik?

---

Hier Auszüge aus den GCode Dateien, die von PusaSlicer, S3D und CraftWare erstellt wurden.
Es sind jeweils aneinander folgende Zeilen, die irgendwo in der Mitte herausgegriffen wurden (um Brim, Skirt, usw. zu 'umgehen'). Die Bemerkungen nach dem Strichpunkt stammen von mir.

Sliced by Craftware:


G1 X61.385 Y16.357 E1.9913 ; start E-value
G1 X61.385 Y15.357 E2.0079 ; travel: 1mm in Y, used E=0.0166
G1 X11.385 Y15.357 E2.8394 ; travel: 50mm in X, used E=0.8315
; an E of 0.8315 (for 50mm) divided by 50 = 0.01663/mm

Note: a diff. of 0.0015 could be the result of rounding (or limiting decimal places).
With (0.915 * 8.75 * RF_MICRO_STEPS) of E steps /mm (=0.915*8.75*32=256.2 microsteps per mm, or 0.0039mm/microstep) this error means it is less than half of a microstep off.

PrusaSlicer:

G1 X77.902 Y57.577 E2.00082
G1 X27.902 Y57.577 E3.78568 ; 50mm movement in X, used E=1.78486 (=0.0356972/mm)
G1 X27.902 Y56.957 E3.80781 ; 0.62mm movement in Y, used E=0.02213 (=0.035693/mm)
G1 X77.902 Y56.957 E5.59267 ; 50mm movement in X, used E=1.78486 (=0.0356972/mm)
G1 X77.902 Y55.957 E5.62837 ; 1mm movement in Y, used E=0.0357 (=0.0357/mm)

S3D: (file BulgingCornertestPiece_1a.gcode, starting at line #419, Dank an AtlonXP!)

G1 X71.700 Y121.200 E0.9756
G1 X121.700 Y121.200 E1.7793 ; 50mm movement in X, used E=0.8037 (=0.016074 pro mm)
G1 X121.700 Y120.209 E1.7952
G1 X123.300 Y120.201 E1.8209
G1 X123.300 Y123.200 E1.8691 ; 3mm in Y, used E=0.0482 (=0.016066 pro mm)
G1 X173.300 Y123.200 E2.6729

Wie man aus dem GCode herauslesen kann, wird an den Ecken keine Rücksicht auf die Überschneidung genommen, in keinem der drei (4) Slicer.

Zu der wichtigen Logik, weshalb man mit der Berechnung auf die fehlerhafte Berechnung schließen kann, bitte den vorletzten Absatz in diesem Beitrag lesen (und verstehen).

Bei CraftWare gibt es eine Differenz, die jedoch weniger als einen Mikroschritt ausmacht. CraftWare scheint nur mit 4 Nachkommastellen zu arbeiten, Slic3r/PrusaSlicer mit 5 (zumindest mit meinen Einstellungen). Auch S3D scheint an der 3. Nachkommastelle gelegentlich Skurriles zu treiben (bei den Koordinaten).

Bis nicht jemand einen Fehler in der Berechnung oder in der zwingenden Logik findet (und pfeift auf die Stauchung!), stelle ich den Spruch mhiers wieder in den Raum:

Passiert das nicht, ist die weitere Argumentation im Grunde hinfällig.

Gilt auch für Folgebeiträge.

Zum Abschluss noch ein letztes Argument, das ebenfalls nicht sterben will (ich zitiere hier sinngemäß): „Die Firmware macht das.“

Nach einigem Nachdenken (ja, manchmal hilft auch das! ), habe ich erkannt, dass es für die Firmware praktisch unmöglich wäre, eine falsche Berechnung der Ecken zu kompensieren. Schließlich fehlt der Firmware eine sehr wichtige Angabe, die dem Slicer, aber nicht der Firmware bekannt ist: den Filamentdurchmesser. Ohne den, kann die Firmware nie wirklich auf die Raupenbreite kommen (schätzen kann sie sie ja). Die Raupenbreite wäre nötig, damit die Firmware weiß, auf welche Streckenlänge sie kompensieren muss. Die Kompensationslänge ist theoretisch (bei einer 90°Ecke) exakt die Hälfte der Raupenbreite. (Zum besseren Verständnis das 5. oder 6. Bild im ersten Beitrag des Threads ansehen.) Die Kompensationslänge ist winkelabhängig. Spitze Ecke benötigen eine längere Strecke, stumpfe eine kürzere.

mjh11

[AtlonXP]

Hallo rf1k_mjh11,
da ich kein AMI bin, erst einmal eine Übersetzung:

Hinweis: ein Unterschied. von 0,0015 könnte das Ergebnis einer Rundung (oder einer Begrenzung der Dezimalstellen) sein.
Bei (0,915 * 8,75 * RF_MICRO_STEPS) von E Schritten/mm (=0,915*8,75*32=256,2 Mikroschritte pro mm oder 0,0039 mm/Mikroschritt) bedeutet dieser Fehler, dass weniger als ein halber Mikroschritt daneben liegt.

Das wird vermutlich auch so sein.

Des Weiteren glaube ich nicht, dass unsere Firmware auf 4 Stellen hinter dem Komma genau rechnet.
Es wird dadurch sicherlich in der tatsächlichen Wegstrecke Firmware Seitig auch Rundungsfehler geben.

Die tatsächlichen Wegstrecken und errechneten Materialmengen, sollten aus jedem Slicer im G.- Code gleich sein.
Warum sind die das nicht?

1.) Ideal wäre ein Druckteil wo rechteckig wäre, so dass überall die gleichen Winkel mit 90°sind.
2.) Das eingestellte Übersetzungsverhältnis (E Stepps) spielt im G.- Code keine Rolle.
3.) Der Düsendurchmesser und der Filament- Durchmesser jedoch sehr wohl.
4.) Auch muss der Material Multi immer auf 1.0 oder 100% stehen.
5.) Allgemein sollten die Druckparameter identisch sein.

Unter solchen Bedingungen wäre der Vergleich der Slicer Sinnvoller gewesen.

LG AtlonXP

[af0815]

Dumme Frage, kann man nicht ein GCodefile erstellen, wo man dann das Verhalten nicht einfach testen kann ? GCode ist ja auch nur ein Textfile.

[rf1k_mjh11]

Tut mir Leid, Computerprobleme - musste den Antivirus wechseln. Der machte Zicken.

Hallo allerseits,

Hiermit spreche ich dem AtlonXP meinen Dank aus. Er zeigt mit seiner Frage:

Die tatsächlichen Wegstrecken und errechneten Materialmengen, sollten aus jedem Slicer im G.- Code gleich sein.
Warum sind die das nicht?

sehr gut auf, wieso meine Beiträge oft sehr lang werden. Eigentlich müsste ich zu den Punkten 1., 3., 4., und 5. Praktisch jeweils einen langen Beitrag schreiben. Dazu komme ich später. Zuerst zum obigen Zitat.

Man kann sich vorstellen, dass die nun folgende Erklärung in meinem vorherigen Beitrag eigentlich vor oder nach dem Abschnitt mit den Slicer-Ergebnissen hätte kommen sollen. Da wäre der Beitrag natürlich um das länger geworden (Oh Gott, nur das nicht!!).

Einiges ist eine Wiederholung aus diesem Beitrag. Und zwar der Teil mit den Annahmen:

Die Korrektur einer Eckenüberschneidung (wie ich sie gezeigt habe), wäre für einen gewissen Eckenwinkel immer gleich, also ein konstanter Wert. Die Ecken vom Probestück waren alle 90°. Somit müsste der Korrekturwert für alle Ecken gleich sein. Egal ob ich sage, ‘pro Ecke kommt die Hälfte der Korrektur vor und die Hälfte nach der Ecke‘ oder ‘es kommt immer die volle Korrektur nach der Ecke‘ – egal, es käme insgesamt immer nur eine Korrektur pro Seite vor. Mit diesen zwei Annahmen ( #1: es handelt sich um einen konstanten Wert und #2 diese kommt nur einmal pro Seite vor) kann man rechnerisch feststellen, ob ein Korrekturwert existiert.
Auf der Extrusionsmenge eines langen Pfads (50mm) würde sich ein konstanter Korrekturwert prozentuell weniger stark auswirken wie auf die Extrusionsmenge eines kurzen Pfads (1mm).

Ich muss, um zukünftige Fragen zuvor zu kommen, noch weiter ausholen.
Der Sinn der Berechnung ist nur, festzustellen, ob der Slicer in irgendeiner Weise eine Korrektur bei Ecken vorsieht. Die eigentlichen Werte interessieren mich nicht, nur der Unterschied zwischen langem Pfad und kurzem Pfad.

Eine der Annahmen ist, dass der Korrekturfaktor für eine 90° Ecke immer gleich sein muss, egal wie lang die Gerade davor oder danach ist. Ebenso egal ist, ob es sich um eine Innen- oder Außenecke handelt. Ich hoffe, das ist verständlich.

Nehmen wir an, der erste Teil des betrachteten Pfads (A) läuft ‘horizontal‘, 50mm entlang der X-Achse, der zweite (B) läuft vertikal 1mm, nach unten, entlang der Y-Achse. (Siehe Bild aus dem ersten Beitrag im Thread). Wichtig: Weder darf der erste Pfad (50mm) ein Anfangspfad sein (quasi nach einem Retract) noch darf der zweite Pfad (1mm) ein Endpfad sein (unmittelbar vor einem Retract). Die Pfade müssen einfach irgendwo 'mitten‘ im Perimeter sein. (Bei einem Quader oder Quadrat kämen somit nur 2 Pfade für die Berechnung in Betracht.) Das Testobjekt, das ich verwendete hatte 8 Außen- und 4 Innenecken, jeweils mit 90° und es gab folglich mehrere Möglichkeiten zur Auswahl.

Zurück zu AtlonXPs Frage, wieso die Materialmengen nicht gleich sind. Da gibt es viele Gründe. Zum einen weiß keiner von uns, wie S3D und CraftWare den Materialbedarf berechnen (diese sind nicht Open Source). Das ist aber nicht von Belang. Ebenso wurde unter unterschiedlichen Bedingungen geslicet. (Bei CraftWare weiß ich jetzt nicht einmal, welche Layerhöhe oder Raupenbreite verwendet wurde – aber auch das ist nicht von Belang!) Unter PrusaSlicer wurde eine 0.35-er Düse und 0.25mm Layerhöhe hergenommen. Macht für die Berechnung keinen Unterschied. AtlonXP ist von einer Raupenbreite von 0.4mm und einer Layerhöhe von 0.1mm ausgegangen. Hat auch keinen Einfluss auf die Berechnung. Die Berechnung nimmt stur den Extrusionswert, den der Slicer für 50mm Länge errechnet hat, und vergleicht diesen mit dem errechneten Wert für 1mm. Ist der Extrusionswert für 1mm exakt ein Fünfzigstel vom anderen Wert, kann man daraus schließen, dass es keinen Korrekturfaktor für die Ecken gibt (oder dieser ist so klein, dass es sich nicht um den Korrekturwert handeln kann).

Mir ging es nicht darum, die Berechnung der Extrusionsmenge zwischen den Slicern untereinander zu vergleichen, sondern einzig und allein festzustellen, ob die Slicer die Ecken berücksichtigen. Aus dem Grund sind die meisten Voreinstellungen (Raupenbreite, Layerhöhe, usw.) egal, denn es ging immer nur um zwei vergleichbare Werte innerhalb eines Pfads, wobei die beiden Werte die gleichen Vorbedingungen hatten und vom gleichen Slicer berechnet wurden (womit sich Raupenbreite, Layerhöhe und andere Faktoren quasi ‘rauskürzen‘).
Es ist auch völlig egal, ob unterschiedliche Werte beim Slicen verwendet wurden (die zu völlig unterschiedlichen Extrusionswerten führen). Wichtig ist, dass sich pro geprüftem Slicer, zwischen den Werten, die zur Berechnung herangezogen werden, nichts geändert hat. Das wurde gewährleistet, denn die GCode-Befehle folgen unmittelbar aufeinander (es liegen somit keine ändernden Befehle dazwischen). Und ob die Werte eines Slicers sich mit denen eines anderen Slicers deckt, ist völlig unerheblich.

Tut mir leid, ich schaffe das nicht, das richtig verständlich darzustellen (trotz der elenden Länge).

Im Extrusionswert verstecken sich zwar der Filamentdurchmesser und der Extrusion Multiplier (=Material Multi), denn diese werden zur Berechnung herangezogen. Nachdem beide innerhalb eines Pfads gleich sind, können wir diese für diese Berechnung vernachlässigen und den Extrusionswert wie eine Länge oder Volumen betrachten (oder überhaupt als einheitenlos ansehen - tut alles nichts zur Sache).

Pro Strecke sollte es einen Streckenwert (‘SW‘) geben, plus einen unbekannten Ecken-Korrekturwert (‘EK‘). Dieser Streckenwert plus dem ‘EK‘ ergeben den Extrusionswert für den jeweiligen Pfad. Der Streckenwert wird stur anhand der Strecke, der Raupenbreite und der Layerhöhe errechnet. Beschleunigung, usw. spielen keine Rolle. Die genaue Formel hängt davon ab, wie angenommen wird, wie die Raupe im Querschnitt aussehen wird (elliptische Seiten, halbrunde Seiten, eckige Seiten, usw. Siehe beispielsweise hier).

Der Streckenwert (SW50) für 50mm Pfad sollte exakt 50 mal so groß sein wie der Streckenwert (SW1) für 1mm Pfad. Beachte: der Streckenwert ist nur ein Teil der Extrusionsmenge, falls es einen Eckenkorrekturfaktor gibt.

Somit könnte ich den Extrusionswert für 50mm durch 50 dividieren und ich bekäme den Steckenwert für 1mm + ‘EK‘/50. Oder umgekehrt könnte ich den Extrusionswert für 1mm mal 50 multiplizieren und bekäme den Streckenwert für 50mm + 50x‘EK‘. Ziehe ich von diesen Wert den Extrusionswert von 50mm ab, müsste ich 49 mal den Ecken-Korrekturfaktor bekommen. Dividiere ich das dann durch 49 bekomme ich den Ecken-Korrekturwert.
Also:
((50 x Extrusionswert von 1mm) - (Extrusionswert von 50mm)) / 49 = 'EK'

Was ich damit hervorheben möchte, ist, dass bei einem vorhandenen Ecken-Korrekturwert es einen Unterschied zwischen einem Fünfzigstel des Extrusionswerts von 50mm und dem von 1mm geben muss.

Diesen Unterschied gibt es nicht, daher gibt es kein Ecken-Korrekturwert, bzw. dessen Wert ist Null.
Ich hoffe das verstehen zumindest einige. Besonders verständlich habe ich es nicht hinübergebracht.

Ich versuche jetzt auf vier der fünf Punkte AtlonXPs einzugehen:

Zu Pkt. 1.:

Ideal wäre ein Druckteil wo rechteckig wäre, so dass überall die gleichen Winkel mit 90°sind.

Das Druckobjekt, dass du verwendet hast, hatte 10 rechte Winkel und zwei spitze Winkel. Das reicht für was ich vorhatte locker. Siehe oben. (Ich brauchte nur 2 Pfade unterschiedlicher Länge, die durch einen rechten Winkel getrennt waren.)

Zu Pkt. 3.:

Der Düsendurchmesser und der Filament- Durchmesser jedoch sehr wohl.

Hier kann ich dich an mehrere Beiträge verweisen, wo dargelegt wird, dass der Düsendurchmesser Schnuppe ist, was die Berechnung der Extrusionsmenge betrifft (bis auf bei Brücken und eventuell Überhänge). Zum Beispiel hier, hier und hier, unter anderem. Der Filamentdurchmesser ist zwar nötig, um die benötigte Extrusionslänge zu errechnen. Aber solange wir uns im selben Layer (und im selben Pfad befinden) ist es auch egal. Auch wenn einer mitten in einem Layer (oder gar in einem Perimeter!) das Hot End umbaut und von 1.75 auf 2.85 umsattelt, ändert das nichts an dem Wert, den der Slicer vorher errechnet hat (obwohl dann eine Menge mehr aus der Düse herauskäme – aber andererseits, ich drucke ja gar nicht! Ich rechne nur nach!)

Zu Pkt. 4.:

Auch muss der Material Multi immer auf 1.0 oder 100% stehen.

Da sich der Material Multi auf beide Bahnen, die in die Berechnung einfließen, gleich stark auswirken, ‘kürzen sie sich ‘raus‘, wie man das sagt. Der Material Multi könnte sogar auf 10000 stehen, es käme das identische Ergebnis heraus (dass 'EK=0 ist, nicht jedoch die zwei Extrusionswerte - aber deren Verhältnis zueinander wäre exakt gleich). Siehe auch die Antwort zu Pkt. 5.

Zu Pkt. 5.:

Allgemein sollten die Druckparameter identisch sein.

Auch diese sind für das, was ich erreichen wollte, egal, solange sich die Parameter nicht innerhalb eines Pfades ändern (was sie nicht taten, denn es stehen keine abweichenden Befehle dazwischen).


Deine Aussagen in den Punkten 1., 3. (teilweise, siehe Pkt. 3.), 4., und 5. wären richtig, wenn man die Extrusionsmengen der Slicer miteinander vergleichen wollte (was ich aber nicht wollte, sorry).

Und falls du das angehen möchtest (das Vergleichen der Slicer), stehen die Chancen gut, dass dir so ein Versuch misslingen würde, denn einige Slicer (Craftware, S3D, und vielleicht andere), lassen bezüglich der Mengenberechnung nicht in ihre Karten schauen.

aber das muesste man doch merken, oder

---

Wenn überhaupt, werden sich die Differenzen im einstelligen Prozentbereich befinden. Der User merkt dann nichts, denn das wird im täglichen Gebrauch mit dem Material Multi ausgeglichen, dann steht dort halt 1.02 oder 0.98, oder so. Und der User begründet das mit Schlupf, Seitenwind, Mondphase, Inflationsindex oder sonst was.

Unter solchen Bedingungen wäre der Vergleich der Slicer Sinnvoller gewesen.

Ich wollte nie die Slicer miteinander vergleichen, sondern einzig allein feststellen, ob ein Slicer die Überschneidung an den Ecken berücksichtigt. Bitte entschuldigt, falls ich das nicht richtig 'rüber brachte.

Zu Pkt. 2.: Da hat AtlonXP völlig recht.

Dumme Frage, kann man nicht ein GCodefile erstellen, wo man dann das Verhalten nicht einfach testen kann ? GCode ist ja auch nur ein Textfile.

Im Endeffekt habe ich das getan. Ich habe anhand des GCodes festgestellt, dass weder Slicer, PrusaSlicer, CraftWare noch S3d die Überschneidung an einer Ecke berücksichtigen.
Falls du aber meinst, man könnte selbst einen GCode erstellen, wo eine Ecken-Kompensation vorgenommen wird, da sage ich, ja das ginge. Zuerst müsste ich mir aber überlegen, wie das zu bewerkstelligen wäre. Die Kompensation ist nicht linear, könnte aber mit einer Gerade angenähert werden (wäre immer noch besser als gar nichts).

CornerCorrection.jpg

In magenta die Extrusionsmenge über den Weg (nicht über die Zeit!!, da spielen Beschleunigung, usw. mit). Dieser ist bis zur Ecke konstant, bricht dann einen gewissen Betrag ein und steigt dann eine Zeitlang hoch, bis wieder derselbe konstante Wert von vorhin erreicht wurde.
Daraus kann man erkennen, dass bei einer Ecke, ein bisher simpler GCode-Befehl (fahre zum nächsten Punkt und Extrudiere so und so viel) aufgeteilt werden müsste in mehrere kleinere Wegabschnitte, mit unterschiedlichen Extrusionsmengen. Vermutlich reichen 3 Unterteilungen, vielleicht gar nur zwei. Da wird aus der grün-gestrichelten Geraden eine Treppe mit der entsprechenden Anzahl Stufen, 3 oder 4). Und diese Prozedur müsste bei jeder Ecke wiederholt werden.

Bloß so zum Spaß diese Änderung bei nur einer Ecke durchführen, wird vermutlich eine gar nicht erkennbare Änderung erzeugen. Man müsste schon mehrere Lagen so bearbeiten um es schön sichtbar zu machen. Wer Lust hat und vor Langeweile völlig am Sterben ist, kann sich das antun.

mjh11

P.S. Der Korrekturbetrag errechnet sich so (gilt nur für 90° Ecken!):
K = r² - r²xPi/4
wobei r der halben Raupenbreite entspricht. Somit wäre bei einer Raupenbreite von 0.4mm an jeder 90° Ecke ein Korrekturfaktor von 0.00858 nötig. Diese wäre, nicht-linear, über die Distanz der halben Raupenbreite anzuwenden. Das ist arg wenig. Aber auch Pressure Advance wird mit so geringen Werten arbeiten.
Der Korrekturbetrag hier entspricht einer Fläche, bzw. zusammen mit der Layerhöhe einem Volumen.

[AtlonXP]

3 Mal ausgeholt um auf den gleichen Punkt zu kommen…
Jetzt habe ich es kapiert!

Danke!

Bei diesen geringen Werten brauchst du vermutlich gar nichts berechnen, da die Werte so gering sind und in der FW schon beim runden unter den Tisch fallen.

Hier ein Leitsatz von mir über eine ältere Conrad Firmware:
Bei einem Filament Durchmesser von 2,98 mm.
Einem Düsen Durchmesser von 0,4 mm.
Einer Layerhöhe von 0,04 mm.

Ist folgendes Problem zu beobachten:
Der Materialfluss ist während des Druckens noch Störungslos.
Setzt man den Material Multi nun auf 99%, bleibt der Extruder einfach stehen.
Die Digits fallen ab und etwas später bekommt der Druck Lücken.

Stellt man rechtzeig den Material Multi auf 100%, dreht der Extruder als ob nichts gewesen wäre wieder weiter.
Hier besteht also eine Grenze am E Stepper!
Nibbels hatte dieses Problem als Rundungsfehler in der FW erkannt und in der Community FW beseitigt.
Ich vermute dass dieses Problem in der Conrad Version noch weiter besteht.

Daraus vermute ich weiter:
Unsere Firmware rechnet mit nur 3 Stellen hinter dem Komma.
Weiter vermute ich,
die Conrad FW macht aus dem Korrekturfaktor von 0.00858 einfach eine 0 (Stillstand).
Wenn wir Glück haben auch 0.008.
Unsere Community FW könnte daraus 0.01 oder auch 0.009 machen.
Es ist nur eine Annahme die es zu wiederlegen gilt.
Wie genau unsere theoretische Positionier Genauigkeit bei X;Y und E ist, weiß ich leider nicht.

Kannst du die nennen?
Das dürfte in diesem Fall auch eine Rolle bei E Stepps spielen.

LG AtlonXP

[mhier]

Sorry Leute, aber ich bin hier raus. Ich habe jetzt nicht mehr alles gelesen, aber die Argumentation dreht sich eh nur noch im Kreis. rf1k_mjh11 liegt falsch. Die Slicer rechnen korrekt. Es gibt schlicht keine Überlappung. Die Firmware muss da auch nichts korrigieren und macht in dem Punkt wohl auch nichts falsch.

Bitte Post #13 hier im Thread noch mal aufmerksam lesen. Wer erstmal grundsätzlich bereit ist, das zu akzeptieren, dem helfe ich gerne auch bei konkreten Verständnisfragen. Solange aber grundsätzlich keine Bereitschaft vorhanden ist, einzusehen, dass der beobachtete Effekt eben doch das klassische Problem mit der Filemantstauchung etc. ist, habe ich keine Lust mehr, das hier zu diskutieren. Es ist wirklich albern hier.

Leute ernsthaft: Es gibt weltweit viele viele Millionen Nutzer der Slicer. Unter denen gibt es unglaublich viele, die sehr sehr viel Ahnung von der Materie haben, viel mehr als wir alle hier im Forum zusammen. Ihr könnt doch nicht ernsthaft glauben, dass so ein simpler Fehler seit Jahrzehnten in den Slicern schlummert. Allein das sollte im Grunde schon als Argument genügen (zumindest, dass man dann selbst sehr sehr gute Argumente braucht und absolut sicher alle anderen Erklärungen ausgeschlossen haben muss - sprich Pressure Advance muss man schon mal ausprobiert haben und zeigen können, dass das das Problem eben nicht löst. Das hat hier keiner gemacht!). Die inhaltliche Erklärung gibt's wie gesagt in Post #13.