2

Similar to, but different from, 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?

  • Quick question, which version of Marlin are you running on your CoreXY? Old marlin or the new 2.0 branch? – Nach0z Jun 27 '19 at 13:12
  • @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 Jun 27 '19 at 15:05
  • @DaveNewton Last time I checked, 1.1.9 had some issues with CoreXY (too?). Just go with Marlin 2.0 – towe Jun 28 '19 at 07:35
  • @towe Thanks; alpha firmware isn't in the cards for now ;) – Dave Newton Jun 28 '19 at 19:10
  • @towe 1.1.9 works fine for my CoreXY, what issues do you mean? Maybe that helps the OP. – 0scar Jul 01 '19 at 08:23
  • @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 Jul 01 '19 at 08:40
  • @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 Jul 01 '19 at 10:18
  • @0scar Check out the code that reports the endstop hit message in 1.1.8 (haven't check 1.1.9 yet). – Dave Newton Jul 01 '19 at 13:05

0 Answers0