FORCE_MOVE fails with no next step error

[yschroeder]

When using the FORCE_MOVE command, Klipper shuts down with: MCU 'mcu' shutdown: No next step.

I suspect that there is some timing problem when using multiple MCUs for different axes.

Note, that I use the hangprinter kinematics, but I observed the same when using cartesian kinematics with the current master branch.

klippy_nonextstep.log

[KevinOConnor]

The "no next step" error occurs when a stepper does not decelerate from speed. It is intended as a safety check to ensure that communications aren't lost between host and micro-controller mid-move. It's being thrown on a FORCE_MOVE, because FORCE_MOVE does not accelerate nor decelerate. To address this, we could: 1 - remove this sanity check from the mcu code, 2 - disable the check on cable winch kinematics (call stepper.set_max_jerk(99999999.9, 999999999.9) ), or 3 - modify FORCE_MOVE to perform accel/decel.

-Kevin

[yschroeder]

I like the third option best. FORCE_MOVE currently results in very rough movement. This also works for other kinematics and does not need special handling of cable winch kinematics.

[KevinOConnor]

FYI, acceleration support has been added to the FORCE_MOVE command (commit d62a41b).

-Kevin

[yschroeder]

Nice! @til-k is working on our cable robot right now, so he will come back to you with results.

[KevinOConnor]

I'm going to close this for now, as I think it should be possible to avoid this issue (and FORCE_MOVE is only intended as a debugging command).