<p>In my case: in section homing I've uncomented</p>
<pre><code>#define USE_XMAX_PLUG
</code></pre>
<p>Apparently, when using sensorless homing, it is undesire.</p>

CC BY-SA 4.0
2022-07-08T04:27:42.510Z
2022-07-09T15:36:48.180Z
2022-07-09T15:36:48.180Z
eryklopata
<p>I've got a heavily modified CR-10s Pro, and I'm compiling my firmware. I have my own x-carriage with the probe changed to the right of the nozzle. The bed size is 300x300. Oddly, when I do a G28 the printer homes to (177, 0). I can't understand where it's getting the number 177 from.</p>
<p>In Configuration.h I have:</p>
<pre><code>// The size of the print bed
#define X_BED_SIZE 300
#define Y_BED_SIZE 300

// Travel limits (mm) after homing, corresponding to endstop positions.
#define X_MIN_POS 0
#define Y_MIN_POS 0
#define Z_MIN_POS 0
#define X_MAX_POS 310
#define Y_MAX_POS 315
#define Z_MAX_POS 395
</code></pre>
<p>And</p>
<pre><code>#define Z_SAFE_HOMING

#if ENABLED(Z_SAFE_HOMING)   
    #define Z_SAFE_HOMING_X_POINT X_CENTER  // X point for Z homing   
    #define Z_SAFE_HOMING_Y_POINT Y_CENTER  // Y point for Z homing
#endif
</code></pre>

CC BY-SA 4.0
2021-04-28T21:40:08.627Z
In order to solve where the 177 is coming from you might need to mention the offset of the sensor to the nozzle. I've got a feeling that it can be explained by that. Also, are you sure The print head can reach beyond both the bed sizes? What are the offsets from endstops to the origin?
0scar
CC BY-SA 4.0
2021-04-29T11:52:47.277Z
What happens with `G28 X0 Y0`?
Davo
CC BY-SA 4.0
2021-04-29T21:16:18.493Z
@Davo [Please note](https://reprap.org/wiki/G-code#G28:_Move_to_Origin_.28Home.29): `The X, Y, and Z parameters act only as flags. Any coordinates given are ignored. For example, G28 Z10 results in the same behavior as G28 Z`. But that is indeed an interesting comment, this will test endstop positions, movement to the "middle of the plate" would be caused by `G28 Z` if safe homing is enabled in firmware (the question suggests it is). So all that is needed to home X and Y is to use `G28 X Y`, digits are ignored.
0scar
CC BY-SA 4.0
2021-04-30T13:07:07.123Z
@0scar That's interesting. On my machines, `G28` does nothing; `G28 X0` homes only the X; `G28 Y0` homes only the Y, and `G28 X0 Y0` homes both X and Y.
Davo
CC BY-SA 4.0
2022-07-13T12:32:16.543Z
@Davo You use a strange firmware flavor :-), `G28` should be [natively supported by any firmware](https://reprap.org/wiki/G-code#G28:_Move_to_Origin_.28Home.29), the flags are optional, digits are ignored.
0scar
CC BY-SA 4.0
2022-07-13T12:35:03.097Z
What is more striking is the value of the Y-axis being zero (in [177, 0]), that should be a value close to the bed center (as in about 150).
0scar
CC BY-SA 4.0
2022-07-14T15:02:43.970Z
@0scar we make our own boards, firmware, software, and hardware in-house. But we run most marlin/repetier-type gcode with minimal changes (like how we set temperatures without changing "focus" - we can change temps on T4 while printing with T0).
Davo
<marlin><firmware>
G28 is not homing to center of bed
Kurt Newman
# G28 is not homing to center of bed

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

I've got a heavily modified CR-10s Pro, and I'm compiling my firmware. I have my own x-carriage with the probe changed to the right of the nozzle. The bed size is 300x300. Oddly, when I do a G28 the printer homes to (177, 0). I can't understand where it's getting the number 177 from.

In Configuration.h I have:

```
// The size of the print bed
#define X_BED_SIZE 300
#define Y_BED_SIZE 300

// Travel limits (mm) after homing, corresponding to endstop positions.
#define X_MIN_POS 0
#define Y_MIN_POS 0
#define Z_MIN_POS 0
#define X_MAX_POS 310
#define Y_MAX_POS 315
#define Z_MAX_POS 395

```

And

```
#define Z_SAFE_HOMING

#if ENABLED(Z_SAFE_HOMING)   
    #define Z_SAFE_HOMING_X_POINT X_CENTER  // X point for Z homing   
    #define Z_SAFE_HOMING_Y_POINT Y_CENTER  // Y point for Z homing
#endif

```

**Tags:** marlin, firmware

> **Comments:**
> **username_1**: In order to solve where the 177 is coming from you might need to mention the offset of the sensor to the nozzle. I've got a feeling that it can be explained by that. Also, are you sure The print head can reach beyond both the bed sizes? What are the offsets from endstops to the origin?  
> **username_2**: What happens with `G28 X0 Y0`?  
> **username_1**: @username_2 [Please note](https://reprap.org/wiki/G-code#G28:_Move_to_Origin_.28Home.29): `The X, Y, and Z parameters act only as flags. Any coordinates given are ignored. For example, G28 Z10 results in the same behavior as G28 Z`. But that is indeed an interesting comment, this will test endstop positions, movement to the "middle of the plate" would be caused by `G28 Z` if safe homing is enabled in firmware (the question suggests it is). So all that is needed to home X and Y is to use `G28 X Y`, digits are ignored.  
> **username_2**: @username_1 That's interesting. On my machines, `G28` does nothing; `G28 X0` homes only the X; `G28 Y0` homes only the Y, and `G28 X0 Y0` homes both X and Y.  
> **username_1**: @username_2 You use a strange firmware flavor :-), `G28` should be [natively supported by any firmware](https://reprap.org/wiki/G-code#G28:_Move_to_Origin_.28Home.29), the flags are optional, digits are ignored.  
> **username_1**: What is more striking is the value of the Y-axis being zero (in [177, 0]), that should be a value close to the bed center (as in about 150).  
> **username_2**: @username_1 we make our own boards, firmware, software, and hardware in-house. But we run most marlin/repetier-type gcode with minimal changes (like how we set temperatures without changing "focus" - we can change temps on T4 while printing with T0).  

---

## 1 answers

### Answer by username_3 on 2022-07-08. Score: 1

In my case: in section homing I've uncomented

```
#define USE_XMAX_PLUG

```

Apparently, when using sensorless homing, it is undesire.


---

