Klipper3d / klipper

Klipper is a 3d-printer firmware
GNU General Public License v3.0
9.24k stars 5.26k forks source link

Z acceleration limit is ignored under some circumstances #2308

Closed ghost closed 4 years ago

ghost commented 4 years ago

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

no M0 wait before Z movement M0 wait before Z movement

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.

ghost commented 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.

JohnEdwa commented 4 years ago

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.

ghost commented 4 years ago

@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.

JohnEdwa commented 4 years ago

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?

KevinOConnor commented 4 years ago

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