<p>I have a Creality CR-10 with EZABL (bed leveling sensor). I'm not sure what prompted the printer to think the center is the origin.</p>
<p>The printer homes in the dead center of the bed to start the auto bed leveling process from there; it seems to think it's doing that at X=0, Y=0 (when the printer receives the command to auto-home and it's already positioned at the center of the bed, it interprets that position as X=0, Y=0.). I've got it set to probe the bed at 9 points, in a 3x3 grid, it starts in the center (as in: it doesn't move to the X and Y endstops), then moves to the right and grinds hard against the right side, then grinds hard against the back.  I'm not sure what to do, I've already tried recompiling and uploading and even resetting to firmware defaults with <code>M502</code>. How do I get my printer to home correctly?</p>
<p>Here's my start G-code:</p>
<pre><code>M75 ; Start Print Timer and Engage Fil Sensor if USB Printing
M84 E ; Disable E Motor for probe accuracy on direct drive systems
M117 Antiblob retract...
G92 E0 ; Reset Extruder distance to 0
G1 E-2 ; Retracts filament to prevent blobs during probing
G92 E0 ; Reset Extruder distance to 0
M117 Homing All...
G28 ; home all axes
M117 Homing Z Probe...
G28 Z ; home z again
M117 Generating mesh...
G29; auto bed leveling
M117 Heaters Recovering...
G4 S10; wait for heaters to recover
M420 Z0; Z fade
M900 K0; LA
</code></pre>

CC BY-SA 4.0
2021-04-18T05:42:36.790Z
Hi Jack, I've rearranged your question. Please note that the stated G-code is not relevant at all, you can leave it out (good you did because it has a lot of instructions on it that can be deleted). It is perfectly fine that the nozzle homes Z in the middle of the plate, this is how it is instructed to do in the firmware. The most relevant part is what your firmware settings are, so please link to the config file on PasteBin for example, other members will be able to use this for an answer and update your question.
0scar
CC BY-SA 4.0
2021-04-18T16:33:09.133Z
I did try to re-compile and upload that firmware and I tried a test print this morning.  The same thing happened, only this time, because the homing problem is so bad, the printer head assembly banged into one of my binder clips and snapped my EZABL mount. So now I'm really out of commission until I get this figured out. I was able to post my configuration on textuploader: http://txt.do/ts4zt
Jack Harris
CC BY-SA 4.0
2021-04-20T06:28:36.193Z
Have you checked the endstop status with `M119`? You need to connect a [console](/q/10573). If the endstops are thinking to be triggered, they won't allow movement in the direction of the endstop, only the other direction. If you move the carriage manually to another position, the printer probes from there? If the endstops are never hit, the printer does not know what coordinates it is at, presumably it assumes it is at 0,0 as the endstops are triggered.
0scar
CC BY-SA 4.0
2021-04-20T14:16:28.157Z
Okay, I sent a command to the printer from Cura to home X and Y.  It homed Y correctly, but X did not; the print head is positioned just a little right of the center of the bed.  I shut down Cura, opened Arduino, and sent M119, and it shows both x_min: TRIGGERED and y_min: TRIGGERED.  This is correct for Y, but not for X.

I then used the printer's console to auto-home.  It functioned correctly, ending up in the middle of the bed as it should, and all axes endstops are showing "open".  Just to be sure, I repeated this process, and it worked correctly again.

Maybe the problem is with Cura?
Jack Harris
CC BY-SA 4.0
2021-04-20T18:08:05.867Z
I've been experimenting with Cura to see if it's the problem.  There seems to be no consistent reason why sometimes it homes properly and sometimes it doesn't.
Jack Harris
CC BY-SA 4.0
2021-04-20T18:16:41.887Z
Maybe you should change the cables of the endstops for new ones.
0scar
CC BY-SA 4.0
2021-04-20T18:32:07.813Z
Well, I thought of that, but I don't see how that can be the problem.  When the errors occur, the assembly isn't even reaching the endstops. I just downloaded a newer version of the firmware. I'm compiling it and uploading it now. Maybe this problem will clear up.
Jack Harris
CC BY-SA 4.0
2021-04-21T20:20:51.283Z
I give up.  I've been working on this for three days, and I can't figure it out.
Jack Harris
CC BY-SA 4.0
2021-04-21T20:52:50.373Z
Shorting or failing of the cables (depends on the firmware configuration of the endstops) would show similar symptoms. I'm still curious of the endstop states when it doesn't move to the endstops on homing.
0scar
CC BY-SA 4.0
2021-04-21T21:23:13.407Z
I just had a print fail because of this nonsense in Cura.  I tried sending G1 X0 Y0, which returned to Y0 correctly, but remained in the middle of the bed on the X-axis.  I shut down Cura, started up Arduino IDE, sent M119, and x_min is TRIGGERED.  I sent G28 and it homed properly to X0 Y0, and x_min still shows TRIGGERED.  I've tried moving the X-axis to various positions, and x_min always shows TRIGGERED.
Jack Harris
<creality-cr-10><homing><ezabl><th3d>
How can I get my printer to home correctly?
Jack Harris
# How can I get my printer to home correctly?

(Asked by: username_0 on 2021-04-18)

I have a Creality CR-10 with EZABL (bed leveling sensor). I'm not sure what prompted the printer to think the center is the origin.
The printer homes in the dead center of the bed to start the auto bed leveling process from there; it seems to think it's doing that at X=0, Y=0 (when the printer receives the command to auto-home and it's already positioned at the center of the bed, it interprets that position as X=0, Y=0.). I've got it set to probe the bed at 9 points, in a 3x3 grid, it starts in the center (as in: it doesn't move to the X and Y endstops), then moves to the right and grinds hard against the right side, then grinds hard against the back.  I'm not sure what to do, I've already tried recompiling and uploading and even resetting to firmware defaults with M502. How do I get my printer to home correctly?
Here's my start G-code:
M75 ; Start Print Timer and Engage Fil Sensor if USB Printing
M84 E ; Disable E Motor for probe accuracy on direct drive systems
M117 Antiblob retract...
G92 E0 ; Reset Extruder distance to 0
G1 E-2 ; Retracts filament to prevent blobs during probing
G92 E0 ; Reset Extruder distance to 0
M117 Homing All...
G28 ; home all axes
M117 Homing Z Probe...
G28 Z ; home z again
M117 Generating mesh...
G29; auto bed leveling
M117 Heaters Recovering...
G4 S10; wait for heaters to recover
M420 Z0; Z fade
M900 K0; LA

**Tags:** creality-cr-10, homing, ezabl, th3d
> **Comments:**
> **username_1**: Hi Jack, I've rearranged your question. Please note that the stated G-code is not relevant at all, you can leave it out (good you did because it has a lot of instructions on it that can be deleted). It is perfectly fine that the nozzle homes Z in the middle of the plate, this is how it is instructed to do in the firmware. The most relevant part is what your firmware settings are, so please link to the config file on PasteBin for example, other members will be able to use this for an answer and update your question.  
> **username_0**: I did try to re-compile and upload that firmware and I tried a test print this morning.  The same thing happened, only this time, because the homing problem is so bad, the printer head assembly banged into one of my binder clips and snapped my EZABL mount. So now I'm really out of commission until I get this figured out. I was able to post my configuration on textuploader: http://txt.do/ts4zt  
> **username_1**: Have you checked the endstop status with `M119`? You need to connect a [console](/q/10573). If the endstops are thinking to be triggered, they won't allow movement in the direction of the endstop, only the other direction. If you move the carriage manually to another position, the printer probes from there? If the endstops are never hit, the printer does not know what coordinates it is at, presumably it assumes it is at 0,0 as the endstops are triggered.  
> **username_0**: Okay, I sent a command to the printer from Cura to home X and Y.  It homed Y correctly, but X did not; the print head is positioned just a little right of the center of the bed.  I shut down Cura, opened Arduino, and sent M119, and it shows both x_min: TRIGGERED and y_min: TRIGGERED.  This is correct for Y, but not for X.  I then used the printer's console to auto-home.  It functioned correctly, ending up in the middle of the bed as it should, and all axes endstops are showing "open".  Just to be sure, I repeated this process, and it worked correctly again.  Maybe the problem is with Cura?  
> **username_0**: I've been experimenting with Cura to see if it's the problem.  There seems to be no consistent reason why sometimes it homes properly and sometimes it doesn't.  
> **username_1**: Maybe you should change the cables of the endstops for new ones.  
> **username_0**: Well, I thought of that, but I don't see how that can be the problem.  When the errors occur, the assembly isn't even reaching the endstops. I just downloaded a newer version of the firmware. I'm compiling it and uploading it now. Maybe this problem will clear up.  
> **username_0**: I give up.  I've been working on this for three days, and I can't figure it out.  
> **username_1**: Shorting or failing of the cables (depends on the firmware configuration of the endstops) would show similar symptoms. I'm still curious of the endstop states when it doesn't move to the endstops on homing.  
> **username_0**: I just had a print fail because of this nonsense in Cura.  I tried sending G1 X0 Y0, which returned to Y0 correctly, but remained in the middle of the bed on the X-axis.  I shut down Cura, started up Arduino IDE, sent M119, and x_min is TRIGGERED.  I sent G28 and it homed properly to X0 Y0, and x_min still shows TRIGGERED.  I've tried moving the X-axis to various positions, and x_min always shows TRIGGERED.  

---

## 0 answers

