LCD_BED_TRAMMING fixes

[Farva42]

Description

This allows LCD_BED_TRAMMING to work with a stowable probe like MAG_MOUNTED_PROBE, SERVO_PROBE, or TOUCH_MI_PROBE. Before if the probe was not deployed before initiating tramming the printer would not attempt to deploy the probe and loop continually raising Z till it hit Z max.
The no_mem was added to reduce excessive movement before and after probe deploy/stow moves.

This also fixes bed tramming ignoring probe offsets which can cause issues with the printer trying to probe off the print bed.

Requirements

LCD_BED_TRAMMING to be enabled with BED_TRAMMING_USE_PROBE to see the offset issue.
both the above and a prob covered in HAS_STOWABLE_PROBE for that fix

Benefits

Lets printers with HAS_STOWABLE_PROBE use LCD_BED_TRAMMING easily and fixes the probe offset issue.

Related Issues

(#24728)

[Farva42]

Bah sneaky BLtouch flagging HAS_STOWABLE_PROBE via being a Servo probe. I need to guard the probe.deploy and stows from getting called with a bltouch enabled before this is good.

[Farva42]

This should be good to go now. If wanted the DISABLED(BLTOUCH) can come out of the NEEDS_PROBE_DEPLOY if wanted but keeping it will mean that it would only deploy before probing instead of potentially being deployed while moving.

[thinkyhead]

It made sense to merge _lcd_bed_tramming_get_next_position and _lcd_goto_next_corner which also saves some SRAM by removing the global corner_point. Hopefully there are no egregious typos. With the other neutral refinements already merged, this PR is reduced down to the logical changes related to NEEDS_PROBE_DEPLOY. Please confirm that it is still behaving as it was.

I have also been working on general probe refinements, but of course this procedure is different from regular probing, so there are no standard Probe class methods to handle its quirks. The main thing I'm still a little hung up on is when to use line_to_z(current_position.z + BED_TRAMMING_Z_HOP) versus just BED_TRAMMING_Z_HOP. It used to be that when BED_TRAMMING_USE_PROBE is enabled _lcd_goto_next_corner adds current_position.z, and otherwise it doesn't. So I've altered _lcd_goto_next_corner to always add current_position.z but maybe that is inappropriate. It would be worth comparing the behavior with and without BED_TRAMMING_USE_PROBE to make sure the raise amounts are appropriate in each case. I will test this tomorrow evening if you haven't already given feedback.

[Farva42]

I just got some time to test this. It is now causing looping with use probe enabled it will never exit and just continues to probe over and over. It is also not prompting to raise the bed if a corner is low it will just probe down to where it last hit and then go back up and go to the next corner. I'm going to start testing to see what caused it to start looping.

[Farva42]

I found the cause of the looping. The line_to_z move down to BED_TRAMMING_HEIGHT was causing the probe to be triggered and causing issues.

In regards to the Tramming hop, having the current position added in was causing a massive hop for me as it would be adding it to the Z height after stowing the probe from the homing which for my setup is 20mm so my hop would be 24mm every time. It could be changed to use Z_CLEARANCE_BETWEEN_PROBES as that should be a safe value as it would already be used between other probings. But I think having the current position can cause some excessive hops in some situations.

[NarryG]

I just got some time to test this. It is now causing looping with use probe enabled it will never exit and just continues to probe over and over. It is also not prompting to raise the bed if a corner is low it will just probe down to where it last hit and then go back up and go to the next corner. I'm going to start testing to see what caused it to start looping.

I'm running the latest bugfix build with this commit merged and am experiencing a similar but slightly different issue with my BLTouch.

It will probe a corner over and over again until I slightly adjust it so it doesn't contact, where it will then prompt me to raise the corner back up.
The probe appears to be deploying while moving back upwards, contacting the plate, which I believe is resulting in a bad reading. If I use this technique of adjusting the bed so it doesn't trigger and properly prompts me to raise the bed, I do not get level corners.

I am currently running a print but can provide a video tonight.

Running on an Ender 3 Pro with an SKR Mini E3 v3 board. BL Touch