FORCE_MOVE STEPPER not working correctly for CoreXY kinematics

General Discussion
1

When using FORCE_MOVE STEPPER to move the printhead 10mm to the right, I use:

FORCE_MOVE STEPPER=stepper_x DISTANCE=15 VELOCITY=100

But this moves the print head diagonally, what I did not expect.
Theoretically it could be this way by design, since indeed only stepper motor X moves, which results in a diagonal movement of the print head.
However, this way it’s not really usable in my opinion for people with a CoreXY printer.

Is this by design?
If so, it’s almost impossible to navigate the print head this way?

“Why do you want to do that?”
After a print, the nozzle moves above a purge bucket and gcode ends.
Before a new print, I want to be able to wipe the nozzle clean before homing, else it always leaves a few cm of drooping material on the bed…

Printer Model: DIY CoreXY
MCU / Printerboard: SKR 1.3
klippy (12).log (38.6 KB)

2

FORCE_MOVE is a low level debugging tool and not intended to perform any daily routines. It completely disregards any kinematic constraints.
You can use homing_override to fine tune your startup routines

1 Like
3

Alright, so it’s by design.
Dis not see homing_override before. This could work for me, thanks!

4

Wonder how homing_override works?
I’ve got this in my printer.cfg :

[homing_override]
gcode:
G90 # use relative movement
G0 X10 F3000 # moves X axis 10mm just as a test
G91 # use absolute movement
G28 # start normal homing routine

When I hit the homing buttons, the following error appears:

Must home axis first: 20.000 0.000 0.000 [0.000]
Must home axis first: 20.000 0.000 0.000 [0.000]
G28

(nothing moves btw…)

That’s the whole point, this routine is to be a replacement for homing?
Isn’t there a way to turn of this annoying ‘Homing first’ check?

5

Did you check the respective reference:
https://www.klipper3d.org/Config_Reference.html?h=homing_o#homing_override
There are numerous examples available when searching for it.

6

Yes, I’ve checked the reference.
I also found some examples that f.e. first turn off the motors and then start a normal G28 procedure, but I did not found any that involve G0 movements prior doing a G28.
These moves still seem to trigger the “Must home axis first” error…

7

If you want to move an axis before it is homed you need to use set_position_? to set this particular axis to 0 for example.
Then you can perform a G0 on this axis and later home it properly.
However as the axis is undefined and you just set a position you should prevent excessive moves as the set position is most likely not the real position.
You can also define for what axes the override should be applied.

8

Thanks, I did not try the "set_position_’ option because absolute positioning is relevant at this point. But if you say it’s mandatory to be able to move the toolhead, I’ll definitively give this a try !

9

Depending on what you want to achieve there are numerous approaches.

  • One surely is set_position_? as mentioned by @LifeOfBrian but then again this is a low level function that might lead to unwanted effects
  • Another approach is to home X and Y first, do your cleaning and then home Z
  • Or home all, do the cleaning and home again

This all depends on your requirements and how you use your printer.

10

I think I’ve something that works for me:
The end gcode script in my slicer moves the head to position -28, 153 which is above the purge bucket
So when homing starts, it is assumed that that’s the current position (which normally is the case)

[homing_override]
axes: xyz
set_position_x: -28
set_position_y: 153
set_position_z: 0
gcode:
G0 X0 F3000 # cleaning move
G0 X-28 F3000 # cleaning move
G28 X # home X
G28 Y # home Y
G0 Z5 F500 # raise Z 5mm
G0 X140 Y110 F7000 # to mid of bed
G28 Z # home Z
G0 Z10 F500 # raise Z 10mm

(of course the cleaning moves are more elaborate in reality as shown here)

Thanks for the help! :sunglasses::+1:

11

Not completely happy yet…
Turns out that f.e. manually typing the “G28 X” command means that the whole homing_override routine is executed. ( I thought it was just an override for the homing button…)
So IF the nozzle is somehow not above the purge bucket, there is no way to safely home?
I thought of a clean_and_home macro, but then I can’t move the head before homing again and I’m back to square one… OMG…

Can’t believe why Klipper doed not have a simple NO_MOTION_BEFORE_HOMING setting like Marlin has… :confounded:

Guess I could alter my printer and place the purge bucket and cleaning brush in a position where the nozzle touches the brush while homing Y after having homed X. A big ooze will drop then I guess…
This needs a pretty big redesign of my printer however… sigh…

12

Maybe you did not yet dig deep enough into the homeing_override code. :smiley:
You can react on each axis if needed:

gcode:
  {% set home_all = 'X' not in params and 'Y' not in params and 'Z' not in params %}

  {% if home_all or 'X' in params %}
    _HOME_X
  {% endif %}
  
  {% if home_all or 'Y' in params %}
    _HOME_Y
  {% endif %}
  
  {% if home_all or 'Z' in params %}
    M117 Homing Z...
    bla blubb

And with querying other print head object parameters you can rebuild other known functions.

Can’t you just home the needed axes and then clean the nozzle?

13

Oh wow, thanks!
Have to spend a little more time with this I understand now, but looks promissing :+1:

Can’t you just home the needed axes and then clean the nozzle?

As the nozzle normally is already above the purge bucket, I want to clean the nozzle right there using the wire brush, so the ooze falls into the bucket. (this can also be solidified ooze from a last print a day before)
If the head does any movements, the ooze can fall off at any point when homing X and Y. As the bucket is on the left side of the bed it’ll probable won’t fall onto the bed, but it’s still not an elegant option…

14

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.