klipper icon indicating copy to clipboard operation
klipper copied to clipboard

probe: Fixed incorrect "Toolhead moved" errors

Open Matszwe02 opened this issue 10 months ago • 5 comments

Toolhead can now move between probes, as long as it returns during (de)activate_gcode

Applied fixes to this PR

This PR allows to move the probe between probing, but ensures that the probe returns to the original position. With the previous approach, any movement will cause float inaccuracy, which triggers the condition. With the fixed approach, the movement is allowed, if the probe goes to its original position at the end of the gcode. That feature is helpful for some exotic probes (like mine) which require movement between probing.

Matszwe02 avatar Apr 18 '24 21:04 Matszwe02

Out it curiosity (it might be obvious but I'm not thinking of it) what probe requires X/Y movement during triggering? That seems to contradict the definition of being a probe, as the probe is probing that spot.

TheFuzzyGiggler avatar Apr 19 '24 10:04 TheFuzzyGiggler

Out it curiosity (it might be obvious but I'm not thinking of it) what probe requires X/Y movement during triggering? That seems to contradict the definition of being a probe, as the probe is probing that spot.

I have a loadcell mounted on the z axis, which requires moving z up and down a bit to reset very little of backlash that otherwise will trip the probe

Matszwe02 avatar Apr 19 '24 13:04 Matszwe02

Thanks. This change looks odd to me as the purpose of the error is to warn users that Klipper's internal calculations do not support movement during the macros. It's not clear to me that these internal calculations support even a little movement - an audit of the code would be needed to ensure the code works correctly.

If you need to take certain movements before or after probing, it's probably best to do that in a macro that invokes the probing process.

Separately, I committed the fix to the error messages (commit 7b490f3e).

-Kevin

KevinOConnor avatar Apr 27 '24 15:04 KevinOConnor

Thanks. This change looks odd to me as the purpose of the error is to warn users that Klipper's internal calculations do not support movement during the macros. It's not clear to me that these internal calculations support even a little movement - an audit of the code would be needed to ensure the code works correctly.

If you need to take certain movements before or after probing, it's probably best to do that in a macro that invokes the probing process.

Separately, I committed the fix to the error messages (commit 7b490f3).

-Kevin

Thanks for the response. Do you mean, that klipper's motion queue needs to be checked for that small movements, or my PR's code?

I have been printing for a long time, and it appears to be working well. I will also need to check for edge case scenarios to make sure it will and won't trip when needed.

Matszwe02 avatar Apr 30 '24 09:04 Matszwe02

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.

github-actions[bot] avatar May 29 '24 00:05 github-actions[bot]