Klipper3d / klipper

Klipper is a 3d-printer firmware
GNU General Public License v3.0
9k stars 5.18k forks source link

hall_filament_width_sensor: max filament diameter #6374

Closed ressu closed 6 months ago

ressu commented 8 months ago

Add support for maximum filament diameter to hall filament width sensor. If the diameter of the filament diameter is larger than the limit, the virtual runout sensor will trigger. The default value is set to maximum flow adjustment threshold to prevent oversized filament from clogging.

github-actions[bot] commented 8 months ago

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.

dewi-ny-je commented 7 months ago

@KevinOConnor this is a straightforward to check and as far as I can tell it's done correctly. We can of course discuss about the difference between "filament present/runout" and "min/max diameter" for performing the correction, but as long as the current overall design of the module is maintained, the changes proposed seem ok to me.

The feature is quite useful, since sometimes too wide filaments (blobs, for example with joined filaments or home made filaments) can get stuck in the reverse-Bowden tube, or in the Bowden between extruder and hot end (for example EVA toolheads use this configuration).

ressu commented 7 months ago

Just to clarify, this won't catch short blobs due to the way how measurement is done. The blob needs to extend at least over 10mm (or what ever is the configured measurement distance) and generally needs a bit longer than that. But it will detect out of spec filament reliably.

I agree that the internal variable naming should change a bit, but it I wanted to keep the changes to minimum in the PR and did my best to find suitable names for the variables within the constraints we had.

I've been running this locally for a few weeks now.

dewi-ny-je commented 7 months ago

Then it's much less interesting, but it still makes sense to some degree.

It would be even nicer to use the Hall filament sensor module for both blobs and average compensation, for example by polling diameter every 1 mm just for filament run out/blob detection, and every 10 mm for diameter compensation.

Once I start working on the module to find a better way to apply the compensation (mid-2024 maybe?) I'll look into it. Ideally, I would prefer the compensation not to translate into flow% corrections, since those should be a user-facing correction which should not jump around. But it's not clear what to use instead.

github-actions[bot] commented 7 months ago

Unfortunately a reviewer has not assigned themselves to this GitHub Pull Request and it is therefore being closed. 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.

KevinOConnor commented 7 months ago

I don't know enough to really review this. However, it seems fine to me. If you confirm this PR is still ready to merge then I'll look to commit.

Cheers, -Kevin

ressu commented 7 months ago

Yup, ready to merge. I synced the branch to master just now to verify that it still cleanly applies.

KevinOConnor commented 7 months ago

Thanks. I just realized that this is a change in behavior. So, I think we should document that change in docs/Config_Changes.md (or alternatively change the default to be high enough that it would not cause a runout trigger).

-Kevin

ressu commented 6 months ago

Apologies for the late update. I went back and forth with setting a high default vs. sticking with the default and documenting it.

In the end I came to the conclusion that when you exceed the maximum adjustment, the behaviour is going to be unwanted and the whole purpose of the diameter sensor is to avoid those artifacts. So for (what I think are) the majority of users that use this feature having the print pause automatically when the automatic adjustment range is exceed is the desired behaviour. So instead of asking everyone to update their configuration individually, it makes sense to have those that prefer print quality issues over print pausing change their confiuration instead.

KevinOConnor commented 6 months ago

Thanks. Looks fine, but I need a signed-off-by line here or in the commit. See https://www.klipper3d.org/CONTRIBUTING.html .

-Kevin

ressu commented 6 months ago

Whoops, missed that when I rebased the changes. Fixed now.

KevinOConnor commented 6 months ago

Thanks.

-Kevin