RF1000 akzeptiert Jerk einstellungen nicht...

[eschmo]

Hallo Liebe RF Gemeinde,

ich habe ein eklatantes problem mit dem drucker oder der FW welches ich nicht verstehe...

Ich gebe dem Drucker klare Anweisungen welchen Jerk er verwenden soll.
Ich habe die config der FW auch entsprechend angepasst.

Code: Alles auswählen

#define MAX_JERK                            5.0                 //std: 20, aber RFx000 sieht zwischen ca. 7 und 18 am besten aus: Renkforce sagt 10
#define MAX_ZJERK                           0.3                  //std: 0.3

unabhängig des oberen Limits welches ja ignoriert werden soll wenn der eeprom mode entsprechend gesetzt ist (ich habe alles an werten ausprobiert mit immer gleichem ergebniss)

Code: Alles auswählen

#define EEPROM_MODE                         44

was nun aber immer passiert, ist, das der drucker keinen wert akzeptiert sondern folgendes auswirft...

14:39:27.743: N1096 m207 X18 Z0.3 E12
14:39:27.747: XY-Jerk:18.00
14:39:27.767: XY jerk was too low, setting to 25.03
14:39:27.767: Z-Jerk:0.30
14:39:27.767: Z jerk was too low, setting to 0.40

14:40:43.654: N1172 m207 X13 Z0.3 E12
14:40:43.676: XY-Jerk:13.00
14:40:43.676: XY jerk was too low, setting to 25.03
14:40:43.677: Z-Jerk:0.30
14:40:43.677: Z jerk was too low, setting to 0.40

14:41:07.623: N1197 m207 X5 Z0.3 E12
14:41:07.643: XY-Jerk:5.00
14:41:07.644: XY jerk was too low, setting to 25.03
14:41:07.644: Z-Jerk:0.30
14:41:07.644: Z jerk was too low, setting to 0.40

mir wäre es ja weitestgehend egal was er da im hintergrund tut, leider hat es eklatanten einfluss auf die druckqualität wenn er derartig hart ums eck knallt. ich bekomme logischer weise keine kleinen kreise mehr gedruckt bzw gehaftet und wenn ich den speed etwas anziehe (aktuell 40mm/s PLA) macht der drucker auch echt ordentliche knall geräusche bei der richtungsumkehr.

hat irgend jemand hier eventuell eine Idee was ich falsch mache? ich hab keine idee mehr...

VG Eschmo

[AtlonXP]

Hallo eschmo,
dein angesprochenes Problem hatte ich mit Nibbels schon ausführlich diskutiert gehabt.
Nibbels hat da eine Sperre eingebaut, mit der Begründung das dies Berechnungsgrundlage von der Repetier FW sei.

In meiner FW Community 1.45.0 ist es möglich den Jerk XY auf 10.33 und Z auf 0.3 zu senken.
Bei mir ist ACC auf 1000 eingestellt.
Definiere deinen Jerk und ACC am besten über das Druckermenü, oder per G Code in der Start Datei.

Du solltest deinen FW H Dateien auf den Normalen Wert zurückstellen.
Ich vermute, du blockierst dir gerade die letzten Einstellmöglichkeiten damit.

In der Community FW 1.43.99 ist diese Hemmschwelle noch nicht verbaut.
Nibbels meinte jedoch, dass da ein Fehler vorliege…

LG AtlonXP

[eschmo]

Hallo AthlonXP,

vielen Dank für dein Feedback.
Ich hab mich gestern noch etwas vergraben und bin dann auch drauf gekommen das er augenscheinlich Anhand der MaxAcc der Achsen den Jerk kalkuliert.

Was ich nur recht problematisch finde ist zum einen der immergleiche Verwendete Faktor.
Wäre es nicht sinnvoller dann den niedrigsten möglichen wert zu avisieren wenn man unterhalb der plausibilitätsgrenzen konfiguriert?
Die latent gewählten 25 sind halt gerade gut genug um dir eine echt lange Fehlersuche zu verpassen.

Problematisch finde ich unter den Umständen auch ein weiteres Problem.
Die in der FW Standartsettings für Travel und 2500 für acc mit und ohne Extrusion. Diese hatte ich die ganze Zeit bereits bei 1500 bzw. 1000. die ACCELERATION_MAX_XY jedoch, stehen bei 6000. Diese dachte ich nun über die Printer Settings verändern zu können. Leider Fehlanzeige.
Da dieser Wert in meiner FW Config bei 6000 stand, hat er beim Druck Begin alle anderen Werte immer auf 6000 gestellt und dann den Jerk "pervertiert". Das Hat mich in sofern irritiert als das wir ja wenigstens 3 verschiedene ACC Settings für XYZ haben. weshalb werden die werte dann während des Druckvorgangs nicht genutzt wie gesetzt?
Vor allem 6000?!? da sind Schrittverluste doch bereits beim Travel vorprogrammiert oder?

In der Situation war aktuell nur eine Lösung denkbar (ohne die FW neu aufzuspielen) und zwar die Acc's komplett per gcode in jedem StartScript einzustellen und ihm danach das Jerk-Setting zu verpassen.
Das jedoch erscheint mir etwas redundant, zumal die werte ja einer gewissen Konsistenz unterliegen und deshalb nicht zwangsläufig dynamisiert werden müssten (bis auf eventuell den jerk).

Ich hab auch erst einmal die gesamte Config auf 1000 gestellt und neu hochgeladen dann konnte ich recht ordentlich fahren. wobei ich gern für den ersten Layer noch weiter runter möchte statt 10...normal brauch ich da wahrscheinlich eher 7-8 damit die kleinen M2 Öffnungen noch vernünftig haften.

Mal so am Rande? Wie läuft denn in dem Kontext der Community Workflow für SW Anpassungen?
Kann man Anpassungen vornehmen und die irgendwie zur Integration vorschlagen?

VG Eschmo

[af0815]

Grundlegend sollte man die Einstellungen im GCode machen, da diese Einstellungen Material und Werkstückabhängig sind. Slicer hinterlegen diese Werte auch normalerweise im Startcode. Wenn nicht, so kann man es über den Script machen.

Generell sollten die Werte im Drucker nur die minimalen und maximalen Grenzen abdecken. Es macht keinen Sinn den Drucker auf eine Werkstücktype abzustimmen. Ich habe auch diesen Weg eingeschlagen und mir meine Slicereinstellungen entsprechend konfiguriert.

Besonders die Bewegungsprofile sind mit dem Umstieg auf Klipper echt gut geworden. Man merkt dort deutlich die bessere Rechenleistung vom RasPi.

[AtlonXP]

Hallo eschmo,
mein Vorredner hat es bereits auf den Punkt gebracht.

In der mir letzten bekannten Community FW 1.45.0, sollte Standardmäßig ACC auf 1500 stehen.
Wenn da was Anderes drinsteht, entzieht es sich meiner Kenntnis.

Ich empfehle ACC 1000.
Die Jerkwerte sind bei mir auf die obigen Angaben begrenzt.
Eine Diskussion darüber ist Sinnlos.
Nibbels wird vermutlich nichts mehr an unserer Community FW ändern.

LG AtlonXP

[mhier]

Meinem Verständnis nach funktionieren niedrigere Jerks schlicht nicht. Der "Jerk" bei Repetier ist auch anders als der Begriff eigentlich vermuten lässt, lediglich die Mindest-Geschwindigkeit, mit der die Firmware eine Bewegung aus dem Stillstand anfängt bzw. aufhört (z.B. bei rechten Winkeln oder 180-Grad Richtungsumkehr). Repetier kann aufgrund der Berechnungen nicht beliebig kleine Geschwindigkeiten fahren, bzw. würde dann falsche Bewegungen ausführen. Das lässt sich nicht mal so eben beheben, dazu müsste man den kompletten Beweguns-Berechungscode umschreiben und würde wohl auch schnell an die Grenzen unseres Mikrokontrollers stoßen (alles, was nicht ganze Zahlen addieren, subtrahieren oder multiplizieren ist, ist unglaublich langsam - dividieren ist also schon schwierig, Wurzel ziehen erst recht).

Es gibt eine Lösung. Vielleicht gehe ich manchen damit inzwischen auf die Nerven, wenn ich das hier so oft bewerbe, aber Klipper hat diese Probleme nicht. Das war für mich einer der Haupt-Gründe umzusteigen. Dort kannst du problemlos beim Jerk-Äquivalent (dort "square corner velocity" genannt, was es besser trifft, auch wenn die Definition nicht exakt gleich sein dürfte) eine 0 einstellen. Das heißt nicht unbedingt, dass man das tun sollte, denn dadurch wird die Geschwindigkeit einer Kurvenfahrt abhängig von Radius stark eingeschränkt, aber es gibt wenigstens kein unteres Limit durch den Algorithmus.