Bug with marling 1.1.8 mesh bed leveling

[batata004]

Hi,

I've been using Marlin for a loong time, it's awesome and unfortunattely the mesh bed leveling for some reason is not working well - not at all. I am using the bed mesh leveling with inductive probe. To increase accuracy I am using 16 mesh points (yeap, 4x4) before every print and even with this I am not getting consistent leveling. I even configured MULTIPLE_PROBING as 3 so I could get better results, but nothing improved.

I attached a veeery simple file that I am trying to print JUST to show you this bug. I also attached my configuration file which is pretty standard. I am not doing anything stupid, I do 3d printing for a long time ;)
files.zip

I recorded the problem in video so you can see the bug. I recorded my printer trying to print the STL file attached. Unfortunatelly I used a potato to record the video so please, forgive my lack of a better potato to record.

https://photos.app.goo.gl/kgOyukch0IkbODBt1

At the beginning I shows you the bed leveling. After that it starts printing. You can see that at the left of my heated bed the filament is getting very well compressed to the bed and it sticks very well. HOWEVER in the right side the filament is loose cause the nozzle is not close to the bed. It's actually a little higher than it should. This tells me the mesh bed leveling is buggy cause if it was doing it's job right, the nozzle should keep a constant distance from the heated bed.

[Roxy-3D]

You are using Bi-Linear bed leveling. It is meshed based. But typically when that term is used, it refers to the very original Mesh Bed Leveling system done by epatel. (He did a great job!!!!)

You really should bump your mesh size up much higher than 4 x 4. And once you probe your your mesh, you can save it so you don't have to do it again. And then... Any imperfection you find, you can edit in the mesh and resave it.

The problem you are talking about has been reported in multiple threads. You might want to switch to a different bed leveling system until we find the problem and get it fixed.

[batata004]

@Roxy-3D thanks as always, you are very supportive!

After reading your notes, is there any other bed leveling method already implemented in marlin that is better than "Bi-Linear" (which I am currently using)? Or, in my case, where I am using an aluminum surface that is not very flat and regular (as glass), you would suggest any other method?

You said I should increase my mesh size, would you recommend any number? 8x8? 10x10? Do you really think it would fix my problem cause I really suspect there is some bug with the mesh bed leveling implementation.

I tried to find other threads reporting this same problem but I couldnt find. Would you mind providing me just one link so I can follow it up?

Thanks again and I really want to fix this problem cause it prevents me from printing big things, most of the time I have to print small things in the left side so it sticks well to my bed.

[Roxy-3D]

After reading your notes, is there any other bed leveling method already implemented in marlin that is better than "Bi-Linear" (which I am currently using)?

I am hesitant to say one system is better than another. They all serve a purpose. It depends on many factors. For example, how much program space your processor has. If you have a 128KB AVR, you probably shouldn't (can't) run UBL. If you have a perfectly flat bed, there may be no reason to add the complexity of running a mesh based system.

But with that said... I'm pretty sure you won't experience the problem you are describing with UBL. The big problem with UBL is it is a super set of all the previous bed leveling systems and that does add complexity. If you follow the 'cheat sheet' instructions here: https://github.com/MarlinFirmware/MarlinDocumentation/blob/master/_features/unified_bed_leveling.md I'll answer any questions you have.

You said I should increase my mesh size, would you recommend any number? 8x8? 10x10?

8 x 8 or 10 x 10 should be fine. I've used 10 x 10 on my 400mm x 400mm bed and that piece of glass is definitely not perfect. I don't think that will fix your problem. But when you do resolve your problem, a 4 x 4 mesh is not sufficient and is going to be yet another problem for you to fix.

I tried to find other threads reporting this same problem but I couldnt find. Would you mind providing me just one link so I can follow it up?

These are not the ones I was thinking of. But they were the easy ones to find. There are more but they take time to find.

UPDATE: Here is a current thread: #9529

Start here: #5898

and you can branch out to these:

#6862
#5616 #4612 #5437 #5890 #5804 #5666 #5694 #5727

[batata004]

Thanks my friend. I will take a time right now to read about UBL! The documentatino that you provided is cristal clear!

I am using arduino mega with ramps 1.4. Do you think arduino mega will have enought memory to hold 50kb of UBL (documentatino says it can use upt to 50kb)?

Also, I didnt understnad this thing you said:

"But when you do resolve your problem, a 4 x 4 mesh is not sufficient and is going to be yet another problem for you to fix"

If I load the mesh from 10x10 points from my epprom, why you said using 4x4 later will not work?

Thanks for the references links, I will read them all.

OBS: after reading a little bit I didnt understand the main difference of bilinear and UBL. Right at the top of the documentation it says UBL creates rectangular zones each one with its specific distance from the nozzle (height or Z). Isnt this the exactly same thing bilinear does? I mean, if bilinear probes 4x4, it should create 16 rectangles each one with it's especific height, right? So how will UBL improve this?

[batata004]

@Roxy-3D I asked my GF to flash my printer with a 10x10 mesh bilinear points. She said it took almost 7 minutes to probe it all. After that I asked her to take a picture of the first layer print and you can see the problem still remains. See: https://photos.app.goo.gl/hGI2KPS5eYCDqnNw1

If you take a look, the lines at the right are not compressed to the bed while the lines to the left are very well compressed with good adhesion. I cant understand why bilinear is not working well in a situation like this, my printer is really solid, nothing wrong with it. The aluminum plate is not flat (I know that) but I have no idea why bilinear is not doing anything to help in this case!

[batata004]

HEY! My GF had the great idea of rotating my alumium plate 180 degree. She rotated the plate so the left side now becomes right and vice-versa. Here is the resulst -> https://photos.app.goo.gl/twww6gXAZ2oJ2xD02

You can clearly see the exactly same problem remains! Filament is sticking very well at the left but poorly/no adhesion at the right! So the problem cleary relies on bilinear :(

[AnHardt]

my printer is really solid, nothing wrong with it.

This confidence is mostly unjustified when i see this problem. (Inability of any BL-system using a probe with y-offset to level along x-axis).
Are you aware of the x-sled rotation problem? The sled rotates around the x-axis when moved along X. That causes, depending on the levers, nozzle and probe are seeing different realities. Often this is caused by z-rods being not exactly perpendicular (and different), loose screws, lost or added washers, bend rods, not snuggy fitting case parts, dirth in the joints, z-rod mounts not printed together or in different orientation, ... .

Check it again.

[Roxy-3D]

If I load the mesh from 10x10 points from my epprom, why you said using 4x4 later will not work?

I didn't say it wouldn't work. I'm just guessing that is not enough resolution to get 100% adhesion across 100% of the bed. You may have a perfectly flat piece of glass. It may work for you. If I had to bet, I would say you would be better off with a 8x8 or 10x10 mesh. THAT will work on just about any bed surface.

OBS: after reading a little bit I didnt understand the main difference of bilinear and UBL. Right at the top of the documentation it says UBL creates rectangular zones each one with its specific distance from the nozzle (height or Z). Isnt this the exactly same thing bilinear does? I mean, if bilinear probes 4x4, it should create 16 rectangles each one with it's especific height, right? So how will UBL improve this?

The correction math is very similar. If the mesh is the same, both should produce very similar results if the nozzle is over the mesh. UBL does not try to correct the Z Height if you are off the mesh. So that is a slight difference in the math. But other than that, the math is similar.

UBL has built in features like Mesh Editing. And the G26 pattern was originally done for UBL but is now available for Bi-Linear. Bi-Linear is much smaller in size. But with an Atmega part, you have plenty of room for UBL.

[batata004]

@AnHardt I totally agree with what you said however, if any of the problems you said really happened, they should happen again when printing. I mean, if there is something loose (for example) it should produce the exactly same results when auto leveling and when printing since nothing changes: temperatures are the same, the sled is the same, the loose things are the same.

Also, if my printer was not solid I should get inconsistent results when printing my test object. But no, I have a very solid result every single time I print the test object.

@Roxy-3D since I know the BILINEAR is not working well and since I know it is causing the nozzle to be too high at the right side of my printer, is it possible to me to make marlin add some offset to the right side?

Also, is it possible to get bilinear ABL spit out the mesh offsets after G29?

[Roxy-3D]

since I know the BILINEAR is not working well and since I know it is causing the nozzle to be too high at the right side of my printer, is it possible to me to make marlin add some offset to the right side?

Yes. The source code is available to do what ever you want to do.

Also, is it possible to get bilinear ABL spit out the mesh offsets after G29?

M420 V

[batata004]

@Roxy-3D Ok, but do you know if bilinear offers a way to me compensate the lack of precision of the math behind this method? Can I add an offset to specific points of the grid so the calculation gets better? I think this could be an improvement to marlin, allowing users to add small offsets to some grid points? For example, if the user selects a grid of 3x3 he could also add offsets to an array like:

offsets_bilinear = [0,0,0,0,0,0,0,0,0];

The points from the left to the right could have some meaning like: the first row, then the second row...

UBL is overkill to my case and also I dont think arduino mega will work fine with it. I tried using BILINEAR MESH with 10x10 (100 points) and some weird problems started happening! For example, the temperature registered in the hotend would lag a lot, 3 or 4 seconds, it would register 230 celsius and 4 seconds later it would register 245 celsius! It took at least a couple minutes to temperature stabilize.

Clearly UBL will create a bigger problem since BILINEAR, which is supposed to run with much lower memory, is already causing problems like the lag in registering temperature of the hotend which caused the PID of the hotend to overshoot.

[Roxy-3D]

UBL is overkill to my case and also I dont think arduino mega will work fine with it.

I know for a fact UBL works fine with Atmeg-2560's. It was developed using an Atmega-2560 board paired with a RAMPS v1.4 board.

Clearly UBL will create a bigger problem since BILINEAR, which is supposed to run with much lower memory, is already causing problems like the lag in registering temperature of the hotend which caused the PID of the hotend to overshoot.

Do you have an Atmega-1280 or an Atmega-2560? Right now I'm working on the G26 code and I have lots of extra debug features turned on. Everything from M48 to Pins Debugging. It says I have 50KB of program memory free. And more importantly, I have 3200 bytes of RAM free with a 10 x 10 mesh.

If you have an Atmega-1280... You probably don't want to mess with UBL. Instead, you would use M421 to edit the mesh points and add (or subtract) an offset to them....

[batata004]

thanks my friend! I think I misused the word memory, I meant cpu cycles. The only thing that explains why using 10x10 grid made my arduino taking so long to report hotend temperature is that the 10x10 for some reason is consuming cpu cycles cause of some sort of math that keeps going on behind the scenes. My Atmega is 2560. Anyway I will try to use UBL as you suggested and see if I get better results on the right side of my printer!

[Roxy-3D]

One easy fix to get back a lot of CPU cycles is to switch your display from full graphics to a 20x4 character display. That significantly cuts down on the CPU cycles. You can also change how often the LCD screen is updated. You can make it very sluggish (like once every 1/2 second) and it will still work, but chew up less CPU cycles.

[AnHardt]

Even if everything is 'solid' the x-rotation can, will and does occur.
Please see #9529 (comment) to understand the problem.
Results of probing can be very consistent and repeatable but simply wrong. (systematic failure.)

[batata004]

@Roxy-3D thanks, I will decrease the LCD refresh rate for sure!

@AnHardt what exacty is "x-rotation" or "x-sled"? I cant run the animation you sent in my computer cause I cant download the openscad software. But if you could explain what it is cause I searched at google for both terms + 3d printer and nothing came up.

[AnHardt]

x-sled = x-carriage = the thing sliding left and right on the x-axis. The place where nozzle and probe are mounted. (In theory a sled is a bit more sliding than rolling as a carriage. But this is completely irrelevant here)

x-rotation = an effect where the x-carriage (including nozzle and probe) is rotating (changing its angle) around the x-axis while moving along the x-axis. Like a tread on a bolt, but only a few degree per meter. Usually but not exclusively caused by non-parallel x-rods.

Sorry for sometimes messing up English spelling. My German is supposed to be a bit better.
Sorry for finding effects not described elsewhere. May i earn a Nobel Award? :-)
Sorry for sometimes inventing words.
Sorry for chaining substantives. In German we always do so.
Sorry for not being able to download openScad. Try again. They may suffer from Windows update. :-)

[batata004]

@AnHardt wowowowowowo you got it!!!! I understood it perfectly! Indeed my carriage has a little rotation! Actually the rotation is not around the X axis, it is around the Y axis! I mean, the thing that has the probe and the nozzle runs horizontally from left to right in my X axis BUT the rotation/loose that I am seeing in this thing is around the Y axis!!

I will try fix that right now, I thing my bearings are a little weared cause they are those polymer bearings. I will fix that and tell you back!

Sorry for making you say so many sorries!

[GypsyRobot]

Hi guys, Just joining the conversation. Been having the same issue of "Left side too tight, right side loose" no matter what leveling system I am using. The best solution I've found is using UBL (5x5 matrix) and editing point by point with M421 command.

BUT with UBL, when I edit a point of the grid with M421, it seems like Marlin does not redo de math and my nozzle goes "wrongly" all the way to ne next point, then suddenly changes the hight. Any guess how to solve this?

Using:
Ramps 1.4 + Mega2560
Inductive sensor, no heated bed (tried also with servos)
Bed size 200x200 mm
Marlin 1.1.8

[thinkyhead]

Been having the same issue of "Left side too tight, right side loose" no matter what leveling system I am using.

This issue is typically caused by a twist in the X gantry leading to bad probe readings.

it seems like Marlin does not redo de math and my nozzle goes "wrongly" all the way to ne next point

Please test with the latest bugfix-1.1.x (and/or bugfix-2.0.x) branch to see where it stands. If the problem has been resolved then we can close this issue. If you still see the bad behavior we should investigate further.

[Roxy-3D]

If the problem is still there with the current bugfix, please post. It will also be helpful to have a photograph of the G26 mesh validation pattern on the bed of the printer. That will tell us a lot about what is going on and give us some ideas how to get things 'correct'.

[razerraz]

Just for my modest contribution : I've spend several hours trying to get ABL working on my anet A8. Every test I maded ended by some part of my bed lower than my probe was measuring. I've tried several sensors, touch's, inductive, test the accurency of them, check for all possible mechanical issue, z steppers sync, belts tension... Found nothing.
The only thing I've understood after stretching my head so long is that the part of the bed that cause this issue change with the probe positioning. In my case, with x offset at -22 and y offset at 42, the right back part of the bed probing is lower than espected, and with x offset at 60 and y offset at 0 the entire left part of the bed is probed lower.

I ended up tired trying to understand this mess, fixing the issue with a ugly but pragmatic trick : I choose the probe position where only one corner is affected, then every time I do a bed leveling I just turn down a little the screw for this corner, and I restore after it. Problem solved. I also change the safe home position on the opposite corner the problem is, to be sure that the reference 0 of the z axis do not change when I do the trick

This is a mechanical issue for sure. On the anet almost every part of the printer is moving more or less during printing. The way it is in static probe when the nozzle is far from the bed and only z is moving slowly is very different than when its printing with tension from the bed, speeds...

Hope its help

[github-actions]

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.