-
-
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] bugfix-2.0.x - Auto Bed Leveling not working as expected #13512
Comments
If you have a system that works well then stick with it. If it has problems then take a look at the following. I prefer the UBL system myself. |
The working system is the manual bed levelling, that doesnt produce good first layers, obviously, as it doesnt level in the center but only in the corners Already saw these guide, they are what i've followed to enable the UBL |
upload configuration.h and configuration_adv.h and fix the title of this issue. |
As soon as I go to office, give me 30 minutes or less
bugfix-2.0.x
z-offset set as 0
Sorry for the title, i didn't see that the title was wrote properly, I was on mobile. Fixed |
I've checked the config files and I'm using the one provided with Marlin, for Geeetech A20M except enabling the BLTouch and setting the probe offset. No other differences as I'm trying to fix the bed levelling, everything else will be addresses after all
|
When I enabled UBL my first matix was terrible. I did the G29 P1 to get the initial matrix but after that I kept repeating the "G26 , G29 P4" loop until I was getting good first layer adhesion everywhere.. After that I used G29 P6 to shift everything up/down based on test prints. |
I can try Is zoffset ignored when using the ubl mesh? I have to rebuild the mesh every time i change the Z offset? |
Side question: with UBL enabled, can I temporary disable the mesh and just use a plain simple 3Point level or a LINEAR leveling with 4 or more points, without the mesh correction ? |
Usually... This behavior is because a person is changing the Z-Offset in the firmware (configuration.h) and not in the EEPROM. Are you doing a M502 & M500 after changing the firmware?
Yes. You can do a G29 P0 to zero the mesh. And then a G29 J to do a 3-point leveling. You can do a G29 J 2 for a 2 x 2 grid of probe points. |
Yes. But when I'm talking about changing the z-offset, i'm referring to changing it from the LCD and the save (still from LCD)
Thank you. This should disable the mesh and activate the 3Point or the Linear. What if I would like to try the BILINER? Just add a number of points greated than 2 to "G29 J" will enable BILINEAR or still LINEAR with multiple points ? Zero-ing the mesh is mandatory ? Isn't possible to temporary disable it for a single print ? |
if you did not remove the original z end stop you will get false triggers from it as the probe and the end stop run on the same z min pin, if the original z end stop is removed it will allow the probe to function without being false triggered and blocked by the original z end stop. this is the only thing i can think of that would result in what you describe and has also been documented in another post here on GitHub. |
I don't have the endstop. Currently, I'm able to print a decent first layer, just trying to figure out the source of some strangeness. In example, does make sense, with chinese printers, to have z-offset with 2 decimal? The printer is able to move Z to 0.10 and 0.15 differently ? Asking this because from the motion menu I can move just up to 1 decimal place, but the z-offset has 2 decimal places. |
the lcd menu motion moves are limited if you where to issue the gcode move command manually from a terminal you could type in a more exact number. |
Sure, but does it make sense to adjust zoffset at 2 decimal place precision ? I don't think any FDM printer would be able to reach a 10 micron resolution on Z. Maybe i'm wrong |
i have never used more then 1 decimal place setting my z offset personally but others claim they must. |
So, if you can print at .06, some printers are able to print at that resolution. My correct z-offset is -2.40, if I set -2.40 first layer seems to be too hight, if I set -2.50 seems to be too low. It seems that Marlin is correcting too much. The paper sheet at -2.50 offset is totally fixed, doesn't move at all, this usually means a too low nozzle. This is what I'm trying to figure out. Why setting a -2.40 offset (that is correct) Marlin doesn't stay too hight and with -2.50 is too low? The mesh seems correct |
the offset moves the entire mesh up or down if your trying to correct 1 spot on the bed the offset will not do that. |
Is not one spot. I have one spot a correct and one spot (a couple of centimeter on the right) too low. I'll try to print near the edge, if i'm able to print properly even there, everything would be ok. Not perfect but still good is something acceptable for my prints. When I have more spare time i'll do a mesh edit point by point I'll keep you updated in about 30 minutes |
There's a better explanation of the G29 options/function in the file ubl_G29.cpp I use G29 P4 to edit individual points in the mesh. That should help with your "point X is OK but point Y isn't" problem. I have a glass bed so I just circle the problem area with a dry erase marker, use G29 P4 and make an adjustment when the nozzle is over the problem area. One possible cause of the "point X is OK but point Y isn't" problem is too few points in the matrix. On my machine a 5x5 matrix is OK but I see others that use 7x7 or even 9x9. |
I have a 7 * 7 Matrix. I can try a 8 * 8 or 9 * 9 |
Can use all but the last 1kb ram it won't compile with less warnings don't mean much. |
Build time is not an issue, i have to do this just one time . If the memory warning can be safely ignored, i could try with a 9 * 9 mesh. There will be 32 additional points |
I tested all the way up to 15x15 then scaled back till it wasn't accurate enough. I can get away with 3x3 on my bed if I wanted. my builds usually have 7x7 due to community demand. Could even print on a 2x2 it wasn't as accurate but was useable. |
7x7 is probably OK. Have you tried G29 P4? |
Already using 7x7
Not yet. |
Well, yes, I'm able to print with a simple 3 points leveling, but as i have a sensor probe, i would like to get the first layer as accurate as possible. |
G29 P1 with my BLTouch has never produced a useable matrix for me. Here's how I tune my matrix:
The reason why I put the head over the bed before issuing a command is my head can go beyond the bed and some settings of the matrix result in the head being too low and hitting the edge. |
Rather than doing 12 & 13 you can use babystepping to adjust the head height during a real print. For me babystepping doesn't work about half the time. Wonderful when it works. |
Any update on this ? In example, if the lower right corner is at -0.10 and the upper left corner is at +0.10, I have a 0.20mm tilted bed. When moving from the lower right to the upper left, the firmware should raise the nozzle automatically. This doesn't happen. |
works for me... i do M502, then M500 to clear eeprom where tilt data is also stored then on lcd i make sure that bed leveing is set to ON under motion menu |
@Virtualight how did you solve it? |
I had issue too, |
@guestisp did you solve this one? |
Lack of Activity |
Hi, I have this issue too. M502 factory reset here my startup code: executing a printing to test the first layer, i see that printing is not compensated uniformly on the bed. |
There has been problems with the EEPROM that cause issues which includes problems saving the UBL meshes. This was fixed in a commit December 6th. It was good that you told about the Marlin versions you are running. Try compiling new firmware version using Marlin bugfix-2.0.x branch and see if solves the issue. @p4PpS @stratodream Personally also using SKR e3 mini v1.2 and similar problems with bed leveling was fixed with updating the firmware. |
Ok, I check and provide a feedback asap. |
I checked and unfortunately issue is still present. |
I To have this issue,does inductive sensor get distracted by magnets which is been placed under the bed |
Or is that really due to firmware |
I have a bltouch and It worked good before moving to Marlin 2.0.
Il ven 20 dic 2019, 16:38 gokulvenkat <notifications@github.com> ha scritto:
… Or is that really due to firmware
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#13512?email_source=notifications&email_token=AD3S4AWTPVNJPMNTOFHERODQZTRILA5CNFSM4HB3Y442YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHNH32A#issuecomment-567967208>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AD3S4AT3ZFFLHEDNPCJQWGLQZTRILANCNFSM4HB3Y44Q>
.
|
I am having this same issue also. Ender 3 and SKR mini E3. Seems like there is no compensation when moving from point to point. |
then there are 4 reasons for this issue according to me:-) |
According to me It Is only a Marlin Bug.
1) Is not changed from meltzi configuration and i personally reported the
same values in fw.
2) i have no issues in mounting
4) i think signal interference are very not probable.
In my configuration the only change Is in fw and board.
Il mar 31 dic 2019, 12:34 gokulvenkat <notifications@github.com> ha scritto:
… then there are 4 reasons for this issue according to me:-)
1.improper offset distance between nozzle and probe might be entered in
marlin
2.unwanted play of probe mount during probing
3.or firmware issue(bug or improper bed leveling settings
4.there can be a noise in the probing signal due to any ac voltage near
the signal wire which can be the reason for wrong triggering values
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#13512?email_source=notifications&email_token=AD3S4AWEISJEC2DPO2SHFKLQ3MU2ZA5CNFSM4HB3Y442YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH4DKHI#issuecomment-569914653>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AD3S4ARIIUD5NS4QFWD6R3DQ3MU2ZANCNFSM4HB3Y44Q>
.
|
Okay cool I told only the possibility of the issue and i am confident on the option 3 which is a firmware issue |
I am still facing the bed leveling issue |
In my opinion a new issue shall be opened, It Is no so comfortable doing It
with a smartphone.
Could you please do It ?
Il mar 31 dic 2019, 12:50 gokulvenkat <notifications@github.com> ha scritto:
… I am still facing the bed leveling issue
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#13512?email_source=notifications&email_token=AD3S4ATWA473ZOM7PJJVKPDQ3MWX5A5CNFSM4HB3Y442YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH4D2HA#issuecomment-569916700>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AD3S4AXHEQXR5CD6VO4NMRLQ3MWX5ANCNFSM4HB3Y44Q>
.
|
yep sure |
auto bed leveling issue #16397 opened |
comment there about your issues bro |
Too bad this have been closed, as the bug are indeed still there! |
I have similar problem. |
Sometimes simply the expectations, what Auto Bed Leveling can do and what not, are wrong - not what ABL does. |
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. |
Hi to all.
I'm trying to use a genuine BLTouch sensor (I think v2.1) but without luck
The mesh is build properly, auto-home is working as expected, but when running a print, the nozzle is lifter too much even where there is no need to lift it and nothing stick to th bed.
If I disable the mesh and the autolevelling, with the same glass and the same manual leveling, i'm able to print properly. So, there is something strange with the UBL or with the auto bed levelling, because enabling it make more issues than without.
Any idea ? I've tried 2 different bltouch (both genuine) on 2 different printers, same behaviour, the nozzle is lifted and lowered with no apparent reason and for too much distance (even 1-2mm)
A glass can't have a 1mm "hole" in a couple of centimeters, it's physically impossible and that would be visible by eyes.
The text was updated successfully, but these errors were encountered: