AtlonXP hat geschrieben:@ mhier, wie du dich vielleicht noch erinnern kannst, halte ich zu hohe Jerk Werte für Verbesserungswürdig.

Ja, du redest von mechanischen Instabilitäten. Ich von numerischen in der Firmware

Wenn ich mir die Fotos anschaue, glaube ich eher an numerische Probleme. Statt eines Kreises fährt er ein Viereck. Das sieht man sehr klar in Post #7. Die Kanten der Raute sind ziemlich gerade. Die abgerundeten Ecken dürften genau dem Fräserdurchmesser entsprechen (rate ich mal). So etwas kommt nicht durch mechanische Probleme, das halte ich für extrem unwahrscheinlich.

Ich würde einfach G2/G3 bei der Repetier-Firmware vermeiden, und mir generell überlegen, auf Klipper umzusteigen.

Hallo mhier,

mhier hat geschrieben:Bin mir nicht sicher, ob es da einen Zusammenhang gibt. G2/G3 Befehle werden meines Wissens von keinem Slicer generiert. 3D-Drucker müssen diese Befehle also gar nicht unterstützen. Absichtlich wird er also wohl eher nichts daran verändert haben. Es kann gut sein, dass er die Befehle aber versehentlich kaputt gemacht hat. So viel ich weiß zerlegt die Firmware G2/G3 Befehle intern in kleine, lineare Teilstücke, die dann genauso behandelt werden, wie G0/G1.

(Derzeitige) Slicer benötigen/erzeugen keine G2/G3 Codes, da alle Slicer zurzeit mit *.stl arbeiten, bzw. Varianten, die im Grunde auf einem Mesh basieren (so wie *.stl auch). Da das *.stl-Format nur aus Geraden besteht, gibt es (praktisch) keinen Bedarf Kurven mittels G2/G3 zu erzeugen, das wäre ein zusätzlicher Aufwand für die Slicer. ABER: Für das Fräsen kommen sehr häufig G2/G3 vor. Diese werden auch von vielen CAM-Programmen erzeugt (z.B. auch das von s.best eingesetzte Fusion 360).

mhier hat geschrieben:Vielleicht funktionieren G2/G3 daher mit niedrigen Geschwindigkeiten (im Verhältnis zur Beschleunigung) einfach nicht gut.

Ich habe, mit der Repetier-Firmware (allerdings nicht die Community Version), eben diese Fräsarbeiten in dem vorhin verlinkten Beitrag durchgeführt. Da es sich dabei um meine ersten Versuche handelte, hatte ich schon sehr niedrige Geschwindigkeiten eingesetzt. Bei mir waren die Löcher (3.5mm Durchmesser) aber rund. Könnte es sein, dass dieser komische Fehler erst bei kleineren Durchmessern auftritt, dafür gleich so extrem?

mhier hat geschrieben:Dummerweise limitiert die Beschleunigung auch noch die Geschwindigkeit, mit der du eine Kreisbahn fahren kannst, denn eine Kreisbewegung ist ja permanent beschleunigt (abhängig von Radius - das ist mathematisch/physikalisch korrekt).

Ich dachte, der Slicer spart sich das Beschleunigen/Verzögern wenn der Winkelunterschied zwischen zwei Liniensegmenten unter einem bestimmten Wert fällt.
Zum Beweis habe ich gerade einen Ring mit 200mm Durchmesser konstruiert und mit ziemlich hoher Auflösung als STL exportiert. Dabei entstehen Liniensegmente unter 3mm Länge.Zusätzlich habe ich eine sehr hohe Druckgeschwindigkeit von 200mm/s vorgegeben. Als ich das Objekt druckte (nur im 'Dry Run Modus, also ohne Extrusion!) fetzte der Druckkopf nur so hin und her. Dieses Verhalten scheint meine Aussage zu bestätigen. Oder habe ich dich falsch verstanden? Natürlich unterliegt jede Fahrt entlang einer Kreisbahn der Zentripetalkraft, was man auch einer Beschleunigung gleichsetzen könnte, aber das kann es nicht gewesen sein, oder?

mhier hat geschrieben:Ich würde einfach G2/G3 bei der Repetier-Firmware vermeiden

Ich für meinen Teil habe (zumindest mir) bewiesen, dass das Problem nicht am G2/G3 liegt (zumindest bei der original-Firmware). Der Fehler liegt entweder an der Community Version oder an der Hardware von s.best (idazu zähle ich auch die Systemplatine).

Man kann, was ich mich erinnere, die Erzeugung von G2 und G3 in Fusion unterbinden. Das wäre also trotz allem noch eine Möglichkeit.

Gesundheit allerseits!

mjh11

Hallo Leute,

ich weiß ich hatte für heute ein Update versprochen, und habe bereits einen weiteren Test gemacht.
Zum Dokumentieren fehlt mir aber heute einfach die Kraft, ich verfasse den Eintrag dazu morgen.

Schöne Grüße
Simon

Wie versprochen habe ich am Wochenende einige weitere Tests zum Fräsen gemacht.
Leider bin ich nicht ganz so weit gekommen wie ich gehofft hatte, das Wetter war einfach zu schön.

Ich wollte noch ein Plexiglas-Teil fräsen und habe mich entschieden das gleich mit Martins Code zu versuchen.
Also den 3mm Fräser genommen und gehofft das alles gut geht

Ich bin mit dem Ergebnis schon sehr zufrieden und denke ich werde erstmal mit dem G1 Postprozessor weiterarbeiten.
Leider ist Plexiglas schwierig zu Fotografieren aber die Radien und Durchmesser haben alle gestimmt.
Für meine Geschwindigkeiten bin ich beim Plexiglas noch nicht annährend optimal und denke da werde ich nochmal Einschneiden-Fräser bestellen für die Zukunft.

Als nächstes Wollte ich den ursprünglichen Job nochmal auf meinem 2ten RF2000, den ich als 3D Drucker stehen habe, laufen lassen um einen Fehler im Setup auszuschließen (wie von mjh11 vorgeschlagen).

Ich melde mich sobald ich genaueres dazu weiß

Schöne Grüße
Simon

Sorry für die späte Antwort, war im Urlaub

rf1k_mjh11 hat geschrieben:Könnte es sein, dass dieser komische Fehler erst bei kleineren Durchmessern auftritt, dafür gleich so extrem?

Alles ist möglich

Ich dachte, der Slicer spart sich das Beschleunigen/Verzögern wenn der Winkelunterschied zwischen zwei Liniensegmenten unter einem bestimmten Wert fällt.

Der Slicer hat mit den Beschleunigungen (Verzögerungen sind für mich nur negative Beschleunigungen Ich meine also immer beides) nichts zu tun. Das macht die Firmware. Ich bin mir nicht ganz sicher, wie Repetier das löst. Meinem Verständnis nach gibt es keine Grenze bei der Beschleunigung oder beim Winkel, es gibt aber den Jerk, der die Geschwindigkeit festlegt, auf die nicht beschleunigt wird. Unterhalb eines gewissen Kurvenradius fährt er also mehr oder weniger permanent mit der Jerk-Geschwindigkeit. Ich denke, bei größeren Radien wird er graduell schneller, und zwar abhängig von der eingestellten Beschleunigung (alles andere wäre ziemlicher Unsinn). De facto wird man daher bei sehr großen Kurvenradien keine große Reduktion der Geschwindigkeit feststellen.

Natürlich unterliegt jede Fahrt entlang einer Kreisbahn der Zentripetalkraft, was man auch einer Beschleunigung gleichsetzen könnte, aber das kann es nicht gewesen sein, oder?

Naja, du kannst ja die Achsen getrennt betrachten (macht ja durchaus Sinn, sind schließlich unterschiedliche Motoren). Wenn du einen Kreis fährst (nimm mal einen echten an erstmal), haben beide Motoren ein sinusförmiges Geschwindigkeitsprofil (mit 90-Grad Phasenversatz). Die Beschleunigung ist dann die Steigung/Ableitung, also wieder sinusförmig. Solange die stärkste Beschleunigung also kleiner/gleich der maximal zugelassenen Beschleunigung ist, muss die Firmware ja nicht langsamer werden.

Mit angenäherten Kreisen durch lineare Teilstücke wird es etwas komplizierter. Bei Klipper gibt es die corner velocity als Äquivalent zum Repetier-Jerk. Das ist die Geschwindigkeit mit der eine 90-Grad-Ecke gefahren wird. Flachere Winkel werden laut Doku entsprechend schneller durchfahren. Ich nehme an, diese corner velocity bestimmt den zulässigen Geschwindigkeits-Sprung auf jeder einzelnen Achse. Ich könnte mir vorstellen, dass Repetier das ähnlich macht.

mhier hat geschrieben:Ich für meinen Teil habe (zumindest mir) bewiesen, dass das Problem nicht am G2/G3 liegt (zumindest bei der original-Firmware).

Zu beweisen, dass etwas korrekt implementiert ist, ist immer schwer bis unmöglich, da man den gesamten Parameter-Raum prüfen müsste. Das eine kaputte Beispiel beweist aber schon, dass G2/G3 nicht korrekt implementiert ist in Repetier

Da der gezeigte G2/G3 Code in einer Simulation z.B. per https://nraynaud.github.io/webgcode/ korrekt aussieht aber das falsche Ergebnis produziert, ist definitiv die Firmware-Implementierung falsch. Das gilt sicherlich nur für gewisse Parameter-Kombinationen, ggf. einschl. der eingestellten Beschleunigung/Jerk etc.