Closed ghost closed 4 years ago
I have found a working solution:
If I set square_corner_velocity = 0, the problem goes away. I assumed that this parameter only influences X and Y. I'm still not 100% sure what this parameter does EXACTLY, but it seems that you have to set it to 0 if you want X, Y and Z to follow exactly the specified acceleration limits.
If this is indeed the solution, the issue can be closed.
IIRC, square_corner_velocity
works in a similar (but not the same) fashion as Marlins Jerk setting, and that is simply the speed in which the axis is instantly stopped/accelerated to when changing direction.
So if you are approaching a 90degree turn at 50mm/s from X to Y, with a square_corner_velocity
of 5, it would deaccelerate X from 9>8>7>6>5>0, then accelerate Y from 0>5>6>7>8... With square_corner_velocity
0 it would go all the way to 0 - X6>5>4>3>2>1>0, then Y 0>1>2>3>4>5>6.
It's there to be able take corners as fast as possible to reduce oozing and bulging the corners, but without skipping steps as obviously you can't instantly accelerate/deaccelerate an axis to really high speeds.
So in this case, your Z-axis is instantly accelerated/deaccelerated to/from the square_corner_velocity
value instead of using 0.
Not really sure if it's the intended behaviour or just an oversight.
@JohnEdwa Thanks, now I understand what this setting does. This was totally non obvious from the description to me. This also explains the problem I have and why it went away when I changed it to square_corner_velocity = 0.
I still think the Z-axis shouldn't use square_corner_velocity
value at all. Not only is it not obvious or explained in the documentation, the Z-axis has a much lower maximum value for that than the others as it's fighting gravity.
@KevinOConnor is this intended or a bug/oversight?
Yes, it is intended and desirable to apply square_corner_velocity to Z moves. Otherwise, "vase mode" printing would not work well.
FWIW, the actual instantaneous velocity change is controlled by both square_corner_velocity and acceleration. So, if accel=3000, max_z_accel=30, and square_corner_velocity=5 then a 90 degree corner within the XY plane would result in a 5mm/s instantaneous velocity change, but a 90 degree corner to the Z plane would result in a .05mm/s instantaneous velocity change.
-Kevin
Klipper ignores Z-acceleration limit under some circumstances and jumpes directly to maximum specified speed. This causes my Z-Axis stepper to skip and loose steps. However I found a workaround, which might help to solve this bug: If I insert an M0 command before the Z-movement, Octoprint pauses the gcode and after I click on resume, the Z-acceleration limit is obeyed and a normal accelerated move is performed.
I attached the gcode, which I reduced to a few lines, which reproduces the problem. I also attached two oscilloscope pictures, where one can see the missing Z-Acceleration in one of the pictures at the beginning of the movment. The other prictures shows the correct accelerated movement recorded with the M0 command before the Z movement. The pictures were recorded with a hall-current-probe attached to one of the Z-motor wires. nail test.gcode.txt
klippy.log
Disclaimer: I'm using a 3D-printer hardware to build an automated nailgun, so don't wonder why my speeds and accelerations are untypical for 3D printing.