<p>Similar to, but different from, <a href="https://3dprinting.stackexchange.com/questions/3383/marlin-end-stops-and-position-report-possible-bug">Marlin, end stops, and position report - possible bug?</a></p>

<p>This is roughly the same question, but I'm trying to understand the endstops hit response from Marlin.</p>

<p>I'm working on a prototype machine that has min and max endstops on X, Y.</p>

<p>How can I get the real position after hitting the <em>max</em> endstops? The reported position is either what I <em>told</em> the machine to move to, or if SW endstops are enabled, whatever the config value for max X, Y are.</p>

<p>When the endstops hit message comes in it provides a number after the X or Y but I can't figure out how it's related to anything in the FW config or the physical printer.</p>

<p>E.g.: </p>

<ul>
<li>Bed/max sizes (X, Y) set to 500</li>
<li>Endstops enabled</li>
<li>Move w/ <code>G0 Y250</code></li>
<li>Ymax endstop triggered ~161</li>
<li>Receive <code>echo:endstops hit:  Y:0.00</code></li>
<li><code>M114</code> returns <code>X:0.00 Y:250.00 Z:0.00 E:0.00 Count A:25147 B:25147 Z:0</code></li>
</ul>

<p>So the counts are (likely) correct (CoreYX machine), they're zero after homing to minimum position, but using them to determine the physical position seems sketchy.</p>

<p>Now: If I continue...</p>

<ul>
<li>Move w/ <code>G0 X250</code></li>
<li>Receive <code>echo:endstops hit:  X:157.31</code></li>
</ul>

<p>Then</p>

<ul>
<li><code>G0 Y250</code></li>
<li>Receive <code>echo:endstops hit:  Y:-265.55</code></li>
</ul>

<p>Here's the thing: those values are roughly what I expect the X, Y max values to be, except (a) they're reversed, e.g., IRL the ~Y at Ymax endstop is around 161, and Xmax endstop is around 265.</p>

<p>Is Marlin:</p>

<ul>
<li>Flipping the X/Y values somehow (and inverting X, probably because I'm doing something weird to try to track this down)?</li>
<li>Should I instead do some CoreYX math to attempt to get the physical position based on stepper counts?</li>
</ul>

<p>What is happening here?</p>

CC BY-SA 4.0
2019-06-27T13:12:24.863Z
Quick question, which version of Marlin are you running on your CoreXY? Old marlin or the new 2.0 branch?
Nach0z
CC BY-SA 4.0
2019-06-27T15:05:42.850Z
@Nach0z Old; currently on 1.1.8 with an update to 1.1.9 coming quickly. We realized that the endstop response might not be doing the CoreYX math right but haven't had a chance to dig into it yet, but that could well explain it. We just don't want to dupe the Marlin math off the motor counts if we can avoid it.
Dave Newton
CC BY-SA 4.0
2019-06-28T07:35:53.067Z
@DaveNewton Last time I checked, 1.1.9 had some issues with CoreXY (too?). Just go with Marlin 2.0
towe
CC BY-SA 4.0
2019-06-28T19:10:34.710Z
@towe Thanks; alpha firmware isn't in the cards for now ;)
Dave Newton
CC BY-SA 4.0
2019-07-01T08:23:25.993Z
@towe 1.1.9 works fine for my CoreXY, what issues do you mean? Maybe that helps the OP.
0scar
CC BY-SA 4.0
2019-07-01T08:40:16.097Z
@0scar I was referring to this Github issue: https://github.com/MarlinFirmware/Marlin/issues/11487
I've been using 2.0 since it came out (before moving to Klipper).
towe
CC BY-SA 4.0
2019-07-01T10:18:24.750Z
@towe I'd hardly call an unconfirmed issue a problem, this was probably some user induced fault, no other users with CoreXY printers have this problem (also this issue is closed by the developer).
0scar
CC BY-SA 4.0
2019-07-01T13:05:47.587Z
@0scar Check out the code that reports the endstop hit message in 1.1.8 (haven't check 1.1.9 yet).
Dave Newton
<marlin><endstop>
Marlin endstop hit message deciphering/real position
Dave Newton
# Marlin endstop hit message deciphering/real position

(Asked by: username_0 on 2019-06-21)

Similar to, but different from, [Marlin, end stops, and position report - possible bug?](https://3dprinting.stackexchange.com/questions/3383/marlin-end-stops-and-position-report-possible-bug)

This is roughly the same question, but I'm trying to understand the endstops hit response from Marlin.

I'm working on a prototype machine that has min and max endstops on X, Y.

How can I get the real position after hitting the *max* endstops? The reported position is either what I *told* the machine to move to, or if SW endstops are enabled, whatever the config value for max X, Y are.

When the endstops hit message comes in it provides a number after the X or Y but I can't figure out how it's related to anything in the FW config or the physical printer.

E.g.:

* Bed/max sizes (X, Y) set to 500
* Endstops enabled
* Move w/ `G0 Y250`
* Ymax endstop triggered ~161
* Receive `echo:endstops hit: Y:0.00`
* `M114` returns `X:0.00 Y:250.00 Z:0.00 E:0.00 Count A:25147 B:25147 Z:0`

So the counts are (likely) correct (CoreYX machine), they're zero after homing to minimum position, but using them to determine the physical position seems sketchy.

Now: If I continue...

* Move w/ `G0 X250`
* Receive `echo:endstops hit: X:157.31`

Then

* `G0 Y250`
* Receive `echo:endstops hit: Y:-265.55`

Here's the thing: those values are roughly what I expect the X, Y max values to be, except (a) they're reversed, e.g., IRL the ~Y at Ymax endstop is around 161, and Xmax endstop is around 265.

Is Marlin:

* Flipping the X/Y values somehow (and inverting X, probably because I'm doing something weird to try to track this down)?
* Should I instead do some CoreYX math to attempt to get the physical position based on stepper counts?

What is happening here?

**Tags:** marlin, endstop

> **Comments:**
> **username_1**: Quick question, which version of Marlin are you running on your CoreXY? Old marlin or the new 2.0 branch?  
> **username_0**: @username_1 Old; currently on 1.1.8 with an update to 1.1.9 coming quickly. We realized that the endstop response might not be doing the CoreYX math right but haven't had a chance to dig into it yet, but that could well explain it. We just don't want to dupe the Marlin math off the motor counts if we can avoid it.  
> **username_2**: @username_0 Last time I checked, 1.1.9 had some issues with CoreXY (too?). Just go with Marlin 2.0  
> **username_0**: @username_2 Thanks; alpha firmware isn't in the cards for now ;)  
> **username_3**: @username_2 1.1.9 works fine for my CoreXY, what issues do you mean? Maybe that helps the OP.  
> **username_2**: @username_3 I was referring to this Github issue: https://github.com/MarlinFirmware/Marlin/issues/11487 I've been using 2.0 since it came out (before moving to Klipper).  
> **username_3**: @username_2 I'd hardly call an unconfirmed issue a problem, this was probably some user induced fault, no other users with CoreXY printers have this problem (also this issue is closed by the developer).  
> **username_0**: @username_3 Check out the code that reports the endstop hit message in 1.1.8 (haven't check 1.1.9 yet).  

---

## 0 answers

