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

[FR] Automatic/Dynamic UBL Fade Height #27095

Open
qwertymodo opened this issue May 15, 2024 · 2 comments
Open

[FR] Automatic/Dynamic UBL Fade Height #27095

qwertymodo opened this issue May 15, 2024 · 2 comments
Labels
T: Feature Request Features requested by users.

Comments

@qwertymodo
Copy link
Contributor

Is your feature request related to a problem? Please describe.

With the default/recommended fade height of 10mm, I get very significant extrusion problems on overhangs close to the bed, such as bottom-edge chamfers. Reducing the fade height to something very small, like 1mm or less completely eliminates these artifacts. I haven't dug into the issue very far to determine if there is some other related root cause going on here, like maybe a Z screw backlash issue, but it's definitely related to a large fade height, as you can see here. These files were printed back to back, with the exact same gcode, the only difference was the fade height. The one with the ugly chamfer artifacts was fade height 10.0mm, and the clean one was fade height 0.4mm.

GNlftvCa0AAdebh

Are you looking for hardware support?

N/A

Describe the feature you want

For me at least, a much smaller fade height seems to be far preferable to a large one. However, too small and you run the risk of a nozzle collision with high spots. And given the fact that the difference between high and low spots can change if the bed gets tilted (due to adjusting the leveling screws), or even the temperature, I think I may have a fairly simple, yet powerful solution. Instead of hard-coding a static fade height, the fade height could be calculated dynamically, based on the highest and lowest points in the bed mesh. The amount of fade could still be specified by the user to suit their own needs if they want more or less, but instead of giving a direct height in mm, it could be given as a multiplier that would be applied to that height difference between mesh points.

In terms of actual implementation details, it looks like there aren't very many letters left for parameter flags on G29, so either this could be implemented in M420, or else it could be a compile-time flag in Configuration.h that changes the behavior of the G29 F parameter to set the multiplier instead of directly setting the height value. Or perhaps both. In either case, the user would specify a "smart fade rate" as a float, and then any time the mesh is updated (e.g. mesh invalidated via G29 I or G29 P0/P1, mesh loaded via G29 L/M420 L, 3-point leveling, maybe others I can't think of), the current mesh is scanned for the highest and lowest points, and the fade height is recalculated as smart_fade_rate x (highest_z - lowest_z). Then, that calculated fade height is used exactly the same way the manually specified height is currently. That way, if the bed mesh is quite flat to begin with, the fade height can be kept small, but if something happens to create a large difference between the high and low, like a bed leveling screw coming loose, the fade rate can automatically adjust to fade more slowly and avoid crashing a few layers into the print at the high point.

Additional context

No response

@qwertymodo qwertymodo added the T: Feature Request Features requested by users. label May 15, 2024
@gudvinr
Copy link

gudvinr commented May 15, 2024

if something happens to create a large difference between the high and low, like a bed leveling screw coming loose

Then you should fix that instead of silently shoving real issue under the rug

If your bed isn't flat, you can't do anything about that other than replacing whole bed. But if it has too much skew, it can simply become a warning and it's up to you to decide how to proceed. Conclusion might be different depending on what you print

@qwertymodo
Copy link
Contributor Author

qwertymodo commented May 15, 2024

The leveling screw coming loose might have been a bad example, but even just simple uneven thermal expansion can make "large" (relative to the amount of correction the UBL system deals with normally) changes to the bed geometry as I demonstrated here, and the question of how much is a "large" change actually becomes quite small in absolute numbers when dealing in the context of the functionality I'm discussing here, trying to minimize the UBL fade height in order to eliminate a demonstrable print quality problem introduced by unnecessarily large fades, while also trying to avoid creating new ones. Also, the rest of the ABL system already accounts for those kinds of changes if and when they occur, it's kind of the entire point of the 3-point tilt function. This suggestion just expands on that idea to improve the behavior of the fade height in addition to the raw mesh.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T: Feature Request Features requested by users.
Projects
None yet
Development

No branches or pull requests

2 participants