Hat jemand schon Erfahrungen mit dem Arc Welder Plugin gemacht? Damit sollen wohl sehr gute Ergebnisse erzielt werden können, in Bezug auf glatteres Aussehen der gedruckten Objekte:

Hier mal ein Video:
https://www.youtube.com/watch?v=18uYYXecH5g

ok, geht nur mit octoprint und cura. Ausserdem müsste ich Klipper auf Bögen konfugurieren.

Klingt interessant. Ich drucke in letzter Zeit viel Bögen und Kurven, Kegel u.s.w.
G2 und G3 scheinen auf der Community Mod Firmware zu laufen.
Jedenfalls wurde eine Bogen-Bewegung ausgeführt als ich das eingegeben habe:
G90
G28 X Y
G0 X0 Y0
G2 X40 I20

Hier ein Link zur Doku:
https://plugins.octoprint.org/plugins/arc_welder/

Jaein, interessant. Die Stepper fahren nun mal gerade. Es wird dann wieder im Drucker aufgelöst. Ja es kann allerdings gewaltige Einsparungen im GCode geben. Wenn die interpolation schon im Slicer sehr fein ist, so ist das GCode File entsprechend fett und es müssen schon viele Daten in den Drucker übertragen werden.

Grundlegend muss man sich überlegen ob es einem was bringt, ausser einen zusätzlichen Zwischenschritt des ARC-Welding. Weil soweit ich die Doku gelesen habe, macht es nicht der Slicer nativ, sondern wird als zusätzlicher Schritt nach der Erstellung durch den Slicer gemacht. Interessant wäre das IMHO eher, wenn der Slicer nativ die Bögen ausgeben würde.

in dem Video wird gezeigt, dass der gcode durch das Plugin wesentlich geringer ausfällt von der Größe her oder was meinst du?

Ja, aber man sollte sich den ganzen Weg betrachten. Siehe meinem Post vorher. Was bringt das MIR jetzt in Summe ausser zwei zusätzlichen Wandlungen. BTW. Ich kenne das Plugin schon länger und habe mich damit beschäftigt. MIR bringt es nichts.

Wenn du von SD druckst oder seriell, so kann es DIR was bringen.

Du hast fertigen GCode aus dem Slicer, der wird untersucht ob man Kurven im GCode anlegen kann. Geht das mit einer gewissen Näherung, so wir der GCode ersetzt. Das ist kürzer, aber auch ev mit Fehlern behaftet, wenn es kein reiner Bogen ist, sondern ev. eine Ellipse. Der resultierende Code ist jetzt kürzer. In den Drucker übertrgen, muss er wieder in Bewegungen zurückgenähert werden, die die Stepper fahren können und das sind halt keine echten Bögen. Sondern das was der Slicer vorher schon mal gerechnet hat. Je nach Drucker vielleicht besser oder schlechter als der ursprüngliche Slicer.

Den meisten Vorteil hast du dann, wenn in der Übertragung Von GCode zum Drucker Probleme hast, oder von SD druckst. Auch wenn du dir viele Dateien aufheben willst. Auch dann wenn dein Drucker besonders gut Radien drucken kann.

Da gab's gerade eine Diskussion auf der Klipper Mailingliste zu. Klipper löst intern Arcs auch wieder nur in lineare Bewegungen auf. Du würdest also lineare Bewegungen durch Bögen annähern, die dann wiederum durch lineare Bewegungen angenähert werden. Das macht es evtl. nur schlechter.

Wenn die Firmware echte Bögen kann, oder die Bögen in extrem kleine lineare Bewegungen zerteilt, ist das vielleicht was anderes. Dann könnte man aber auch im Slicer hinreichend feine Unterteilungen wählen. Die meisten Slicer haben das einstellbar. Wichtig ist auch, dass das Modell schon ausreichend feine Unterteilungen der Rundungen hat. STL kann nämlich auch keine echten Rundungen...

Gerade bei Klipper sollte es ja eben keine Probleme mit der Übertragung zwischen Octoprint und der Firmware geben, denn beides läuft auf dem selben Host.

Guten Morgen

Wie muss ich mir einen Bogen im Drucker vorstellen?

a. ein Bogen wird genügend fein segmentiert und X fährt eine Anzahl Mikroschritte und danach fährt Y eine Anzahl Mikroschritte, und so weiter.
b. beide Achsen laufen gleichzeitig.

Das kann man sicher heraus bekommen, nur fehlt mir derzeitig die Methode und vielleicht das Messmittel und wohl auch die Suchbegriffe.

... auffällig ....
Im G-Code meines Druckers steht für jede Achsbewegung eine Zeile (a?).
Im G-Code einer Zerspanungsmaschine stehen in einer Zeile mehrere Achsbewegungen für X Y Z und A oder B. (b?)

Wenn a. zutrifft, hilft eine Ehöhung der Microsteps auf 64 oder gar 128?


Gruß zero K

zero K hat geschrieben:Wie muss ich mir einen Bogen im Drucker vorstellen?

Im Idealfall ähnlich wie eine beschleunigte Bewegung, nur dass die Beschleunigung auf beiden Achsen gegenläufig stattfindet. Theoretisch ist es denkbar, dass die "Segmentierung" dann effektiv auf dem Level einzelner Microsteps stattfindet.

a. ein Bogen wird genügend fein segmentiert und X fährt eine Anzahl Mikroschritte und danach fährt Y eine Anzahl Mikroschritte, und so weiter.

So sowie so nie. Die Achsen fahren immer gleichzeitig und koordiniert, alles andere wäre viel zu ungenau.

Im G-Code meines Druckers steht für jede Achsbewegung eine Zeile (a?).

Ich versteh nicht genau, was du damit meinst. Im G-Code, den mein Slicer produziert, stehen durchaus Befehle wie d.h. es werden beide Achsen gleichzeitig gefahren. Die Bewegung ist aber eben linear, d.h. im obigen Beispiel wird der kürzeste Weg zwischen den beiden Punkten gefahren. G-Code-Generatoren für Fräsen machen das prinzipiell genauso, wobei diese meist die Funktion haben, G2 und G3 Befehle zu generieren, um Kreisbögen zu beschreiben.

Der Arc Welder berechnet jetzt aus linearen Kreisbögen-Segmenten, die der Slicer generiert hat, G2 oder G3 Befehle. Das macht nichts genauer, es spart nur G-Code-Zeilen, weil z.B. aus 100 Kreisbögen-Segmenten in 100 G-Code-Zeilen ein einzelner Befehl werden kann.

Wenn a. zutrifft, hilft eine Ehöhung der Microsteps auf 64 oder gar 128?

Das Microstepping hat erstmal wenig bis nichts damit zu tun. Wir sprechen hier von einer Segmentierung auf G-Code-Ebene. Wenn die Firmware tatsächlich korrekte Kreisbögen auf niedrigstem Level berechnen kann (was selbst Klipper wohl nicht tut, da braucht man vielleicht eher LinuxCNC oder professionelle Geräte), bringen Microsteps trotzdem wenig, denn es ist falsch anzunehmen, dass 128 Microsteps die 4-fache Genauigkeit von 32 Microsteps bieten. Alles was über ~8 Microsteps oder so hinausgeht (wenn überhaupt) dient nur noch der Laufruhe.

Hallo,

Interessantes Thema. Ich hatte schon früher einmal über was ähnliches geschrieben: Das Fehlen der G2 und G3 Befehle im erzeugten GCode. Ich bilde mir ein, damals schrieb ich, es waren die Programmierer von Slic3r, die diesen Ansatz (von Arc Welder) schon einmal begonnen hatten und dann wegen zu hohem Aufwand wieder aufgaben. Vielleicht hat es dann einer der Programmierer selbst weiterentwickelt und als Plug-in herausgegeben. Egal, eigentlich wollte ich wieder was anderes ansprechen.
Ich hatte hier auch von einer Python Datei geschrieben, die dasselbe leistet wie Arc Welder.

Ich stimme den meisten aufgebrachten Punkten bei. Primär von Vorteil ist das Plug-in beim Drucken über USB (wie ich es tue), da weniger Daten übertragen werden müssen. Hier im Forum gab es bereits einige Beiträge bezüglich 'Stottern'. Ich glaube das wurde, wie im Video auch, auf einen vollen Befehlspuffer zurück geführt. Ich vermute sogar, dass hier die Art der Daten-Übertragung (per USB oder SD-Karte) keine große Rolle spielt. Der Prozessor der Hautplatine wird einfach, durch eine lange Folge extrem kurzer Bewegungen, an seine Grenzen getrieben - mit Stottern als Folge. Dem Problem kann man begegnen, indem weniger Daten verarbeitet werden müssen. Eine Möglichkeit bietet hier Arc Welder. Eine weitere wäre die absichtliche Reduzierung der STL Auflösung. Gehe ich mit der Auflösung herunter, werden, ohne Arc Welder, besonders kleine Radien deutlich eckiger, aber auch große, lange Radien sehen eckig aus (wie im Video verdeutlicht). Wenn ich aber umgekehrt mit der Auflösung hoch gehe (als Beispiel siehe diesen Link), können zwei Probleme entstehen. Einmal das bereits besprochene Stottern durch die hohe Datenrate, andererseits kann die Firmware ein Problem mit dem Aufsummieren der Nachkommastellen bekommen (siehe den Spoiler in diesem Beitrag). Wenn durch die hohe Auflösung die Wegstrecken sehr kurz werden, müssen die einzelnen Extrusionswerte ebenfalls sehr klein werden. Da kann es passieren, dass der Unterschied zwischen den E-Werten kleiner als die rechnerische Auflösung des Systems wird - dann wird nicht mehr ordnungsgemäß Material gefördert.

Die Schrittmotoren fahren -theoretisch- exakte Geraden. Diese Motoren sollten eigentlich -theoretisch- ebenso exakte Kreisbögen fahren (korrekte Firmware vorausgesetzt). Wenn die Motoren keine Kreisbögen schaffen, müssten wir alle CNC-Bearbeitungsmaschinen zum Schrottplatz fahren .
Aber es reicht völlig, wenn die geraden Teilstücke, die einen Bogen ausmachen, so klein sind, dass die resultierenden Abweichungen unter der erwarteten/erlaubten Oberflächen-Rautiefe zu liegen kommen.

mhier hat geschrieben:Wenn die Firmware echte Bögen kann, oder die Bögen in extrem kleine lineare Bewegungen zerteilt, ist das vielleicht was anderes.

Das ist die Bonusfrage (vor allem für Nibbels und RF1000):
Wie werden der G2 und G3 Befehl in der Firmware abgearbeitet? Wenn dort erst wieder ein Bogen durch mehrere Geraden angenähert wird, würde Arc Welder, durch die unnötige zusätzliche Berechnung, eher der Genauigkeit abträglich sein.

EDIT: Eine mögliche Antwort auf die Bonusfrage habe ich eben hier gefunden:

Nibbels hat geschrieben:Schaut man sich die Funktion
PrintLine::arc(float *position, float *target, float *offset, float radius, uint8_t isclockwise)
genau an, sieht man ein paar Dinge, die man evtl. nicht so erwarten würde:
- Auch hier wird die Bahn in kleinste Teilstücke zerteilt.
- Hardcoded: Ist ein Kreisstück < 0.001mm lang wird es ignoriert.
- Es wird anhand einer festen Feedrate-Konstante von 60mm/s unterschieden, ob größere oder kleinere Segmente verwendet werden.

Gesundheit allerseits,

mjh11