Hybrid Corexy seems to need inversion

General Discussion
1

Basic Information:

Printer Model: Custom
MCU / Printerboard: Manta M8p

klippy.log (1.6 MB)

So I have an issue getting the X axis to realize which way it’s supposed to go. Logic inversion would solve my issue in a heartbeat but I can’t find any reference anywhere in the vastness of the klipper tuts and discussions on how to do that. I can get the X and Y moving in the right directions and homing in the right directions, the X axis just seems to be inverted in it’s coordinates. Physical X0 Y0 is X450 Y0 and moving X into + decreases the X coordinate value. How do I tell Klipper to invert the coordinates of X. Maybe I button on the screen or a setting in the config somewhere that I am missing?

2

Fore left edge is defined as 0,0. So depending where your physical endstops are sitting or where you home sensorlessly you have to define the right coordinates respectively.
And depending on that you might want to change the following parameter under the X and Y stepper sections:

homing_positive_dir:

Read here for further information on the parameters:
https://www.klipper3d.org/Config_Reference.html#stepper

Also read this knowledge base article about coordinates and homing:

1 Like
3

For my design of CoreXY printers, I have one of the X/Y stepper motors pointing upwards and the other down.

For this to work properly, I have to invert the DIR pin on one of the X/Y steppers.

I don’t have a hard and fast rule on which axis, I just try one and if both movements are in the wrong direction then I invert the other.

4

As far as I’m aware, this kinematics is quite similar to the regular CoreXY kinematics but with the difference that stepper A is basically direct proportional to Y while stepper B follows the CoreXY rules of being proportional to X minus Y.

So likely the solution to this issue is a similar approach as described here: Initial Startup | Voron Documentation but limited to one stepper only

But again this is only an assumption as I have exactly zero experience with this kinematics.

6

Thanks Sineos you are correct, my issue however is the logic of the axis. I would like to be able to just have it count the other way, so what it though was going into the positive would now just be going into the negative. I am most probably just missing something super obvious to everyone else.

7

Usually Klipper determines this automatically. As mentioned by @LifeOfBrian this automatism can be overruled by setting homing_positive_dir but today no real case is known where this setting needs to be set.

  • If position_endstop setting is closer to position_min then homing_positive_dir is automatically false and homing occurs towards zero (your case)
  • If position_endstop setting is closer to position_max then homing_positive_dir is automatically true and homing occurs away from zero

So, in theory, it should work for your case if the homing indeed happens towards the relevant endstop pins AND your endstop switches are in the front-left corner.
position_max in your case is max allowable distance the axis can safely travel from its origin (0) point.

8

Please see here: klipper-OVO/klippy/kinematics/hybrid_corexy.py at master · Bablinski/klipper-OVO · GitHub

Do you think that will lead to me being able to tell the firmware to just think the other way around?

9

As I have no experience here, I cannot meaningful assist. Try it

10

will do. this is just to make up at least 10 characters

11

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