[URGENT] FORCE_MOVE moves only one motor on a dual Z-axis printer

[marcocipriani01]

Fluidd Version

v1.20.0

Browser

Chrome

Device

Desktop PC

Operating System

Windows

What happened

Using the FORCE_MOVE command on my dual Z-axis printer, only one Z motor is activated. When I tried moving the printer up by 50mm, the X gantry started bending very badly and got nearly destroyed. Luckily I noticed, unplugged the printer in time and turned the motors by hand.

What did you expect to happen

The two Z motors turning together.

How to reproduce

Press on FORCE_MOVE, then move the printer up by some amount. Only one of the two Z motors will move up.

Additional information

From the command line I can see Fluidd invokes the following command:

FORCE_MOVE STEPPER=stepper_z DISTANCE=1 VELOCITY=10 ACCEL=200

stepper_z, in my case, is only the right Z motor. The left motor is stepper_z1.

From what I know, there is no way of doing FORCE_MOVE with two stepper parameters, so this bug fix would need coordination with the Klipper developers to add a second (or third and so on) STEPPER= parameter. It is, however, such a dangerous bug that _I would advice disabling (in the Fluidd code, as soon as possible) the FORCE_MOVE feature for the Z axis on all 3D printers with more than one Z motor_ until a complete fix in the Klipper and Fluidd code is achieved. I hope nobody breaks his printer in the meantime.

P.S.: You guys are really trying everything to destroy my printer! See #814 😂😂

[pedrolamas]

Thanks for reporting this @marcocipriani01, and you are correct, this is a nasty bug!

@BastelKlug @matmen The easy fix here is to check that if there's a stepper_k1 (where k is the axis) we just disable the arrows when Force Movement is enabled.

However, I'm starting to think that we should NOT use the default "movement arrows" style buttons as we currently do when Force Movement is enabled, but instead show a list of the available steppers with just a + & - buttons.

Thoughts?

[marcocipriani01]

The easy fix here is to check that if there's a stepper_k1 (where k is the axis) we just disable the arrows when Force Movement is enabled.

Perfect, but I would consider it a temporay solution. I often need to move the Z axis without homing. For example, if I'm changing a nozzle and I need a little more space (but I can't home the printer with the hotend partially disassembled), I use SET_KINEMATIC_POSITION X=100 Y=100 Z=100 to enable the arrows and move the printer up. This is a hacky solution and, if I later forget to actually home the printer and start moving the X axis, I often either hit the end of the gantry to the right or can't move the printer to the left anymore. Using FORCE_MOVE makes the buttons a different color, so I remember to home the printer after I'm done with the nozzle swap (but obviously I can't use it right now to move the Z axis).

Since my Anycubic Mega has two Z motors, if I move the printer up by hand (like I would do on an Ender 3) I need to run Z_TILT_ADJUST before starting a print, which is annoying. Hence the need to use either SET_KINEMATIC_POSITION or FORCE_MOVE.

However, I'm starting to think that we should NOT use the default "movement arrows" style buttons as we currently do when Force Movement is enabled, but instead show a list of the available steppers with just a + & - buttons.

That wouldn't solve my problem, because I wouldn't be able to move the Z axis anyway (unless I want to break it). The arrows are perfectly fine, but I think the best long-term solution is allowing multiple steppers in the FORCE_MOVE command.

As a workaround, for now, I created this macro:

[gcode_macro FORCE_MOVE_UP]
gcode:
    SET_KINEMATIC_POSITION Z=100
    G91            ; Relative positioning 
    G1 Z+50
    M84            ; Turn off motors

[pedrolamas]

That wouldn't solve my problem, because I wouldn't be able to move the Z axis anyway (unless I want to break it).

There is a difference between being able to do something and actually making sense to do it... the truth is the Klipper does allow you to perform separate stepper (forced) movement, but in your case you know you should not do it (well, I believe having a stepper_k1 should be reason enough to NOT allow it in the interface)

The arrows are perfectly fine, but I think the best long-term solution is allowing multiple steppers in the FORCE_MOVE command.

As you very well put on the first post, that requires Klipper changes, so not something we can act upon here right now!

---

As a first step here, I think it is reasonable to just disable controls for an axis K if a stepper_k1 exists.

[marcocipriani01]

Ok fair enough!

[matmen]

The easy fix here is to check that if there's a stepper_k1 (where k is the axis) we just disable the arrows when Force Movement is enabled.

I agree, this seems like the best (/only) fix as of now, however I'm not sure Klipper would get multi-stepper support for FORCE_MOVE any time soon.

However, I'm starting to think that we should NOT use the default "movement arrows" style buttons as we currently do when Force Movement is enabled, but instead show a list of the available steppers with just a + & - buttons.

I'm fine with the movement arrows, in the end implementing a new system for stepper selection doesn't solve the problem (can still only move one stepper at a time, unless I'm missing something here).