Make movement tracking more lenient

[rcloran]

Thank you for your work on load cells! I'm setting klipper up on my Prusa MK4S, and have had a hard time getting probing to work reliably. Specifically, the deconstruction of movements is unreliable -- there are cases where it works, and cases where it doesn't, depending on distance of move, among other things.

This seems to fix most of my headaches, but I'm not sure of its correctness. I've only been using klipper for 3 or 4 days now, and so I've got lots to learn about its movement system, among other things :) I'm happy to take feedback and go and test something different on my machine.

The change at L380 helps to avoid triggering the num_moves check later on when there is a move sequence like this:

{'print_time': 389.8337528809523, 'move_t': 0.15811388300841897, 'start_v': 0.0, 'accel': 200.0, 'start_x': 4.0, 'start_y': 0.0, 'start_z': 5.0, 'x_r': 0.0, 'y_r': 0.0, 'z_r': -1.0},
{'print_time': 389.99186676396073, 'move_t': 0.15811388300841897, 'start_v': 31.622776601683793, 'accel': -200.0, 'start_x': 4.0, 'start_y': 0.0, 'start_z': 2.5, 'x_r': 0.0, 'y_r': 0.0, 'z_r': -1.0},
{'print_time': 390.2336346011905, 'move_t': 0.0, 'start_v': 0.0, 'accel': 0.0, 'start_x': 4.0, 'start_y': 0.0, 'start_z': 0.04500000000007631, 'x_r': 0.0, 'y_r': 0.0, 'z_r': 0.0},
{'print_time': 390.3846626011904, 'move_t': 0.0016000000000000003, 'start_v': 0.0, 'accel': 200.0, 'start_x': 4.0, 'start_y': 0.0, 'start_z': 0.04500000000007631, 'x_r': 0.0, 'y_r': 0.0, 'z_r': 1.0},
{'print_time': 390.3862626011904, 'move_t': 0.31089999999999995, 'start_v': 0.32, 'accel': 0.0, 'start_x': 4.0, 'start_y': 0.0, 'start_z': 0.04525600000007631, 'x_r': 0.0, 'y_r': 0.0, 'z_r': 1.0},
{'print_time': 390.6971626011904, 'move_t': 0.0016000000000000003, 'start_v': 0.32, 'accel': -200.0, 'start_x': 4.0, 'start_y': 0.0, 'start_z': 0.1447440000000763, 'x_r': 0.0, 'y_r': 0.0, 'z_r': 1.0}]

I don't know why there is a move that looks like a no-op at 390.233 (index 2), but filtering it seems to work.

The change at L364-L374 is because I seem to get move patterns without a stopping acceleration in some cases -- I /think/ it's when the load cell triggers before the deceleration move has a chance to be scheduled, but I'm not sure.

trapq move: {'print_time': 1606.16218075, 'move_t': 0.005, 'start_v': 0.0, 'accel': 200.0, 'start_x': 0.0, 'start_y': 0.0, 'start_z': 5.0, 'x_r': 0.0, 'y_r': 0.0, 'z_r': -1.0}
trapq move: {'print_time': 1606.1671807500002, 'move_t': 5.096700523809432, 'start_v': 1.0, 'accel': 0.0, 'start_x': 0.0, 'start_y': 0.0, 'start_z': 4.9975, 'x_r': 0.0, 'y_r': 0.0, 'z_r': -1.0}
trapq move: {'print_time': 1611.4151203214287, 'move_t': 0.0016000000000000003, 'start_v': 0.0, 'accel': 200.0, 'start_x': 6.312832201427199e-14, 'start_y': 0.0, 'start_z': 0.15250000000007624, 'x_r': 0.0, 'y_r': 0.0, 'z_r': 1.0}
trapq move: {'print_time': 1611.4167203214288, 'move_t': 0.3108999999999999, 'start_v': 0.32, 'accel': 0.0, 'start_x': 6.312832201427199e-14, 'start_y': 0.0, 'start_z': 0.15275600000007625, 'x_r': 0.0, 'y_r': 0.0, 'z_r': 1.0}
trapq move: {'print_time': 1611.7276203214287, 'move_t': 0.0016000000000000003, 'start_v': 0.32, 'accel': -200.0, 'start_x': 6.312832201427199e-14, 'start_y': 0.0, 'start_z': 0.2522440000000762, 'x_r': 0.0, 'y_r': 0.0, 'z_r': 1.0}

With these changes I'm able to successfully get a bed mesh and measure probe accuracy on my MK4S.

[garethky]

I think this is a config thing. You want to set you Z axis up so that the minimum Z value is negative.

When you do a probing move, the move will stop at whatever the axis minimum value is. If the machine is homed to 0 and the axis minimum is also 0 then you see deceleration moves getting scheduled in probes. There is going to be some spot on your bed that is lower than the homed 0 location is. In that spot the probe cant work correctly because it cant actually hit the bed.

So the solution is to configure the axis so it can go below zero:

[stepper_z]
position_min: -5

This will allow the probe to go below the homed z value and always hit the bed. It will trigger before any deceleration move gets scheduled. This is how the vast majority of klipper printers are set up. "Its just klipper things"

If you try the config change and remove this patch and everything is OK then that's the root cause.

[rcloran]

I'm pretty sure I had a negative allowed z (only 1 or 2mm, though) when I first was experimenting with this. I definitely do now -- I'll play with this more tomorrow and see if I can avoid it with config.

[rcloran]

Yup, you were right, with position_min: -1 it looks like it works successfully without this change. Thanks for the help, closing!

[rcloran]

It'd be nice if there was maybe a warning or something to catch this misconfiguration. Not sure exactly how that should work, but if you have ideas on how it might look I'd be happy to take a stab at writing it.

[garethky]

Yes I agree, a warning/error would be ideal. Maybe by detecting that move #3 is a deceleration move and that's not expected?