Endstop Issues on my Ender 5 Plus - Smashing Rails on X (sometimes)

General Discussion
1

Basic Information:

Printer Model: Ender 5 Plus
MCU / Printerboard: SKR PRO 1.2
Host / SBC Raspberry Pi 3b
klippy.log

Fill out above information and in all cases attach your klippy.log file (use zip to compress it, if too big). Pasting your printer.cfg is not needed
Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there

Describe your issue:

Hey there,
I run in problems while homing my x axle on my ender 5 plus.

I use mechanical endstops, the sensorless homing of the tmc2209 are disabled (by bend pin).
All endstops trigger fine, query the state of each shows the expected values.

While homing x the endstops will be ignored, and mashes against the rail.
This behaviour / problem occures not within each homing sequence, mostly when homing after a print or some other movements happends before.

What i tried so far:

  • I replaced the endstop - same problem
  • when using homing sequence with two hits (homing_retract_dist > 0) first hit works (mostly) correct, while the second smashes in the rails.
  • now running with homing_retract_dist = 0 does not solve the problem.
  • Homing Y before X helps (sometimes).

I recently migrated from marlin, where printer and endstops works.
Klipper is realy great and i hope i can fix this issue.

Do you have any ideas?
Best regards Matthias

In my Logfiles attached you find the smashing rails on (Stats 4991.6)

[1]
Stats 4991.6: gcodein=0 mcu: mcu_awake=0.003 mcu_task_avg=0.000007 mcu_task_stddev=0.000004 bytes_write=42749 bytes_read=67714 bytes_retransmit=30 bytes_invalid=0 send_seq=2528 receive_seq=2526 retransmit_seq=2528 srtt=0.001 rttvar=0.001 rto=0.100 ready_bytes=0 upcoming_bytes=76 freq=168002262 heater_bed: target=0 temp=50.8 pwm=0.000 sysload=0.49 cputime=267.215 memavail=570816 print_time=4955.604 buffer_time=0.000 print_stall=0 extruder: target=0 temp=83.2 pwm=0.000
Unable to obtain tmc stepper_x phase

logs-20250417-160220.zip (416.5 KB)

…

2

Would be helpful to see your stepper x config as well as the driver config for x

Also are you using SET_GCODE_OFFSET anywhere ?

3

Hey @jsmith ,
Thanks for the quick reply! See my driver/stepper configuration below.

I did not found any usage of SET_GCODE_OFFSET.
This would be part of a macro, right?
Can I query the current GCODE_OFFSET?

Might this also be part of a gcode (als cura prefix o.e.)? what would be the coresponding G-Codes?

Thanks a lot!
Best regards Matthias

[stepper_x]
step_pin: PE9
dir_pin: PF1
enable_pin: !PF2
microsteps: 128
rotation_distance: 40
endstop_pin: PB10
# https://klipper.discourse.group/t/understanding-x-and-y-axes-limits-and-homing/10779
position_endstop: 350
position_max: 350
homing_speed: 50
#https://www.klipper3d.org/Config_Reference.html#stepper
homing_retract_dist: 0

...

[tmc2209 stepper_x]
uart_pin: PC13
run_current: 0.800
hold_current: 0.500
stealthchop_threshold: 999999
4

Your endstop is on the right side assume ? If you didn’t set a gcode_offset then there isn’t one.

Try this for homing:

homing_speed: 50
homing_retract_dist: 5
homing_retract_speed: 25
second_homing_speed: 5

Edit: You can safely comment out hold_current.

Edit 2: If limit switch is on the right I would expect to see “homing_positive_dir: true” If it’s on the left side you need minimum which would be a negative number, Klipper may draw that conclusion from the max value though. I have an Idex so 2 on x Axis so I use it.

Edit 3 lol: You may need a pullup on the endstop pin IE: “endstop_pin: ^PB10”. My money is on this one because if pin floats high/low you can weird results.

1 Like
5

Jepp, the endstop is on the right side …

I tried the config, but same issue. After (pre)heating nozzle and bed the homing failed.
This time the first hit was also ignored.

Stripped Log-File attached …

klippy.log (73.7 KB)

6

Edit, nm just noticed the board your using, the Klipper generic config don’t use pullups for that board. You can skip starting a print or pre-heating to trouble shoot, just issue a G28 in console to home.

At this point I would double check the wiring is solid for that endstop. I run a BTT Octopus and use pullups so the pin state can’t float. That’s with 2 wire end stops. If you have 3 wire you probably don’t need them.

With motors off (M84) move X axis to depress endstop and issue QUERY_ENDSTOPS in console. It will show the state of the endstops.:
x:TRIGGERED y:open z:open

7

The LOL on Edit2 was the hint! :slight_smile:
With the pullup on the endstops it’s working fine now!

Thanks for the great and super fast support @jsmith !
Awesome!

Thanks a lot!

8

You’re welcome

1 Like