Config help KlipperK1

General Discussion
1

Basic Information:
Printer Model: Creality K1
MCU / Printerboard: BTT M5P, CB1 & EBB42
Mainsail / Klipper

Hi!

I am new to this level off mods but I wanted to give it a try.
I have a CR K1 that I fitted a BigTreeTech M5P mainboard, CB1 controller and a EBB42 canbus toolhead PCB and I also bought a cartographer.
The stepper drivers are TMC2009.

Stepper motors, extruder etc. is all stock.

I have come that far that I setup sensorless homing, the steppers are moving the right way and so on.

Even though I have setup sensorless homing the toolhead is dragging and pushing against the frame when I try to home, but only then.
I have set the homing position to X110Y110 but it homes to the front left corner as a stock K1 do and I have no problem with that except the rubbing and pushing.

Apparently it doesn’t know “where it is” because when it rubs I can see the coordinates changing as if it thinks it is moving.

Tried to follow a guide to calibrate the gantry to get the X0Y0 to be the front left but I only ended up getting the same results.

Can someone please help me get the printer setup so I can use it again?
As you probably can tell my knowledge in modding printers isn’t very impressive, haha.

moonraker.log (132.0 KB)
klippy.log (3.7 MB)

3

On a cursory look, your config seems quite good.
Make sure to have set the jumpers on the board correctly to allow sensorless homing. Generally, the homing direction is driven by the position_min / position_max settings and the endstop position settings. More on this here: Understanding X and Y Axes Limits and Homing

A final central position after homing X/Y is typically set with either homing_override or safe_z_home.

2 Likes
4

Hi!

Ok, good to know I didn’t mess it up totally haha.

That was a good explanation, thanks for the link!

It homes in the front left corner and according to the printer config that is the maximum point of the bed.

When I home it the coordinates on the “main screen” shows X:110 Y:110 :thinking:
Shouldn’t it be X:220 Y:220?

5

I’m not sure if I fully understand your current concerns.

Generally, your configuration:

[stepper_x]
...
position_endstop = 226.5
position_min = -2.5
position_max = 226.5

[stepper_y]
...
position_endstop = -0.5
position_min = -0.5
position_max = 204

[stepper_x]:

  • This tells Klipper that the endstop is at the maximum position 226.5.
  • After hitting the x-gantry, Klipper knows that its current position is 226.5.
  • From this, Klipper knows that x=0 is -226.5mm away.

[stepper_y]:

  • This tells Klipper that the endstop is at the minimum position -0.5.
  • After hitting the y-gantry, Klipper knows that its current position is -0.5.
  • From this, Klipper knows that y=0 is +0.5mm away.

Now you have defined your X/Y origins (0/0), and all further coordinates relate to this definition.

6

Yeah, I know.

But the coordinates Mainsail gives me when I home is X:110 Y:110.

When I home it stops nice and easy at the front left, I can then place it at the center (using the UI controls) and do another homing and then the toolhead rubs against the gantry until I stop it or it jumps enough to think it reached the right coordinates :grimacing:

Sorry if my English is confusing, I try to explain as good as I can.

If I try to make a cartographer run to get a mesh it slams and rubs against the gantry like crazy, so clearly there is something I do wrong :disappointed_face:

7

I have an idea about what might be going wrong on your side. Your configuration does not actually use or call the sensorless homing macros, and that’s why it starts to act up.

Take a look at the macro posted here: G28 delay on retract - #8 by Sineos and how it defines the homing scenarios using _HOME_X / _HOME_Y in homing_override. Also, follow the discussion to the end to get a better understanding of what is happening.

1 Like
8

So, long time no see!

I have tried the code in the link but I am afraid it didn’t help me or I maybe did it the wrong way :sad_but_relieved_face:
I’ll put a little Klippy in for you to
klippy (1).log (2.0 MB)
read.

9

Looks like a

[force_move]
enable_force_move: True

is missing in your config

	{% if home_all or 'Z' in params %}
	SET_KINEMATIC_POSITION Z=15
	G1 Z4 F1200

While it seems you were lucky that this force move was missing, since the above sounds very dangerous. You should reconsider it!

[gcode_macro _HOME_Y]
gcode = 
	...
	
	G1 Y-15 F1200

If you home towards Y=0 then you cannot go another 15 mm into the negative direction.

Verbatim copying of some example configurations that are posted to demonstrate a certain approach can have really ugly consequences.

1 Like
10

Okay!

Yeah, I really dont know what I am doing if I must be completely honest. :confused:

11

Hello again!

I am still trying to understand and learn, so here I am.
I got this files sent to me from another guy that is using the same printer as me without any problems, but they are made for my setup so to speak.

When I “home all” it goes to the front left corner as it should, but it rubs a little before it’s “home”.
The coordinates I get from it is:
mcu: stepper_x:-60 stepper_y:-19180 stepper_z:-766
stepper: stepper_x:227.500000 stepper_y:1.500000 stepper_z:9.999908
kinematic: X:114.500000 Y:113.000000 Z:9.999908
toolhead: X:114.500000 Y:113.000000 Z:10.000000 E:0.000000

I read your post about kinetic limitations/boundaries but couldn’t get a hang of it.
Do you understand my problem with the printer?
Any inputs in wich direction I should go to make it work? :confused:

printer.cfg.cfg (3.3 KB)
sensorless.cfg (5.5 KB)
scanner.cfg (704 Bytes)

12

Well, I tried to do a height map calibration now after a succesfull home all.
It starting to go towards the back left corner but rubbing against the wall as it did, before it stopped and gave me “Move out of range: 258.665 6.000 2.000 [0.000]” but the toolheads coordinates was “X:53.665000 Y:6.000000 Z:2.000000”.
How can it be two different values of the same part of the printer?!

I uploaded a Klippy

klippy.log (5.9 MB)

13

I’m not familiar with this printer, but it somehow doesn’t fit.

[stepper_x]
...
position_endstop = 229
position_min = -5
...

Here, you tell Klipper that when it hits the endstop, it has reached the X-value of 229 and that it can move 234 mm until it reaches its kinematic limit. Additionally, Klipper now knows that its X=0 is -229 mm away.

[stepper_y]
...
position_endstop = -0.5
position_min = -0.5
position_max = 226
...

For Y, you tell Klipper that upon hitting the endstop, it is at Y=-0.5 and that it needs to travel +0.5 to reach Y=0. From there, it can travel further 226 mm.

Overall, this means that after hitting the “front left corner”, Klipper assumes it is at 229/-0.5.

Given a regular Cartesian coordinate system, where the origin (0/0) is in the lower left corner, your origin (0/0) would be in the lower right corner.

I’m not sure what this means. What is rubbing where?

[scanner]
x_offset = -18.665
y_offset = 0

Given your coordinate system, you now tell Klipper that the probe “scanner” is offset 18,665 mm to the RIGHT in X-direction.

[bed_mesh]
..
mesh_min = 35, 6
mesh_max = 240, 198

The bed mesh uses the probe coordinates for min and max. This means you need to correct the nozzle coordinates with the offsets from above.
Given your coordinate system and the offsets, your nozzle will end up at X=258,665 when the probe tries to reach X=240. This leads to the error:

Move out of range: 258.665 6.000 2.000 [0.000]

Unfortunately, I cannot offer any more insight without knowing the intention behind it.

14

It’s just a CoreXY I guess.

When it was stock electronics it homed to the front left corner (looking at it from behind).
I dont really care WHERE it homes, as long as I get it to home and prints as it should, haha.

I’ll try to make something out of all this and come back to you later.

15

This :grimacing:

16

I managed to get a mesh done, but it’s rubbing against the frame on the X axis even though I have edited the values.
I’ll post a Klippy as well.
klippy (1).log (5.4 MB)

Skärmbild 2025-06-15 103808
Skärmbild 2025-06-15 1038081919×956 160 KB

17

I see a problem in the Klippy myself, I forgot to change this one so I guess that is why it’s hitting/rubbing the frame.

Screenshot_20250615_105906_Chrome
Screenshot_20250615_105906_Chrome1920Ă—781 56 KB

18

mykepredko

I saw you had som pointers when it comes to sensorless homing on a CoreXY and therefore tagged you.
Do you think you maybe could shine a light, cause I can’t figure this out really :confused:

19

You can tag by using “@”

@mykepredko See above post.

20

Thanks :see_no_evil_monkey: Didn’t think that far :rofl:

21

Can I ask exactly what are is problem and how it regards sensorless homing? When I look through the thread, I’m not exactly sure what the issue is as you report it’s okay and then when things start moving, the toolhead is rubbing against other parts.

Could you post a video of what’s happening?