-
-
Notifications
You must be signed in to change notification settings - Fork 19.3k
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
[BUG] G29 results in random small Z error with BILINEAR leveling #23843
Comments
I am working on a fix for this. Issue raised just to document it. |
I have encountered a similar problem, I use Mesh bed leveling. Below I am attaching my START GCODE,
It does not perform the operations at the same time, it first moves the Y axis and then extrudes beyond the Y axis.
|
@andreibobirica I have been looking into PLANAR, 3POINT and BILINEAR leveling. There are a number of things I am aware of. Some may apply more generally and so affect MESH leveling. Two questions:
Do you mean it moves Z and Y separately? This is normal. From memory, I think it might be to do with preventing head crashes on non-cartesian machines. |
in the image I have shown on the left side the Ideal behavior with the start gcode posted above, in the right part it is an approximation of the true behavior with the new firmware. I do not use Skew corection and It Is not activated. I poster my problem because i think Is related to G29 GCODE. |
This sounds like a different problem to the one I was raising. I suggest you raise an new BUG issue. |
Looking like I have the same issue - no matter what I do, my first layer is refusing to stick to the bed (not squished enough). Does not seem to be hardware, happens regardless of slicer. Changing the Z-Probe offset on the printer itself does not change anything. BTT SKR mini E3 v2, Marlin 2.0.9.3 and Bugfix (March 2022) as well. |
That surprises me. With a low (or negative) enough Z probe offset you should eventually get squished lines in the hardware is physically able to get the head down that far. This bug results in inconsistency - sometimes the lines are squished too much and sometimes not enough. Decreasing Z probe offset makes the lines oversquished more often. |
I'll try to do some testing - I raised my bed a fair amount and the same results were still happening. It may also be a different bug... my purge line comes out fine, but the actual print isn't squished enough. Once I get some wiring fixed, I'll try to narrow it down more. |
Converting from mm to steps and then back from steps to mm as part of leveling enable/disable may introduce a small error, but it should be relatively insignificant. Whenever there are homing or leveling issues, we now ask everyone to follow a standard procedure to gather more information so that we're not just taking stabs in the dark. Here is the boilerplate:
Repeat this procedure, if needed, to demonstrate inconsistencies. From these logs we should hopefully get a better idea of what's going on with your machine. |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Did you test the latest
bugfix-2.0.x
code?Yes, and the problem still exists.
Bug Description
At the end of running G29, leveling is applied to
current_position
. See line 880 ofMarlin/src/gcode/bedlevel/abl/G29.cpp
When
bilinear_z_offset()
is called, cached values from the previous mesh are used to calculate the offset. The freshly measured mesh is ignored.In principle, it might seem like this should not happen because earlier in G29, on line 443, there is:
And
set_bed_leveling_enabled()
has this:However, there are two problems with this way of clearing the cached Z offset values. First,
set_bed_leveling_enabled()
goes on to callplanner.apply_leveling()
which callsbilinear_z_offset()
again. This is only really a problem if you call G29 when the nozzle is already at the last probing point, e.g. by calling G29 twice in a row.Second, and more seriously, calling
bilinear_z_offset()
caches not only the specific nozzle position but the whole mesh cell in which that nozzle position falls (in variablelastg
). So there are many scenarios where G29 can use the wrong cached values for some time.Example behaviour with the default values in Configuration.h:
GRID_MAX_POINTS_Y = GRID_MAX_POINTS_X = 3
Bed size is 200 x 200.
PROBING_MARGIN = 10
Valid mesh already exists and leveling is applied.
Bug Timeline
In 2017, commit 830851d.
Expected behavior
No response
Actual behavior
No response
Steps to Reproduce
No response
Version of Marlin Firmware
Latest bugfix branch
Printer model
No response
Electronics
No response
Add-ons
No response
Bed Leveling
No response
Your Slicer
No response
Host Software
No response
Additional information & file uploads
No response
The text was updated successfully, but these errors were encountered: