Marlin: How to configure no XY endstops

Created on 25 May 2016 · 8Comments · Source: MarlinFirmware/Marlin

Comment in Configuration.h says "leave undefined", but when I comment them out then Marlin doesn't compile.

//#define USE_XMIN_PLUG
//#define USE_YMIN_PLUG
#define USE_ZMIN_PLUG
//#define USE_XMAX_PLUG
//#define USE_YMAX_PLUG
//#define USE_ZMAX_PLUG

No X and Y endstop, only Z min is present.

Question

Source

bond4u

👍1

All 8 comments

A machine without at least one endstop/homeswich per axis can not be homed - it's unusable. (Ok, triks with G92 are possible but unsafe because even the software endstops can not work.)

AnHardt on 27 May 2016

👎1 👍1

The "QuadRap" has no endstops. Perhaps it should be easier to do that.

thinkyhead on 27 May 2016

The workaround is to define one endstop per axis and playing with ?_???_ENDSTOP_INVERTING until this endstop is always untriggered. Leave it unconnected.

What is the supposed workflow with a "QuadRap"? Homing is manually moving to [0,0] and reset?

AnHardt on 27 May 2016

What is the supposed workflow with a "QuadRap"? Homing is manually moving to [0,0] and reset?

I'm setting up a new printer and have some endstop troubles. Allowing this functionality would be pretty nice to have for some niche users. My workflow is indeed a manual zero and then only zero when the controller+arduino have reset.

Dippyskoodlez on 30 May 2016

What is the supposed workflow with a "QuadRap"? Homing is manually moving to [0,0] and reset?

Setting up a new printer, as @Dippyskoodlez is doing, is one use-case for disabling all endstops, and it's the reason cited for making the QuadRap (initially) with no endstops, to reduce the cost (a tiny bit) and to make it easier to do the initial build. I actually edited the QuadRap article for RepRap Magazine Issue # 3, You can read about the QuadRap starting on Page 61.

thinkyhead on 30 May 2016

I had it working with 1.1.0-rc3 - move the head where You want 0,0 to be and print away (from sd card).
1.1.0-rc6 seems to "remember" its position and during 2nd print attempts to go out of build area.

bond4u on 21 Jun 2016

@bond4u Once the machine "knows" where 0,0,0 is, it should always be able to re-align for the next print, even if you don't re-home. But if your GCode includes a G92 X0 Y0 or something similar, that could explain why a second print could start at a different point. I can't think of any other explanations at the moment….

thinkyhead on 22 Jun 2016

Thank you for your interest making Marlin better and reporting this issue but this topic has been open for a long period of time without any further development. Marlin has been under heavy development for the past couple of months and moving to it's last mile to finish the RC cycle and release Marlin v1.1.0. We suggest you to try out the latest RCBugfix branch and reopening this issue if required.