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

Home offset to probe limits #26257

Conversation

kisslorand
Copy link
Contributor

@kisslorand kisslorand commented Sep 10, 2023

Description

Since PR #25996 Home Offset is not taken into account for probing motion limits. There's no prevention for moving elements to try to move beyond the endstops resulting in grinding and losing real coordinates.
I have home offset defined as my nozzle cannot reach the bed at 0, 0 coordinates. However if I want to make a probe let's say at the bed coordinates which correspond to the probe offset than the printer tries to move the nozzle to the bed's 0, 0 coordinate which is physically not possible.
This PR fixes this issue by limiting probing motion commands based on the defined home offset also.

@smiksky
Copy link
Contributor

smiksky commented Sep 10, 2023

PR #25996 changes the Home Offset behavior so that it is not and shouldn't be used everywhere, and is just used to set the point the printer homes to.

With your home offset set to 10mm, then the printer will think that the endstop triggers at 10mm, meaning that it can move over another 10mm to get to 0mm, the default X_MIN_POS & Y_MIN_POS in Configuration.h.

I believe that the issue described that your home offsets are inverted and it should be fixed by making them negative instead of positive. Also please note that home offset also will effect your maximum travel limits, so make sure the printer will not crash at that end either.

Since you are editing the firmware though, you can set X_MIN_POS and Y_MIN_POS to the positive distances from the front left corner of you bed the printer homes at, and that would fix your issue while still displaying the coordinates in relation to the bed.

This PR implements is redundant with the code above it (the _min_x through _max_y functions) and removes support for NOZZLE_AS_PROBE. If inverting your offsets does not resolve you issue, please provide more details about your printer so we can better diagnose the issue.

@ellensp
Copy link
Contributor

ellensp commented Sep 10, 2023

"I have home offset defined as my nozzle cannot reach the bed at 0, 0 coordinates"

This is a badly configured system.
Your machine has to be able to reach x0,y0
You should define the bed smaller than it physically is so that the entire bed 0 to bedsize is reachable

@kisslorand
Copy link
Contributor Author

There's nothing wrong with the system configuration.
I wouldn't define a smaller bed, I rather define the system as it is, With a smaller bed defined the nozzle will not reach the maximum size of it, without home offset I will not have the homing of the Z at the exact middle of the bed.

When the X hits the endstop on the left the nozzle is slightly to the right from the left edge of the bed, so the X home offset is positive.
When the Y hits the endstop on the back the nozzle is slightly to the back from the front edge of the bed, so the Y home offset is positive.

@ellensp
Copy link
Contributor

ellensp commented Sep 11, 2023

If you do not define a smaller bed, then when you come to print something that is bed size (or just overhangs that unreachable area) , the object will be clipped to the lowest reachable axis value. NOT at slicing time, but when you try and print it

The slicer will not warn you of this as slicers expect you be be able to print the entire bed size specified.

This is a Configuration error.

@smiksky
Copy link
Contributor

smiksky commented Sep 12, 2023

As I previously mentioned, you can set your X_MIN_POS & Y_MIN_POS in Configuration.h to the home position and it will be blocked from going to (0, 0), but that is not an ideal solution and slicers will interpret it weird.(0, 0) should be the front-leftmost point you nozzle can reach, and your bed size should be reduced to your available print area. Basically, what ellensp said.

Both this PR and #26256 should be closed, as they both are work-arounds for a configuration error.

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.

4 participants