Ich hänge dir hier mal meine Fusion360-Profildatei an, die ich damals benutzt habe. Wenn ich das richtig sehe, habe ich da die G2/G3 Codes deaktiviert und durch lineare Annäherung ersetzen lassen. In dem Fall wäre es gut möglich, dass die RFx000-Firmware die Befehle nicht korrekt interpretiert.

So jetzt mal ein "unbelasteter" Test.

Folgendes Setup:
ein fest eingeklemmter Bleistift in der Fräshalterung und den Dremel von 230V abgesteckt.
Dann die Z-Höhe so knapp eingestellt, dass er gerade die letzten 2-3 Fräsbahnen aufs Papier zeichnet.

-->Keine Vibrationen, kaum Einfluss der Riemen, Keine Belastung des Fräsers (sonst wäre der Bleistift wahrscheinlich runtergefallen)

etwas schwieriger zu erkennen aber dasselbe Muster. Sogar die Verwacklungen in den Radien des D-Sub Ausschnittes kann man erahnen. Und die Führungsschienen hab ich auf X&Y beide drinnen, sehe aber keinen Unterschied wenn ich den 2ten Wagen beim X-Fräsen an oder Abschraube (ich hatte Anfangs eine Verklemmung des entfernten X-Wagens vermutet).

Morgen geht es dann mal an unterschiedliche Kreisdurchmesser.
Werde das vermutlich wieder Fräsen, ist sonst so kompliziert von der Höhe einzurichten.

Hab's gerade erst gesehen Martin,

das Probiere ich dann Morgen auch noch aus, Danke dir!

Grüße
Simon

Äh ja das sieht ziemlich eindeutig nach einer falschen Interpretation des G-Codes aus.

Hallo s.best,

Falls es sich hier wirklich darum handelt:

mhier hat geschrieben:In dem Fall wäre es gut möglich, dass die RFx000-Firmware die Befehle nicht korrekt interpretiert.

Könnte es
a) an der Firmware Version liegen, die du einsetzt
oder
b) am 'G3' Befehl liegen.
Ich habe mir dein GCode-Schnipsel aus dem ersten Beitrag im Thread angesehen. Da kommt (in den kurzen Stück) nur der 'G3'-Befehl vor. Zum Vergleich habe ich mir eine alte GCode Datei von mir angesehen (aus diesem Beitrag). Dort kommt 173 Mal 'G2' und 'nur' 41 Mal 'G3' vor.
In den Bildern sieht man einige Bilder des gefrästen Alu-Blechs. Die Bohrungen sind nicht so klein wie bei dir (3.5mm Durchm.), sind aber deutlich 'runder' als deine problematischen Bohrungen. Meine Firmware Version war damals (glaube ich) RF.01.33, also nicht die Community Version. Allerdings glaube ich nicht, dass es an der Firmware liegt, denn Nibbels hätte dort in den Quellcode nie eingreifen müssen (oder?).
Auch habe ich dein GCode-Schnipsel in Repetier-Host geladen. Das Resultat:Damit liegt es auch nicht am erzeugten GCode.

Als weitere Möglichkeit möchte ich einen unerkannten Bruch der Motorachse auflisten. Es gab schon bei einem hier im Forum eine gebrochene (Extruder- ?) Achse. Dabei hat sich das Rändelrad noch gedreht, aber bei jedem Richtungswechsel 'hinkte' es ein wenig nach. So ein Verhalten beim X- oder Y-Motor könnte so ein Verhalten, wie bei dir, verursachen. Zur Prüfung einfach alle Achsen homen, dann das Bett und den Extruder händisch in jeweils beide Richtungen zu drücken versuchen (es müssen beide Motoren unter Strom stehen!). Gibt eines der Achsen nach, wäre das ein deutlicher Hinweis.

COVID-19 für keinen! Impfung für alle!

mjh11

Leicht off-topic: Wenn ich mir gerade noch mal dein erstes Bild ansehe: Ich würde dir wärmstens empfehlen, mehr Haltestege zu verwenden. Mit nur zwei Stegen kann das mittlere Teil sich leicht verkippen um die Achse, die von den beiden Stegen gebildet wird. Auf das Teil wirken ja durchaus Schnittkräfte. Wenn es blöd läuft, zieht sich das Teil dann in den Fräser rein und der bricht sofort ab. Ist mir schon passiert (allerdings bei dickerem Material).

rf1k_mjh11 hat geschrieben: Allerdings glaube ich nicht, dass es an der Firmware liegt, denn Nibbels hätte dort in den Quellcode nie eingreifen müssen (oder?).

Doch hat er.

Es ging damals um schnelleres Drucken, damit der Drucker noch die Kurve bei kleineren Radien bekommt.
Es ging auch um die Rechenzeit der MCU.
Bei schnellerer Geschwindigkeit haut die MCU nicht einen Stepp nach dem anderen raus,
sondern fast bis zu 4 Stepps zusammen und haut die gebündelt raus.

Nibbels hatte das hier im Forum, als Gangschaltung beschrieben.
Auch gab es eine ganze Zeit lang im Druckermenü eine Stelle die DPL, oder so ähnlich hieß.
Dort war etwa ein Wert mit 6000 hinterlegt.
Leider hat Nibbels dieses zu meinem Bedauern entfernt.
Soviel zur absoluten Userkontrolle!

Wenn es beim Fräsen Ungenauigkeiten gibt, dann bitte mal folgendes Probieren:
Die Feedrate <= 10 auf alle drei Achsen stellen.
Der Jerk sollte sich nun verkleinern lassen.
Den Jerk versuchen auf minimal zu setzen bis die FW anfängt zu mosern.
Das dürfte bei Jerk so um die 0,3 sein.


LG AtlonXP

AtlonXP hat geschrieben: Bei schnellerer Geschwindigkeit haut die MCU nicht einen Stepp nach dem anderen raus,
sondern fast bis zu 4 Stepps zusammen und haut die gebündelt raus.

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.

AtlonXP hat geschrieben: Die Feedrate <= 10 auf alle drei Achsen stellen.

Meinst du da nicht die Beschleunigung?

Generell macht die Repetier-Firmware einige Näherungen, die gerade für extrem niedrige Geschwindigkeiten falsch werden. Das ist für beschleunigte Bewegungen blöd, weil die ja theoretisch immer bei Geschwindigkeit 0 starten und enden. Daher gibt es eine Mindestgeschwindigkeit, unterhalb der keine korrekten Ergebnisse mehr zu erwarten wären, weshalb die von der Firmware umgangen werden (mittels beherztem Sprung von 0 auf die Mindestgeschwindigkeit). Der Jerk ist (entgegen seiner Bezeichnung) eine einstellbare Mindestgeschwindigkeit, mit der jede Beschleunigung startet bzw. endet. Die zuerst erwähnte Mindestgeschwindigkeit ist daher genau der kleinste erlaubte Wert für den Jerk. Diese Mindestgeschwindigkeit hängt (aufgrund der verwendeten Näherungen) von der Beschleunigung ab. Je langsamer die Beschleunigung, desto langsamer kann man fahren.

Mir ist allerdings unklar, ob nicht vielleicht auch oberhalb der von der Firmware verbotenen Mindestgeschwindigkeit nicht schon Probleme auftreten können. Vielleicht funktionieren G2/G3 daher mit niedrigen Geschwindigkeiten (im Verhältnis zur Beschleunigung) einfach nicht gut. 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).

Bei all diesen Diskussionen muss ich leider wieder erwähnen: Eben jene Probleme mit der Firmware waren für mich der treibende Faktor, auf Klipper umzusteigen. Die Repetier-Firmware (zumindest in der Version, die wir haben - es gibt m.W. inzwischen einen kompletten Rewrite, der mag anders sein) ist eine sehr hemdsärmelige Umsetzung, die sehr viele interne Workarounds braucht, um überhaupt nutzbar zu sein. Hinzu kommen noch eine Reihe handfester Bugs - du hast vielleicht einfach einen weiteren entdeckt.

Sooo jetzt hab ich mal wieder experimentiert.

erst wollte ich ausschließen, dass die G3 Befehle vielleicht vom RasPi-Repetierserver falsch per USB gesendet werden und hab die Datei mal von SD-Karte gedruckt, (und jaa ich weiß was Ihr von der SD-Karte haltet ) Aber der Fehler ist geblieben, völlig identisch zur Verbindung über USB.

Ich hab euch mal die Bilder dazu ersparen wollen.

Dann hab ich mal den Code vom Martin getestet und gleich vergessen meine Nullpositionen nach der Einrichtung einzufügen RIP Bleistift

Nach einigem Basteln hab ich es jetzt mit der Näherung über die G1 Codes am laufen und es scheint richtige Kreise zu machen.
Leider hält der andere Bleistift nicht so gut und ist bei einer Bahn leicht verrutscht.

Ich werde am Wochenende mal die Anpassungen für mein Setup und die Einrichtung machen und dann erst den Fräser wieder einschalten
Der Bleistift ist die eine Sache, ein Fräser eine andere

Ich hatte mit den G1 Befehlen jetzt allerdings schon das Gefühl als wäre die Verfahrgeschwindigkeit langsamer als vorher, kann aber täuschen. Mehr dazu am Sa oder So.

Außerdem hab ich in deinem Code auch die Z-Kompensation gefunden Martin, ich dachte das funktioniert im Fräsbetrieb garnicht.
Aber falls doch wäre ich interessiert wie du das eingerichtet hast. Außerdem müssten doch die DMS mit dem 2ten Wagen garnicht mehr funktionieren oder Zumindestens eine viel höhere Schwelle haben bei dem Gewicht vom Dremel?

Vielleicht hat ja jemand einen Tipp zum Vorgehen der Z-Kompensation, da will ich mir die Schneiden vom Fräser ja auch nicht verdrücken.

@mhier:
Das mit den Haltestegen hab ich auch schon gemerkt, nachdem die wirklich leicht mit dem Cuttermesser zu entfernen sind hab ich jetzt bei den neuen Fräsungen auch mehr eingebaut, wollte es jetzt mit dem einen File aber für alle Tests konstant haben.
[/quote]
Hinzu kommen noch eine Reihe handfester Bugs - du hast vielleicht einfach einen weiteren entdeckt.[/quote]
Auch ein blindes Huhn findet wohl mal ein Korn

@AthlonXP:
[/quote]
Wenn es beim Fräsen Ungenauigkeiten gibt, dann bitte mal folgendes Probieren:
Die Feedrate <= 10 auf alle drei Achsen stellen.
Der Jerk sollte sich nun verkleinern lassen.
Den Jerk versuchen auf minimal zu setzen bis die FW anfängt zu mosern.
Das dürfte bei Jerk so um die 0,3 sein.
[/quote]

Ich muss gestehen, dass ich keine Ahnung habe was ich hier tun soll, da reicht mein Kenntnisstand in Fusion oder in der Firmware bei weitem nicht aus. Aber Danke dir für den Tipp!

Schöne Grüße
Simon

Feedrate =10 mm/s
ACC = 1000 mm/s²
Jerk = 0,33 mm/s
Diese Werte lassen sich in unserem Druckermenü einstellen.

@ mhier, wie du dich vielleicht noch erinnern kannst, halte ich zu hohe Jerk Werte für Verbesserungswürdig.
Bei dem Drucken (mit hoher Geschwindigkeit) werden die Ecken an einem Würfel durch den hohen Jerk abgerundet und das Fahrverhalten überschwingt.
Auf den Punkt gebracht, der Druck wird ungenau…

Da du noch der letzte Programmierer von uns bist, wollte ich mit meinem Beitrag nur mein Halbwissen beisteuern.

mhier hat geschrieben: Meinst du da nicht die Beschleunigung?

Ich meinte wirklich die Feedrate!
Wenn die Verfahr- Geschwindigkeit sehr niedrig angesetzt ist mit 10 mm/s, dann wird diese in kürzester Zeit erreicht.
Sagen wir mal in 0,1 Sekunden ist diese erreicht.

Was soll da noch ACC mm/s² bewirken, bei einer so geringen Zeit.
Man könnte es fast rechnerisch wegkürzen.

Jerk und die Verfahr Geschwindigkeit ist in der FW auf jeden Fall miteinander gekoppelt.
Das bedeutet wenn Jerk gesenkt werden soll, muss auch die Geschwindigkeit gesenkt werden.

Was ich noch nicht getestet habe ist, spielt um den Jerk zu senken der Wert ACC auch in der FW Rechnung eine Rolle, wenn man mit so niedriger Geschwindigkeit fährt?

LG AtlonXP