MANUAL STEPPER SYNC and FORCE_MOVE behavior issue in latest

General Discussion
1

Hi everyone,

I have noticed that the latest klipper queue and manual stepper refactorings broke the MANUAL_STEPPER SYNC=0 behaviour which allowed to run movements in parallel with another stepper when using it alongside FORCE_MOVE

In summary, prior to 17ce45d2, the following command sequence would run the steppers in parallel.
The update makes it execute in one after the other, SYNC having no effect.

MANUAL_STEPPER STEPPER=sp_motor ENABLE=1 SET_POSITION=0 SPEED=5 ACCEL=100 MOVE=20 SYNC=0
FORCE_MOVE STEPPER=stepper_x VELOCITY=5 ACCEL=100 DISTANCE=20

Is there a chance to restore the previous behaviour?
Thanks!

2

This commit does not touch the motion subsystem, so I suspect it has been broken later.
It would be helpful if you could identify where it has been broken: Klipper Versioning, Downgrading, and Bisecting

It is sort of a “cut”/knife move for MMU?

I’m personally a little surprised that FORCE_MOVE plays well with other motions in the system.
So, I’m not sure it was intended to work, or that there was a change that explicitly removed this functionality.

(Btw, I suspect it could be emulated with an extra axis: G-Codes - Klipper documentation)

Thanks.

3

I meant that up to in and including 17ce45d2 works fine with the commands above.
The changes that followed broke this behavior.

That command combination is at the core of the Pico MMU system for stage that syncs the MMU motor with the Extruder for loading the filament into the gear and I wrote the MMU Code around this behavior knowing that it works.

Thanks, LH

4

Maybe a klippy.log helps further.

5

Thanks for the report. However, there was never an intent for FORCE_MOVE to be strictly timed with other commands. It was just a coincidence that it worked previously.

It would be difficult to maintain any kind of strict timing in FORCE_MOVE, so I don’t foresee a future change restoring the previous behavior.

I can think of a few alternatives that may provide a solution. (These will all require changes to config/code on your side, but if they work they should be supportable in the future.)

  • Consider registering the “sp_motor” as an extra gcode axis ( G-Codes - Klipper documentation ). With that support it is possible to explicitly request simultaneous motion between motors (eg, G1 X20 R20).
  • If that isn’t possible, consider using the “sp_motor” SYNC=0 move followed by the stepper_x move implemented using a regular G1 command (instead of via FORCE_MOVE).
  • Consider remaining on older versions of the software (eg, rel-0.13.0).

Maybe that helps a little,
-Kevin

6

Thanks for the reply.

That’s unfortunate, and sadly the other options other than recommending users not to upgrade are not viable in my particular case.

-LH

7

Hi @lhndo ,

Happy Hare software (the same software that runs the ERCF, Tradrack, and many more MMUs) has support for the Pico MMU and there is beta support for the new Klipper update in the v340 branch. You might want to give that a try.

Take it from another MMU designer (I created the 3MS), Happy Hare is much more robust than simple macros for controlling an MMU, and it lets you spend more time on furthering the MMU design or working on other projects instead of debugging software issues.

8

A large portion of my work was dedicated to creating a lightweight and non bloated system, bespoke to the Pico MMU, and which supported all kind of klipper versions running from many years back.

I have no reliability problems with “simple” macros and the system is incredibly robust, so I don’t know what your claims are based on.

9

FWIW, considering the original snippet

_SP_MOTOR STOP=0 SYNC=0 SPEED={sync_speed} ACCEL={sp.motor_accel} DIST={sync_dist}
FORCE_MOVE STEPPER=extruder VELOCITY={sync_speed} ACCEL={sp.motor_accel} DISTANCE={sync_dist}

I am a bit confused why a snippet like

SAVE_GCODE_STATE
MANUAL_STEPPER STEPPER=sp_motor GCODE_AXIS=R LIMIT_ACCEL={sp.motor_accel}
G1 E{sync_dist} R{sync_dist} F{sync_speed}
MANUAL_STEPPER STEPPER=sp_motor GCODE_AXIS=
RESTORE_GCODE_STATE

I do see that _SP_MOTOR was doing some calculations for speed, distance, etc. under the hood, but you could wrap the above snippet into a similar macro like _SP_MOTOR_SYNC_E that would perform similar calculations and pass the appropriate distances as E and R parameters to G1 command. Note that F parameter controls the speed of the fastest axis here. And since in the original snippet the sp_motor and E axes should start and stop simultaneously I understand, I think it should be possible to calculate R, E and F parameters for G1 appropriately. I may be missing something here though.

10

Thanks for the suggestions Dmitry,

There are a few reasons for that:

  • Backwards compatibility is important for me since many users are running older klipper versions, or other branches. This is why I chose the klipper macro system direction as a stable API.
  • Operations which otherwise wouldn’t require heating the hotend would previously do now, or would require users to set their extruder min temp below ambient.
  • The MANUAL_STEPPER MMU motor is commanded different distances and speeds due to an internal backlash compensation algorithm and per lane RD compensation multiplier.

Could I hack something together to accommodate all the edge cases I find myself in at the moment? Possibly.

From my point of view, if there was a possibility to retain the previous behavior, that would have been ideal. Hence why I brought this issue into your attention.

Thanks,
LH