<p>Some info on the subject: few stepper motors have any way of knowing their exact position during operation, which means Marlin will have to assume the steppers always are in the right place. </p>

<p>In other words, all g-code commands are executed <em>relative to their current position</em>, not with regards to the real positions. So if you forcefully move the printhead during print, the printer will just continue printing the same patterns in mid-air (this is basically what is called <em>layer shifting</em>).</p>

<p>The only way the printer can know the real position of the steppers is when the endpoint switches are triggered. This is why the <em>homing</em> action is done to before prints in order to reset the internal positional bookkeeping of the steppers in Marlin. So if the endpoints are triggered without the printer actually being at the endstops, you will seriously confuse Marlin.</p>

<p>I agree that is sounds weird that Marlin does not reset the positions of it's steppers when an endstop is triggered (during print?), but then again, if it happens accidentally (and not as part of a re-calibration procedure), I believe the default actions should be to abort all operation since this would indicate the printer being out of control. Perhaps there simply is no routine to handle movement after the program has been aborted - a situation where probably nothing would be right anyway..</p>

CC BY-SA 3.0
2017-01-12T15:54:43.240Z
Thankyou, well said & informative.  I can now understand why this has, perhaps unintentionally, been unhandled.  I am not sure what the advantages of having this work correctly could be, but I will submit a code fix and bugreport to Marlin if naught than for the sake of completeness.
Mtl Dev
CC BY-SA 3.0
2017-01-12T07:05:30.167Z
2017-01-12T07:12:21.493Z
2017-01-12T07:12:21.493Z
Tormod Haugene
<p>Am seeing the following behavior in Marlin:</p>

<p>When moving the printhead, if an end stop is hit, a position report (M114) erroneously reports the print head position as where it was <em>trying</em> to go, as opposed to where it's position <em>actually</em> is.</p>

<p>For example (using pronsole):</p>

<pre><code>&gt; M114
X:1.00 Y:1.00 Z:1.00 E:0.00 Count A: 142 B:0 Z:1260  
&gt; G0 Z100
endstops hit:  Z:16.88
&gt; M114
X:1.00 Y:1.00 Z:100.00 E:0.00 Count A: 142 B:0 Z:21263
</code></pre>

<p>In this example, the Z endstop was hit at (z:16.88), but the printer appears to think it is at the target location (z:100).  </p>

<p>The "Count" Z appears to remain accurate however.</p>

<p>Question: Is this a bug in Marlin, or is this correct behavior and I am misunderstanding something?</p>

CC BY-SA 3.0
2017-01-11T22:07:47.403Z
If it a bug you should make a report to their github page.
MakerModder
CC BY-SA 3.0
2017-01-12T01:28:49.500Z
Thanks, and yes I will if it is.  First just seeking confirmation that this is a bug - I would be surprised that this would exist in something as mature as Marlin, as it would clearly throw the whole print job off - so I am first seeking confirmation from those smarter/more experienced that I if it is indeed a bug, or am I just misunderstanding something?
Mtl Dev
CC BY-SA 3.0
2017-01-12T03:05:37.450Z
I understand the concern to want to be sure that you have an issue before reporting it. However in this case they would be the best people to report it to. If you think about it, really, you just did a report, but to the wrong people :-)! It is likely the same amount of effort for us to look and not have an answer as it is for the guys who wrote the code. In my opinion the best use of effort is asking them.. I open bug reports all the time at companies like google. No big deal to do a report. Just don't think we will have the detailed knowledge to answer. But I could be wrong.
MakerModder
<marlin><firmware><motor>
Marlin, end stops, and position report - possible bug?
Mtl Dev
# Marlin, end stops, and position report - possible bug?

(Asked by: username_0 on 2017-01-11)

Am seeing the following behavior in Marlin:

When moving the printhead, if an end stop is hit, a position report (M114) erroneously reports the print head position as where it was *trying* to go, as opposed to where it's position *actually* is.

For example (using pronsole):

```
> M114
X:1.00 Y:1.00 Z:1.00 E:0.00 Count A: 142 B:0 Z:1260  
> G0 Z100
endstops hit:  Z:16.88
> M114
X:1.00 Y:1.00 Z:100.00 E:0.00 Count A: 142 B:0 Z:21263

```

In this example, the Z endstop was hit at (z:16.88), but the printer appears to think it is at the target location (z:100).

The "Count" Z appears to remain accurate however.

Question: Is this a bug in Marlin, or is this correct behavior and I am misunderstanding something?

**Tags:** marlin, firmware, motor

> **Comments:**
> **username_1**: If it a bug you should make a report to their github page.  
> **username_0**: Thanks, and yes I will if it is.  First just seeking confirmation that this is a bug - I would be surprised that this would exist in something as mature as Marlin, as it would clearly throw the whole print job off - so I am first seeking confirmation from those smarter/more experienced that I if it is indeed a bug, or am I just misunderstanding something?  
> **username_1**: I understand the concern to want to be sure that you have an issue before reporting it. However in this case they would be the best people to report it to. If you think about it, really, you just did a report, but to the wrong people :-)! It is likely the same amount of effort for us to look and not have an answer as it is for the guys who wrote the code. In my opinion the best use of effort is asking them.. I open bug reports all the time at companies like google. No big deal to do a report. Just don't think we will have the detailed knowledge to answer. But I could be wrong.  

---

## 1 answers

### Answer by username_2 on 2017-01-12. Score: 3 | Accepted answer

Some info on the subject: few stepper motors have any way of knowing their exact position during operation, which means Marlin will have to assume the steppers always are in the right place.

In other words, all g-code commands are executed *relative to their current position*, not with regards to the real positions. So if you forcefully move the printhead during print, the printer will just continue printing the same patterns in mid-air (this is basically what is called *layer shifting*).

The only way the printer can know the real position of the steppers is when the endpoint switches are triggered. This is why the *homing* action is done to before prints in order to reset the internal positional bookkeeping of the steppers in Marlin. So if the endpoints are triggered without the printer actually being at the endstops, you will seriously confuse Marlin.

I agree that is sounds weird that Marlin does not reset the positions of it's steppers when an endstop is triggered (during print?), but then again, if it happens accidentally (and not as part of a re-calibration procedure), I believe the default actions should be to abort all operation since this would indicate the printer being out of control. Perhaps there simply is no routine to handle movement after the program has been aborted - a situation where probably nothing would be right anyway..

> **Comments:**
> **username_0**: Thankyou, well said & informative.  I can now understand why this has, perhaps unintentionally, been unhandled.  I am not sure what the advantages of having this work correctly could be, but I will submit a code fix and bugreport to Marlin if naught than for the sake of completeness.  

---

