AUTO_BED_LEVELING_BILINEAR and BLTouch always off

[insanity67]

Hi! I´m on the latest bugfix release, and have a prusa i3 clone with genuine BLTouch. ABL kind off works, I can see the Z-axis move on larger X-axis moves, but I have the problem that the left side of the bed is always a bit too high, and the right a bit too low.

Any ways to debug this? Is this a software issue? Homing works perfect, bed and x-axis are parallel and I have manually leveled really close.

Thank you!

[ManuelMcLure]

That's a symptom of a twisted X axis - i.e. the distance between the probe and the bed vs the distance between the nozzle and the bed changes depending on the X position. It's a common problem on prusa-style printers and there's not much you can do about it except to try to eliminate the twist or just use the probe for a first estimation of the leveling mesh and use G26 and manually edit and save the mesh instead of probing every time.

[insanity67]

I have read nearly all issues about this in here, and have a hard time to believe that twisted axis are the only reason. I think too many of us having such problems.

If it is really a hardware problem, wouldnt it be good to "level" the bed in software to compensate that error? My genuine Prusa MK3 has the option to set 9 offset points around the bed to compensate ABL level errors. This offsets are stored in EEPROM, and calculated against the live ABL before each print.

[gloomyandy]

Which ABL configuration re you using? There are several different versions of bed leveling supported by Marlin. It may be that the one you have chosen to use can not cope with the type deformations you have in your bed. Some will only handle a simple tilt in the bed. You will probably get more useful answers if you provide your configuration files.

[insanity67]

Hi! I Dont know what information you all need to be sure, so I uploaded my config here:

configuration.h: https://pastebin.com/TuNwGr3j configuration_adv.h: https://pastebin.com/k4nr8RkP

Thanks for your support!

[insanity67]

It may be that the one you have chosen to use can not cope with the type deformations you have in your bed.

It is strange, with manual leveling before I installed the BLTouch printing was very good on the complete bed, so I assume that the bed cannot be that bad?!

[gloomyandy]

Are you sure you have the offsets of your probe defined correctly? If the probe is not where the system thinks it is then it can cause problems. Have you printed out the mesh to see how it looks? How does the mesh compared to what you can measure by moving the probe around to check the level of the bed?

I'm afraid I can't really help with the details of ABL bilinear as I've never used it. I use UBL and it has been working well for me.

[ManuelMcLure]

It is strange, with manual leveling before I installed the BLTouch printing was very good on the complete bed, so I assume that the bed cannot be that bad?!

It probably isn't. But a twisted X axis can make it appear so. I have the "twisted X axis" problem on my AM8 - if I put a square against the X axis rods on the right side they're correct, but if I measure on the other side the bottom rod is slightly further back (only about .2-.3 of a mm) than the top rail. Since my inductive sensor is in front of the nozzle, this means that the sensor is slightly closer to the bed (with respect to the nozzle) when the carriage is at the left than it is when the carriage is to the right so when the bed is measured it appears like the left side of the bed is higher than the right and the mesh gets skewed, and a G26 mesh validation pattern after probing the bed is worse than a validation pattern printed with no leveling.

I therefore decided to use the probe only for homing and am using UBL with a mesh that started as all 0s (G29 P0) and is manually tweaked with help from the G26 validation pattern.

[insanity67]

Are you sure you have the offsets of your probe defined correctly? If the probe is not where the system thinks it is then it can cause problems.

Yes, the probe is mounted behind the extruder. I measured as good as possible with a ruler.

Have you printed out the mesh to see how it looks?

Will try that as next step, and post a picture.

It probably isn't. But a twisted X axis can make it appear so.

Very busy weekdays, I will try to get is as good as possible on weekend. Even if this is not the problem, a not twisted axis is always good :)

I therefore decided to use the probe only for homing and am using UBL with a mesh that started as all 0s (G29 P0) and is manually tweaked with help from the G26 validation pattern.

Hmm.. I ordered the BLTouch to be able to switch between different types of beds without having to level each time. With this method it would be easier to remove the BLTouch and level by hand.

[ManuelMcLure]

Hmm.. I ordered the BLTouch to be able to switch between different types of beds without having to level each time. With this method it would be easier to remove the BLTouch and level by hand.

If you have the flash and EEPROM space available, you can create and store multiple UBL meshes (obe for each bed) and load the correct one before each print job.

[razerraz]

I have the same problem on my anet a8 (prusa style), and I'm also pretty sure about the twisted X axis being the cause. You can try a very simple experience : deploy your probe somewhere you're experiencing your issue, then get you z axis down until the probe detect the bed. Then, move your X/Y to place the nozzle where the probe was initialy. If your nozzle is not at the correct Z height, then you have confirmed X is twisted. Then, you can try to play with your X / Z axis angle to correct the twist, thing that I never be able to achieve with my anet. On my case, I have made a small python script that do the leveling, then apply correct offsets to the mesh points and save the result in EEPROM. Ask for it if you wish.

[insanity67]

I gave up at the moment, und use the BLTouch only as Z-Endswitch. So I can use different heatbeds with different heights. It would be cool if you could share your py scripts!

[Newtonn2]

I'm not convinced is a mechanical issue. I have been reading a lot about it and have checked my X axis and it is spot on (I have a P3Steel), but I still get the left hand side of the bed perfect but on the right hand side the nozzle is too high and eventually prints come unstuck from the bed. As insanity67, I would like to use other beds, including a magnetic bed. I got the BLTouch so I can do this without the need to worry about levelling the bed each time. Is there a way we could add some sort of compensation on the firmware so we get a good fist layer?

[razerraz]

Well you can believe what you want, never the less it's crystal clear when you look at the code, starting from line 605 : https://github.com/MarlinFirmware/Marlin/blob/1.1.x/Marlin/planner.cpp

If probing is good, no reason for the issue you have in there It can be related to z axis, both motors being out of sync, your frame moving, even your Y axis of you have an Y offset with nozzle/probe positions, not only X You're right to be pragmatic, creating a software compensation somewhere, but the firmware doesn't seems to me the best place to put it...

[Newtonn2]

Thank you for the reply. It is still not really crystal clear to me. There are many many people with the same issue and 95% of them seems to have the right side of the bed higher as well. If is a mechanical issue, would not that be odd? that most of them have the same issue in the same place? I have not Y offset for the sensor, only an X offset Not sure about motors out of sync... How do to test that? My frame is solid and there is not movement at all. How is the Y axis going to affect this? Could you explain that please?

Thank you for your help

[razerraz]

For me, right side is viewed lower that it is really, for good measure, and I have proven myself, with the method explained upper, that my X axis is squeezed. You can verify the sync of your Z motors making a line with a pen in the both Z couplers and check if they loose alignment Indeed, if you don't have offset between probe and nozzle on the Y axis, no reason it can interfere during probing In fact, I'm pretty sure that all issues people are facing are related to the probe position. Just try to move your probe position, and you will see another type of issue.

[Newtonn2]

I will do that and report back. Thank you again.

[Seref]

I got the same issue on my Anet A6 (Prusa Style) (with an ramps board). The left side is a bit to low, while the right side is too high.

I'm using an inductive 8mm sensor and the bilinear abl option (with a 4x4 grid instead of a 3x3 grid).

.	0	1	2	3
0	-0.096	-0.029	+0.182	+0.463
1	-0.169	-0.062	+0.102	+0.319
2	-0.225	-0.107	+0.063	+0.250
3	-0.243	-0.130	+0.011	+0.169

It doesn't matter how much I tweak it :( the bilinear bed leveling doesn't compensate it.

My probe is located like this:

#define X_PROBE_OFFSET_FROM_EXTRUDER 10     // X offset: -left  +right  [of the nozzle]
#define Y_PROBE_OFFSET_FROM_EXTRUDER -55    // Y offset: -front +behind [the nozzle]
#define Z_PROBE_OFFSET_FROM_EXTRUDER -2.6   // Z offset: -below +above  [the nozzle]

It's reaching both ends on the X-Axis and only one end on the Y-Axis, I also checked if the bed is flat (with a ruler).

[ManuelMcLure]

I have not Y offset for the sensor, only an X offset

Although this sort of thing is more noticeable if you have a Y offset, it will still happen even if you only have an X offset, because the nozzle/sensor are (usually) not exactly under the axis of rotation - instead they are in front of where the rotation occurs (on an i3 style machine with two parallel x-rods the axis of rotation would be on a line exactly half way between the two rods), because the amount of correction measured either leads (if the sensor is to the right of the nozzle) or lags (if the sensor is to the left) the actual nozzle position.

[razerraz]

@ManuelMcLure Something seems to me wrong with your rotation axis thing : if I understand right, the offset should be the same for all parts of the bed, ie independently of x axis position ? or this rotation axis is changing along the X course ? Because the problem here is that the probe offset change with the X position... @Seref What you describe is a little strange. You have more or less no offset on your X probe position, and a big one in the Y. Normally you should have problems on the Y axis, ie back versus front... You can try to find a probe position with a very small offset on one of the axis, to limit the causes, then apply software corrections after leveling by editing points manually or by a script. First you have to make the best manual leveling that you can on your bed, in order to have a clear vision of the offsets to apply. I have a script for that if your computer is capable of running something in python 3 (if you have a mac, forget it)

[Seref]

@razerraz Okay I updated the description to the table, I got this output and assummed that 0,0 is top left.

To the problem really happens more or less in the right-left axis. I tried to print a circle and the right the right side is always a bit too high which cuases that side not stick.

I dunno why but this problem just happened recently, it worked really well before. I don't save anything to EEPROM and before printing I'm always doing G28 and then G29 with the bilinear abl 4x4 Grid and 2 times probing.

Btw to the manual probing, I tried the Paper leveling (without Marlin) and adjusted the springs under the headbed until it was "perfect", that didn't improve a thing. After that I removed the springs which also didn't change anything.

No I don't use a Mac ^^ only Windows/Linux

[ManuelMcLure]

Something seems to me wrong with your rotation axis thing : if I understand right, the offset should be the same for all parts of the bed, ie independently of x axis position ? or this rotation axis is changing along the X course ? Because the problem here is that the probe offset change with the X position...

Imagine the following with the standard 2-rod X axis (this is what my AM8 has):

• On the left side of the bed the lower rod is slightly more towards the back of the printer than the upper rod (in my case this is about 0.5mm)
• On the right side of the bed, the upper and lower rods are exactly aligned (as they should be).
• The rods are around 38mm apart - this makes the amount of twist asin(0.5 / 38) = 0.75 degrees.

This results in a twisted X axis. The nozzle on most i3-style machines is a few cm in front of the plane of the rods - in my case around 30mm. This means that the nozzle will be around sin(0.75) * 30mm = 0.4mm closer to the bed on the left side than on the right, assuming the bed is actually perfectly flat.

Now in my case my sensor has a Y_PROBE_OFFSET_FROM_EXTRUDER of -40. So the probe is 40mm in front of the nozzle, or 70mm in front of the plane of the rods. Let's pretend my X_PROBE_OFFSET_FROM_EXTRUDER is 0. Then on the left side of the bed the sensor will be sin(0.75) * 70mm = 0.91mm closer to the bed - a difference of 0.5mm between the amount the nozzle changed vs the amount the sensor changed. So the bed leveling system thinks the bed is 0.5mm higher on the left side than the right side.

That said, I did the math and if there is no Y_PROBE_OFFSET_FROM_EXTRUDER the amount of difference between the desired correction and the measured correction is pretty close (within .001mm for a Y_PROBE_OFFSET_FROM_EXTRUDER of -50) to constant if the twist angle is small (since at small angles sin(X) approaches a line) so I was wrong in that assertion. But if there is a Y_PROBE_OFFSET_FROM_EXTRUDER then a twisted X axis will definitely show up as one side of the bed appearing to be higher than the other.

[xeddog]

I was just about ready to rip my capacitive sensor off of my CR-10S and go to purely manual levelling until I read this thread. It describes the problem that I have, which has just very recently started. Just about the time I downloaded the latest Marlin bugfix releases maybe two weeks ago. This problem is the same for me using the latest 1.1.x-bugfix, and the 2.0-bugfix. I have been using BiLinear levelling for a while now. But very recently, the left side of the bed is way too high, and the right side is way too low. When printing, there is a purge line at the beginning that is supposed to be printed along the left edge. The bed is so high that the nozzle is pushed into the bed and the extruder cannot push any filament out. On the right side, the nozzle is printing in air. As an experiment, I tried using Mesh levelling as well, and the problem seems to be identical.

[razerraz]

@ManuelMcLure Thanks for your explanation. I have also a Anet A8, but with acryclic frame. I have spend so much time trying to understand and fix autoleveling, list all possible things that can be causing the mess I had, but never think about this X rotation thing. I suppose I have the same on my machine, but since I decide to go with 0 Y offset it doesn't affect me. By the way, if I look at the bed orientation along Y axis movement, I can see by eyes the curve it takes, I suppose it's a most relevant issue, at least for me

My thoughts: @Seref and @xeddog point out the fact that everything was working until something change that is not software. It confirm my first though that Marlin have nothing to do with that, since it's a pure mechanical issue. Considering that, we are not at the right place to discuss that, it's not a marlin firmware issue When I made my script for software fixing, I was pretty sure that it was an ugly hack and cannot be useful for everyone but me. Seems that I was wrong, and that software correction can be a simple and pragmatic way to go. Then, I'm thinking about something more serious and adaptable, as a octoprint plugin for instance. Let me look over it and create a repo where we can discuss freely about all of that

[xeddog]

razerraz - I think you have misunderstood my reply. I am saying that everything was working until something change that WAS software, and only software.

[xeddog]

A side note - I went back and re-installed the official 1.1.8 release of Marlin and my abl seems to be working again. it is MUCH better than with the bugfix releases.

[Seref]

@razerraz It's a bit late from my side, I think I said it wrong. This didn't happened suddenly I only noticed it just now after trying to print something with a bigger surface.

I probably try out @xeddog 's method and go back to 1.1.8... the only bad thing is that I won't be able to use S-Bezier-Curves :(

[razerraz]

Well, despite @xeddog statement, I stay convinced that software cannot be related to that. I try to compare between bugfix version and official one to be sure, but too much commits there. Obviously my issues are mechanical and appears with all marlin versions, so of course I guess that's the same for every one. ABL is a very simple thing : you build a map with altitude values and just adjust Z with, nothing magic, easy code with no real place for bugs. I just think that mechanical behaviors are changing between tries, and then you also change marlin version and think this was the cause.

I have worked a little on my script, now it can correct offsets in both axes. I'm actually on vacation and forgot to sync it somewhere to continue this work, but it should be ready in a while for sharing.

Of course I'm interested about what will be going on after you downgrade since I want to know if my thoughts are wrong. So we keep in touch

[xeddog]

FWIW, I have downloaded a new version of bugfix-2.0.x and loaded it into my CR-10S and I am a happy man again. At least with the firmware. Now if I could just stop other things from breaking . . . (deep sigh).

[Seref]

okay I upgraded to 2.0 bugfix and it doesn't improve anything.

with the G29 command I get this now:

Bilinear Leveling Grid:

.	0	1	2	3
0	-0.253	-0.062	+0.259	+0.604
1	-0.337	-0.108	+0.176	+0.480
2	-0.373	-0.139	+0.134	+0.401
3	-0.395	-0.173	+0.078	+0.321

And my standard deviation is:

Mean: -0.000450 Min: -0.010 Max: 0.010 Range: 0.020
Standard Deviation: 0.006559
X:101.00 Y:166.00 Z:7.64 E:0.00 Count X:10100 Y:16600 Z:3055

I have no idea what causes this..

[xeddog]

That is quite a set of numbers. To me, those numbers look like generally the bed in has quite a tilt to it. The left front being very low, and the right rear being very high. I don't know how much deviation a sensor can compensate for, but you have 1mm to compensate across the whole width. Even though, I would expect a sensor to be able to accommodate that. If it were me, I would start be trying to lower the right rear corner by about 0.8mm, and the right front by about 0.5mm, and then run the G29 again. If you still have the springs, this should be easy. If you have solid mounts, try the opposite. Instead of lowering the right side, raise the left side. Aluminum foil can be your friend here. If you are still not able to get this working, then there is something else going on, and it sounds like firmware to me.

One quick question first. I didn't re-read everything that has been said, but after running your G29 command, are you saving your settings? That is done either from the Control menu on the control box, or running an M500 command from a terminal.

[Seref]

@xeddog thanks for answering! No I disabled (commented out) the save to EEPROM setting, I'll try the other things out, thanks!

[Seref]

@xeddog okay I tried it no luck :(

Bilinear Leveling Grid:

.	0	1	2	3
0	-0.028	-0.069	+0.038	+0.207
1	-0.036	-0.053	+0.004	+0.072
2	+0.015	-0.009	+0.032	+0.072
3	+0.082	+0.045	+0.078	+0.110

Finished!
Mean: -0.000250 Min: -0.006 Max: 0.003 Range: 0.008
Standard Deviation: 0.002740
X:101.00 Y:166.00 Z:5.70 E:0.00 Count X:10100 Y:16600 Z:2280

I really wish I knew what is wrong

[razerraz]

I have worked on my script for sharing :: https://framagit.org/razer/bed_leveling_fix

Feel free to give it a try

[Newtonn2]

After looking at this in length for a while now I discover that in my case it had nothing to do with a mechanical issue at all and would like to share what has solved my issue.

I did check and check the mechanics of my printer as it was suggested that it could be a mechanical issue, and this may be true in the case of some, but it was not in my case. It was not the firmware ether.

The issue in my case was solved with an adaptor to connect the Z steeper driver in Series with this adaptor: Link

Connecting the steppers in SERIES provides the full driver current for each motor and ensuring maximum torque at low z-axis speeds.You may need to increase the voltage of your stepper driver.

I had my Z steeper motors connected in PARALLEL, this halves the driver current to each motor.

I didn't change anything else, not mechanical or on the firmware, just put this adaptor and VOILA! problem solved.

I hope this helps someone straggling with the same issue.

[Its-my-right]

Hi,

to all of you interested in this issue, I solved this by reducing the number of points in the grid. I had a similar problem with bilinear and UBL and downed the number of points from 10 to 3 and that did the trick for UBL (I have not yet tested for bilinear). Maybe this has to do with the mesh/bilinear correction size in EEPROM, I don't know, but I'ms so glad it's working perfectly right now !

[github-actions[bot]]

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.