rf1k_mjh11 hat geschrieben: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.

Die Repetier-Firmeware schafft es nicht mal, G0 und G1 korrekt zu berechnen...

Ok Leute.
Ich lese hier schon eine Weile mit und halte meine Klappe.

Dieses Plugin gibt es auch für Klipper.
Es wird auch in Cura eingebunden und vermutlich ist es auch in der Slic3r Pursaedition möglich.
Dass unsere Arduino Gurken vieles vermauscheln müssen,
das muss nicht auf die neuen M4 MCU zutreffen.

In einem anderen Forum habe ich dieses Tool zur Schau gestellt.
Es wurde unter der neuen Marlin FW gedruckt.
Gefühlt war der Drucker mit M4 Prozessor in den Kurven schneller unterwegs.
Leider hat der Drucker aber auch manchmal gestockelt.
Einstellungssache, System schwäche, keine Ahnung!

Wenn ich es richtig verstanden habe, kann man das Komprimierungsverhältnis einstellen.
Wird dann bei reduzierter Komprimierung nicht manche Gerade auch gerade bleiben?

LG AtlonXP

Ich würde mir erstmal konkret überlegen, welches Problem ich habe, was ich mit diesem Plugin zu lösen gedenke.

Was das Plugin nicht sinnvoll leisten kann, ist die Ecken, die der Slicer reingemacht hat, zu glätten. Würde das Plugin hier signifikante Abweichungen in der Trajektorie erwirken, würden die Bewegungen wohl nicht mehr zueinander passen. Die Nachbar-Raupe ist nicht mehr zwingend, wo sie sein soll, und die Extrusions-Menge passt nicht mehr (Weglänge ändert sich).

Was das Plugin tatsächlich leisten kann, ist den G-Code zu "komprimieren". Das bringt aber nur was, wenn die Größe des Codes aufgrund von angenäherten kreisförmigen Bewegungen tatsächlich ein Problem ist und die dann zusätzlich nötigen Kurven-Berechnungen den Microcontroller nicht überlasten.

Also: Wer ein Stocken bei annähernd kreisförmigen Bewegungen bzw. in unmittelbarer Umgebung von solchen Bewegunen beobachtet (und nur dann!), der kann mit dem Plugin vielleicht (!) was reißen. Wer meint, damit die Facetten der Oberfläche glätten zu können, handelt sich damit nur andere Probleme ein und ändert besser die Slicer-Einstellungen und/oder sein STL-Modell. Wer generell ein Problem mit stockenden Bewegungen hat, z.B. auch bei häufigen linearen Richtungswechseln, der wird auch besser nach anderen Lösungen suchen. Vielleicht ist auch einfach der Host zu langsam um die Daten über USB schnell genug zu liefern (das Problem hatte ich, als ich noch meinen RasPi 1. Generation dafür benutzt habe)?

Kreisförmige Bewegungen sind in vielen Modellen ja gar nicht so stark vertreten, da wird das Plugin dann quasi gar nichts ändern...

Hallo mhier,

mhier hat geschrieben:Was das Plugin nicht sinnvoll leisten kann, ist die Ecken, die der Slicer reingemacht hat, zu glätten.

Das muss ich korrigieren:
Kein mir bekannter Slicer macht irgendwelche zusätzliche Ecken in den GCode. Die Ecken sind allesamt bereits in den Ausgangsdateien vorhanden (zumindest jene Dateien mit den Formaten *.STL, *.OBJ, *.AMF und *.3DF). Dummerweise versteht (noch?) kein Slicer ein Dateieformat, das NICHT auf einen Mesh basiert. Jedenfalls kenne ich noch keinen Slicer der ein anderes Format, als die oben genannten, verarbeitet.

Will man hingegen fräsen, und verwendet ein entsprechendes ('ordentliches') Programm dafür (wie z.B. Fusion 360, oder ähnliches), kann das Programm von den tatsächlichen 3D Daten ausgehen, womit Bögen, Kurven, und so weiter, möglich werden. In den erzeugten Toolpaths (=GCode) tauchen dann natürlich entsprechende G2 und G3 Befehle auf.
Manche CAM Programme (z.B. MeshCAM) benutzen erst wieder *.STL Dateien als Input, womit sich 'Ecken', die sich bereits in den Ausgangsdaten befinden, bis ins fertigen Produkt hinein 'vererben'.

Moge COVID-19 uns alle verschonen,

mjh11

rf1k_mjh11 hat geschrieben:Das muss ich korrigieren:

Du hast recht, nicht Slicer sondern STL Exporter. Slicer weichen zwar durchaus vom Modell ab, da aber ja keine echten Kreisbögen im Mesh vorliegen, können sie die auch nicht durch Ecken annähern.

For the records (und weil ich gerade bei der Suche drüber gestolpert bin):
Communityversion: In der motion.cpp ab Zeile 851 ist noch das zu mit eine bedingten Kompilierung. Dabei werden Kosinus und Sinus Funktionen auch nur genähert um den MCu zu entlasten. Es ist in der Funktion jede Menge englischer Kommentar, so das man das schön langsam lesen kann.

Zusatzinfo, das ist das angesprochene grbl https://github.com/grbl/grbl

Grbl is a no-compromise, high performance, low cost alternative to parallel-port-based motion control for CNC milling. It will run on a vanilla Arduino (Duemillanove/Uno) as long as it sports an Atmega 328.

"no-compromise" und "Atmega 328" schließt sich auch ein wenig aus... Klipper ist da im Vorteil, dass es seine Berechnungen auf einem Raspberry Pi durchführen kann, der irgendwas wie 10000 mal schneller ist bei floating point Berechnungen. Trotzdem ist es natürlich ein erheblicher Programmieraufwand, Kreisbögen anders zu implementieren als durch lineare Annäherung. In der Praxis ist das auch nicht unbedingt relevant, solange die Abweichungen vom idealen Kreisbogen viel kleiner als z.B. die mechanischen Ungenauigkeiten.