4

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?

Mtl Dev
  • 609
  • 2
  • 7
  • 19
  • If it a bug you should make a report to their github page. – StarWind0 Jan 11 '17 at 22:07
  • 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 Jan 12 '17 at 01:28
  • 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. – StarWind0 Jan 12 '17 at 03:05

1 Answers1

3

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..

Tormod Haugene
  • 3,947
  • 2
  • 20
  • 40
  • 2
    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 Jan 12 '17 at 15:54