Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow Zero Endstops (e.g., for CNC) #21120

Merged
merged 15 commits into from
Feb 25, 2021
Merged

Allow Zero Endstops (e.g., for CNC) #21120

merged 15 commits into from
Feb 25, 2021

Conversation

deirdreobyrne
Copy link
Contributor

@deirdreobyrne deirdreobyrne commented Feb 17, 2021

Description

Some machines (e.g. cheap Chinese CNC machines) come without endstops. Such machines cannot be homed, and so need to be considered to always be in a known and trusted position. It is up to the user to ensure that there are no toolhead crashes.

My test for a machine without endstops is that none of USE_[XYZ]MIN_PLUG or USE_[XYZ]MAX_PLUG are set.

The only thing I'm not sure of is in the motion.cpp set_axis_never_homed(...) implementation. There is a test for I2C position encoders. I cannot see how a machine cheap enough to not have endstops would ever have position encoders. Should this combination throw an error in SanityCheck.h?

Benefits

Marlin now becomes useful on the cheapest of machines that have no endstops!

Postscript

(p.s. my first ever PR - feedback welcome)

Concise Diff

…cannot be homed. They must always be considered to be homed, and cannot be 'un-homed'.
@thinkyhead thinkyhead changed the title Bugfix 2.0.x Allow Zero Endstops (e.g., for CNC) Feb 18, 2021
@thinkyhead
Copy link
Member

Thanks for the submission. I've cleaned it up and extended it a bit, but haven't evaluated the question of encoders. However, since they are somewhat independent of each other, we should allow for something that has encoders but no endstops.

@deirdreobyrne
Copy link
Contributor Author

I've just noticed that there are tests in the code for the toolhead being over the bed, with different behaviour (e.g. no skew correction) when the toolhead moves off the edge of the bed. Makes full sense in the context of a 3D printer, but I think in the context of a CNC that has no endstops (and hence the coordinates that correspond to "over the bed" are flexible) those tests should be bypassed. Going to look at it closer later.

deirdreobyrne and others added 5 commits February 19, 2021 08:02
Fixed the conditional at the end of Conditionals_LCD.h - USE_ZMIN_PLUG was duplicated in the #if

Having no endstops affects much more than just the planner, as checks are carried out in various places in the code to ensure the toolhead won't crash. But without endstops Marlin can never know if a crash is imminent, so the checks need to be disabled.

Endstop-less machines (notably CNCs) can still have probes. Whether or how bed levelling works on such machines needs to be experimented on. Such machines also, for example, cannot reasonably have tool parking. Sanity checks have not been implemented to catch such probable anomalies.
@deirdreobyrne
Copy link
Contributor Author

Currently working on implementing G68 and G69 (rotated co-ordinate systems). Not sure how I should create another PR when its ready?

My use case is PCB milling. With double-sided milling, it's important, and difficult, to get the second side of the PCB in the same orientation that it had when the first side was milled. An answer is to drill fiducials in the PCB, and use them to determine the actual orientation after flipping to the second side.

@thinkyhead
Copy link
Member

Not sure how I should create another PR when [it's] ready?

For simplicity, you'll want to wait for this to be merged, and then build on top of bugfix-2.0.x after that. Otherwise you'd have to do some git tricks to get back in sync.

@deirdreobyrne
Copy link
Contributor Author

Cool - thanks! Is there anything I should be doing to help matters along? (I'm new to this. I've done tests, and it all seems OK to my eye. I've tested leveling, and it also seems fine).

@thinkyhead thinkyhead merged commit 468e437 into MarlinFirmware:bugfix-2.0.x Feb 25, 2021
Vertabreak added a commit to Vertabreak/Marlin that referenced this pull request Feb 25, 2021
@deirdreobyrne deirdreobyrne deleted the bugfix-2.0.x branch February 25, 2021 13:59
rhapsodyv added a commit to rhapsodyv/Marlin that referenced this pull request Feb 25, 2021
vyacheslav-shubin pushed a commit to vyacheslav-shubin/Marlin that referenced this pull request Mar 10, 2021
Co-authored-by: Scott Lahteine <thinkyhead@users.noreply.github.com>
vyacheslav-shubin pushed a commit to vyacheslav-shubin/Marlin that referenced this pull request Mar 10, 2021
Co-authored-by: Scott Lahteine <thinkyhead@users.noreply.github.com>
W4tel-BiDi pushed a commit to W4tel-BiDi/Marlin that referenced this pull request Apr 5, 2021
Co-authored-by: Scott Lahteine <thinkyhead@users.noreply.github.com>
thinkyhead added a commit that referenced this pull request Apr 30, 2021
Co-authored-by: Scott Lahteine <thinkyhead@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants