probe: Fixed premature firing of 'homing:homing_move_begin'

[nickweedon]

When probing multiple points such as when calibrating a bed mesh, the ProbePointsHelper start_probe method initiates a horizontal repositioning move and then immediately begins to probe without waiting for the repositioning move to complete. This causes the 'homing:homing_move_begin' to trigger before the Z direction move has even began. This is problematic when running BED_MESH_CALIBRATE with [homing_heaters] configured since it means that the bed will never attempt to re-heat.

This fix addresses this issue simply by waiting for the moves to complete before begining the actual probe.

[KevinOConnor]

Thanks. This change seems like it would cause significant delays during probe sessions (as wait_moves() takes a long time to complete). I'm not sure I understand the problem being reported - why does homing_heaters care where the toolhead is when homing nominally starts?

-Kevin

[nickweedon]

Thanks for checking this out! So homing_heaters cares about this because it needs to know when the actual BLTouch probe is about to begin as opposed to when the toolhead is simply being horizontally re-positioned. Otherwise it will keep the heaters turned off during the entire movement from the previous probe to the next probe. The impact is quite apparent as it means that the entire bed mesh probing operation becomes one giant chained sequence of probes where the bed heater is never re-enabled for more than a few milliseconds and thus the bed will usually be cold by the end of bed mesh calibration.

Here is an example of the old behavior:

Turn off heater -> probe -> turn on heater -> turn off heater -> probe -> turn on heater -> turn off heater -> move to next probe position and probe -> turn on heater -> turn off heater -> ...

New behavior (bed will be reheated between toolhead horizontal moves): Turn off heater -> probe -> turn on heater -> turn off heater -> probe -> turn on heater -> move to next probe position -> turn off heater -> probe -> turn on heater -> turn off heater -> ...

Note that I have not observed any slowdowns from 'wait_moves()' since it the printer is waiting on the horizontal movement but its quite possible i overlook/misunderstand something here?

As an aside, this fix is also necessary for my related bed reheating feature PR to work #6780

[nefelim4ag]

I did something like this to test:

[homing_heaters]
steppers: stepper_z
heaters: heater_bed

And tested the bed mesh sequence without and with patch:

I don't think this is the right way to work around that behavior.

As an example, that is my bed_mesh config:

[bed_mesh]
horizontal_move_z: 3
mesh_min:  20, 5
mesh_max: 380, 355
speed: 1000
probe_count: 7, 7

So 380/7 = 54 mm maximum distance between probes. By using the Prusa calculator With cruise ratio = 50%, move profile will look like this:

Let's roughly estimate travel time to move with that speed, assuming half of the time it will accelerate or deaccelerate. 54 / 2 / 400 + 54 / 2 / 200 = 0.2s this is barely enough to enable and disable heaters - heaters always scheduled 300ms ahead.

I tried to limit the speed to 50 mm/s, so I have around 1s between probes, and there is enough time to enable and disable them.

Looks like there are just no events that will trigger heaters enabled/disabled, and self.printer.lookup_object('toolhead').wait_moves() works as a hack.

[nickweedon]

Thanks for checking out this change @nefelim4ag.

So just to point something out here, irrespective of whatever algorthm you use and given current bed heater technology, if you are spending the majority of the time probing as opposed to anything else and you are also wishing to turn off the bed to avoid EMI interferance, then you will always have the bed go cold.

There is no free lunch here, it is impossible to keep the bed hot while running at the kind of speed and acceleration you are using and in fact even if you were to lower the speed significantly it may still not keep the bed at the desired temperature. If you are looking for this behavior then see my feature PR #6780. Apologies if this was unclear as I was using bed heating and probing as an example of the kind of behavior this bug fix addresses but this change is to fix a bug in the probing event logic, not specifically bed heating.

With regard to 'wait_moves', i'm really not sure why you refer to this as a hack as this is acutally the correct behavior. Repositining the toolhood should not be considered part of probing. This is part of the mesh calibration and it is illogical to conflate these things and it is in essence a bug. Please feel free to elaborate though if I perhaps overlook something here with respect to 'wait_moves'.

Just to further re-iterate, the bug fix is actually not supposed to address bed heating in particular. Technically this bug fix has nothing to do with bed heating, just the probing event which is logically decoupled from bed heating via an observer pattern. This event could actually be consumed by all kinds of different code for various reasons and cause similar bugs in those cases.

If you take a look at #6780 then you will see the actual solution that I have for bed heating. It can actually work independantly of this bug fix but i think it makes sense to fix this underlying issue as this will make for a bit more of an optimized solution when combined with #6780. I believe the #6780 feature is the only way possible to solve for the bed reheating scenario.

[Sineos]

While I cannot comment on how the proposed code is working, I do agree with the intention behind it.

When using the [homing_heaters] functionality, the temperature drops for both the bed and the extruder are quite significant, as they stay off for longer periods, such as during Quad Gantry Levelling or adaptive meshing.

I'd also appreciate an improvement here.

[github-actions[bot]]

Thank you for your contribution to Klipper. Unfortunately, a reviewer has not assigned themselves to this GitHub Pull Request. All Pull Requests are reviewed before merging, and a reviewer will need to volunteer. Further information is available at: https://www.klipper3d.org/CONTRIBUTING.html

There are some steps that you can take now:

1. Perform a self-review of your Pull Request by following the steps at: https://www.klipper3d.org/CONTRIBUTING.html#what-to-expect-in-a-review If you have completed a self-review, be sure to state the results of that self-review explicitly in the Pull Request comments. A reviewer is more likely to participate if the bulk of a review has already been completed.
2. Consider opening a topic on the Klipper Discourse server to discuss this work. The Discourse server is a good place to discuss development ideas and to engage users interested in testing. Reviewers are more likely to prioritize Pull Requests with an active community of users.
3. Consider helping out reviewers by reviewing other Klipper Pull Requests. Taking the time to perform a careful and detailed review of others work is appreciated. Regular contributors are more likely to prioritize the contributions of other regular contributors.

Unfortunately, if a reviewer does not assign themselves to this GitHub Pull Request then it will be automatically closed. If this happens, then it is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards, ~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.