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

LCD Bed Tramming Probe Loop Fix #26962

Merged
merged 5 commits into from
May 12, 2024
Merged

LCD Bed Tramming Probe Loop Fix #26962

merged 5 commits into from
May 12, 2024

Conversation

AlexanderThomasJulian
Copy link
Contributor

Description

Previously, when using LCD Bed Tramming with a probe, if the bed was adjusted to trigger the probe, and the distance between the bed and extended probe was < BED_TRAMMING_Z_HOP, the probe (if servo or piston) would deploy and immediately trigger. This premature triggering would result in the probe deploying again to verify the change, and would be followed by an immediate trigger. This deploy and premature triggering would continue over and over.

This pull request resolves this issue by adding the BED_TRAMMING_Z_HOP to the current_position.z to gurantee clearance between the bed and probe to compensate for the change in distance between the bed and probe due to adjustment.

Related Issues

Resolves LCD Bed Tramming Probe Loop

@thinkyhead
Copy link
Member

The configuration defines BED_TRAMMING_Z_HOP as an absolute Z position, and other logic in _lcd_bed_tramming_probe and elsewhere in Marlin still depends on that assumption. To change the meaning of this configuration setting, we'll need to update its description and change its usage everywhere else to match.

thinkyhead added a commit to MarlinFirmware/Configurations that referenced this pull request May 1, 2024
@@ -235,7 +228,7 @@ static void _lcd_goto_next_corner() {
}

bool _lcd_bed_tramming_probe(const bool verify=false) {
if (verify) line_to_z(BED_TRAMMING_Z_HOP); // do clearance if needed
if (verify) line_to_z(current_position.z + (BED_TRAMMING_Z_HOP)); // do clearance if needed
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code like this will need to be tested since it may now need special handling for the first point. We don't want to just raise over the current height before we've moved down to the bed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Upon initial review this change seems to be safe and won't adversely affect behavior.

ExtUI::setAxisPosition_mm(Z_MIN_POS + BED_TRAMMING_Z_HOP, ExtUI::Z);
}
if (BED_TRAMMING_Z_HOP)
ExtUI::setAxisPosition_mm(ExtUI::getAxisPosition_mm(ExtUI::Z) + (BED_TRAMMING_Z_HOP), ExtUI::Z);
ExtUI::setAxisPosition_mm(x, ExtUI::X);
ExtUI::setAxisPosition_mm(y, ExtUI::Y);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NOTE: These manual move methods are not ideal for this usage since they move only one axis at a time. The move to and from the center point ends up taking two moves instead of one. ExtUI should be extended with a method to move XY together (or this code should just use the motion.* functions directly).

@thinkyhead thinkyhead merged commit f5f6c37 into MarlinFirmware:bugfix-2.1.x May 12, 2024
62 checks passed
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