Homing not working as expected (does not stop)

karl_ranseier

Using Rumba32 and repetier dev2 I have the following Problem:

I move somewhere in the center of my bed. Using M119 I get something like

endstops hit: x_min:L y_max:L z_max:H

Which ist correct, because z is at maximum and hits the end stop.

When I move by hand to the x-axis min hard stop I get

endstops hit: x_min:H y_max:L z_max:H

makes sense.

When I press homing while position is somewhere in the center, it moves correctly towards x-axis min, but it does not stop. I cannot read the endstop value by M119, because during homing the communication seems to be blocked (makes sense).

I press either reset or wait till it stops the homing without result. Using M119 I get the result

endstops hit: x_min:H y_max:L z_max:H

For noise supression I added some capacitors parallel to the switch.

Am I doing something wrong? The endstops for x, y and z are the same type. So I do not understand, why this homing does not work.

Every movement is done using repetier server.

My main configuration of the endtsops is the following:

configuration.h

// ################ Endstop configuration #####################

#define DOOR_PIN -1

#define DOOR_PULLUP 1

#define DOOR_INVERTING 1

#define ENDSTOP_X_BACK_MOVE 5

#define ENDSTOP_Y_BACK_MOVE 5

#define ENDSTOP_Z_BACK_MOVE 5

#define ENDSTOP_X_RETEST_REDUCTION_FACTOR 5

#define ENDSTOP_Y_RETEST_REDUCTION_FACTOR 5

#define ENDSTOP_Z_RETEST_REDUCTION_FACTOR 5

#define ENDSTOP_X_BACK_ON_HOME 0

#define ENDSTOP_Y_BACK_ON_HOME 0

#define ENDSTOP_Z_BACK_ON_HOME 0

#define ALWAYS_CHECK_ENDSTOPS 1

#define MOVE_X_WHEN_HOMED 0

#define MOVE_Y_WHEN_HOMED 0

#define MOVE_Z_WHEN_HOMED 0

configuration_io.h

// Define your endstops inputs

IO_INPUT_INVERTED_PULLUP(IOEndstopXMin, ORIG_X_MIN_PIN)

// IO_INPUT_INVERTED(IOEndstopXMin, ORIG_X_MIN_PIN)

IO_INPUT_INVERTED_PULLUP(IOEndstopYMax, ORIG_Y_MAX_PIN)

IO_INPUT_INVERTED_PULLUP(IOEndstopZMax, ORIG_Z_MAX_PIN)

ENDSTOP_SWITCH_HW(endstopXMin, IOEndstopXMin, X_AXIS, true)

ENDSTOP_NONE(endstopXMax)

ENDSTOP_NONE(endstopYMin)

ENDSTOP_SWITCH_HW(endstopYMax, IOEndstopYMax, Y_AXIS, true)

ENDSTOP_SWITCH_HW(endstopZMax, IOEndstopZMax, Z_AXIS, true)

ENDSTOP_NONE(endstopZMin)

RAyWB

referring https://docfirmwarev2.repetier.com/config/endstops</div><div><br/></div><div>ENDSTOP_SWITCH_HW(endstopXMin, IOEndstopXMin, X_AXIS, false)

should do the trick.

false = homing to min , true =homing to max

so as z is homing to max it´s working correct. if y is homing to min also change to false

karl_ranseier

Thanks, I read that manual, but obviously too fast. I did not expect the need of entering two times the direction:

Here:

<span>#define X_HOME_DIR -1<br/></span>
And here:

<span>ENDSTOP_SWITCH_HW(endstopXMin, IOEndstopXMin, X_AXIS, <b>false</b>)<br/><br/><br/></span>

It might make sense to translate "X_HOME_DIR" to false/true using some code, what I am yet not able to do.

Now it stops, moves back as expected, than looks again for the endstop. So far so good.
But than it tries to move to a position smaller than the endstop, hitting the end of my printer.

karl_ranseier

Looks like the endstop is defined as 0 mm.

If I set "x-axis distance after homing" to 0 it does not move.

"x-axis min position" is set to -65mm. Therefore I thought I need to set "x-axis distance after homing"to -65mm.

Where do I set the position of the endstop?

Repetier

Distance after homing is just to get away from the endstop so it is not triggered any more. It is independent of the position so think of it as a relative distance.

min/max positions are defined by this

#define X_MAX_LENGTH 420

#define Y_MAX_LENGTH 420

#define Z_MAX_LENGTH 595.596

#define X_MIN_POS -210

#define Y_MIN_POS -210

#define Z_MIN_POS 0

just put your value sthere.

karl_ranseier

Repetier said:

Distance after homing is just to get away from the endstop so it is not triggered any more. It is independent of the position so think of it as a relative distance.

Ok, handling it as a relative position change explains it. And you are right, a distance is alway relative... damn math/physics definitions. I like them, but sometimes I don't expect others to use them in the correct way. I apologize for this.