"Endstop y still triggered after retract" Error after power-up

General Discussion
1

Basic Information:

Printer Model: AnyCubic Kobra 2
MCU / Printerboard: Trigorilla Pro B V1.02
klippy.log (44.0 KB)

Everytime I start up my AnyCubic Kobra 2 and run a HomeAll (or Home Y) I get the
“Endstop y still triggered after retract”-error.
It is running directly into the endstop an then throwing the error.
There is no retraction and no 2nd homing.
If I run the homing command a 2nd time it runs as it should. If I move the bed manually into the endstop before calling the home command is is also working perfectly.
What is the reason for this?

2

Now you’ve got me rethinking my own homing, but before we get that far. You don’t have these options setup in your steppers for homing:

#homing_retract_dist: 5.0
#   Distance to backoff (in mm) before homing a second time during
#   homing. Set this to zero to disable the second home. The default
#   is 5mm.
#homing_retract_speed:
#   Speed to use on the retract move after homing in case this should
#   be different from the homing speed, which is the default for this
#   parameter
#second_homing_speed:
#   Velocity (in mm/s) of the stepper when performing the second home.
#   The default is homing_speed/2.
#homing_positive_dir:
#   If true, homing will cause the stepper to move in a positive
#   direction (away from zero); if false, home towards zero. It is
#   better to use the default than to specify this parameter. The
#   default is true if position_endstop is near position_max and false
#   if near position_min.

I don’t home in the negative direction like you do, but the code makes it seem like it only does the retract and 2nd home if there is a retract distance set. I don’t have one set and I could SWEAR mine does it too.

Mines in pieces right now but definitely going to see what’s up with that when I get it back together.

Edit: Nvm I’m blind it says it right there “The default is 5mm”

You most likely need to set “homing_positive_dir: false” for it to pick it up right.

Mine retracts 5mm in the negative direction to rehome, yours is probably retracting 5mm in the negative direction too and just pushing harder against the end stop.

Hence the error.

3

It is indeed a bit weird. I think I will change it to homing towards positive direction.
But why is it working perfectly after the Endstop still triggered error?

4

What do you mean? As in, it lets you do everything normally?
I thought homing wasn’t successful if it didn’t trigger the second homing pass, but again my printer has a few parts off so I can’t test myself to double check my assumption.

The second homing pass is just a double check to make sure it wasn’t a false trigger on the first. Could be it just runs with the first one, but I’ll have to validate that, the code makes it look like homing would fail.

5

Yes it does. It is the very first homing after power-up that fails.
I just checked. It has to home from the endstop triggered. If I move the bed manually away from the endstop it will throw the error again and again.
I also checked for the 2nd homing. Only z-axis shows a 2nd homing.
The x-axis nevertheless does not throw an endstop still triggered error

6

Add this to your X and Y steppers and set it to false:

#homing_positive_dir:
#   If true, homing will cause the stepper to move in a positive
#   direction (away from zero); if false, home towards zero. It is
#   better to use the default than to specify this parameter. The
#   default is true if position_endstop is near position_max and false
#   if near position_min.

By settings a position max and and endstop on a negative position it’s skewing Klippers expectation on where your toolhead should be.

If you set it as “False” it uses the position min and not position max, which is what you want since your endstop is near position min.

Edit:

Also, Your Z homing is setting right on top of the X endstop.
You should really move it a bit away from that unless you HAVE to have it there.

[safe_z_home]
home_xy_position = -4, 210
speed = 100
z_hop = 10
z_hop_speed = 100
move_to_previous = False
7

I set

homing_positive_dir: false

for both x and y axis but the problem remains.

edit: no wonder

#homing_positive_dir:
#   The default is true if position_endstop is near position_max and false
#   if near position_min.

I have to correct myself. The 2nd homing happens but not if it’s at the endstop position.

8

I’m not sure what you mean by some of your points.

You said your homing direction is false, which it should be because your endstop is near your minimum position for x and y.

I’m confused by the “no wonder”.

The 2nd homing happens but not if it’s at the endstop position

The 2nd homing ONLY happens at the endstop position?
It homes once, retracts a bit from the endstop and moves to trigger it again.

If that’s not happening then something else is set wrong

9

Let’s say the value for homing direction is false. That corresponds to the default value and is in fact the correct value.

No wonder nothing has changed because the configuration has not changed.
I only set homing_positive_dir explicitely to its default value (which is FALSE)

I’ve meant to say that the second homing does not happen, when the endstop already has been triggered and I command homing. If it is not triggered, the second homing will occur.

The initial problem remains:
When the machine is powered up and the y-endstop is not triggered, the y-axis runs into it and throws the error “Endstop still triggered” once.
As the y-endstop is now triggered, a second homing command will be executed without any problem.

10

I believe I found a solution for my problem.
I’ve changed the homing speed for the y axis from 100 to 75 an it does not throw an error anymore.

2 Likes
11

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