I’ve updated from 412 to 414 and in the configuration I’m seeing Junction is now 0.1 instead of 0.01, so that should be a big help. I did a video before and after and I am still seeing sluggish behavior around arcs. I used the crown svg and Estlcam with a feed rate of 720 mm/min, aiming for the same 12 mm/sec as the official test gcode.
Here is before, version 412:
And after, version 414:
In both cases the movement queue was not being depleted so I don’t think it’s a CPU issue.
I ported over my personal preferences which I don’t think are relevant to this test, but I’ll list everything in case:
- #define MOTHERBOARD BOARD_MKS_GEN_L
- #define USE_ZMAX_PLUG
- #define X_MIN_ENDSTOP_INVERTING false
- #define Y_MIN_ENDSTOP_INVERTING false
- #define Z_MIN_ENDSTOP_INVERTING false
- //#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
- #define Z_MIN_PROBE_PIN Z_MIN_PIN
- #define FIX_MOUNTED_PROBE
- #define Z_MIN_PROBE_REPEATABILITY_TEST
- #define Z_HOME_DIR 1
- #define NUM_SERVOS 4
- #define SERVO_DELAY { 300, 300, 300, 300 }
And in Configuration_adv.h:
- #define BEZIER_CURVE_SUPPORT
- #define G38_PROBE_TARGET
- #define G38_PROBE_AWAY
- #define JOYSTICK
- #define JOYSTICK_DEBUG
- #define MAX7219_DEBUG
- #define MAX7219_CLK_PIN 42
- #define MAX7219_DIN_PIN 63
- #define MAX7219_LOAD_PIN 40
I’m going to try disabling S_CURVE_ACCELERATION and ADAPTIVE_STEP_SMOOTHING. If neither makes a difference then I’ll try increasing JUNCTION_DEVIATION to a “crazy” value and see what happens and then after that who knows. Maybe I’ll try classic jerk just to see. Maybe I’ll play with arc parameters and see what happens. Or see how much of a difference the acceleration values have.