[2.0.x] Add delta_height variable in lieu of using home_offset #8344
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
#8229 appears to have broken the height adjustment for Delta machines due to the way that the height was adjusted via
home_offset[Z_AXIS]
. This PR adds a dedicateddelta_height
variable that can be directly adjusted and also ensures that thecurrent_position
andsoft_endstop
limits are configured appropriately after homing.I tested this on my Delta machine with the default
DELTA_HEIGHT
set to values +- 20mm from the true height of my machine.With
DELTA_HEIGHT
set to 20mm less than the true height,G33
generates probing failed messages after the first probe event because the first probe attempts to go to -50, but the subsequent probes only go to -10, so they never reach the bed. RunningG33 P1
to just set the delta height prior to runningG33
allows the calibration to succeed.With
DELTA_HEIGHT
set to 20mm greater than the true height,G33
succeeds, but the first iteration ends up double probing each probe event because the probe is triggered during the fast movement phase of the probe.I think we should look into making
G33
first perform a single probe followed by a home to set the delta height (i.e.G33 P1
), and then continue with the iterations. Perhaps @LVD-AC can help with this sinceG33
is rather complicated. In any case, this is the same behavior as prior to #8229, so I think we can continue with this PR and apply any updates toG33
is a separate PR.