HELP: Bilinear bed leveling one side higherthan the other

[Zuru1]

Hi,

First of , good job on the firmware, it has come a long way since I started using it (about 2yrs ago.)

I have a prusa i3 clone 3D printer, which is running marlin v 1.1.8 and configured to use bilinear bed leveling. The issue is that no matter what I do, (level the bed, check and double the X axis, extruder, inductive sensor, rods etc.) I end up with the same results, unable to print due to part not sticking on bed on one side and smashed on the other side.

Here are two grids produced after adjusting the bed screws with on change in the results and are performed with the bed and hotend heated up to print temperatures:

Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3
Recv:  0 -0.071 -0.137 -0.228 -0.378
Recv:  1 -0.508 -0.881 -0.647 -0.418
Recv:  2 -0.662 -0.943 -0.565 -0.308
Recv:  3 -0.230 -0.204 -0.082 -0.096

Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3
Recv:  0 -0.092 -0.274 -0.357 -0.290
Recv:  1 -0.600 -0.999 -0.973 -0.437
Recv:  2 -0.692 -1.121 -1.025 -0.498
Recv:  3 -0.164 -0.429 -0.439 -0.375

Here are the configurations files with configuration used on the printer: Configuration_adv.zip

Any help or direction in solving this issue is greatly appreciated.

Thank you and happy printing

[Zuru1]

I gave another try to the ABL (bilinear) after changing the lead screw nuts to the ones that they came with instead of the anti-wabble ones. This what I got

Finally something to work on. I think I have to increase the size of the grid in order to get the validation pattern on the whole bed and start tuning the mesh. Of the grid I got to today, I still have about 1 mm-ish between the left and right side.

Q: Which grid is used when printing and using the bi-linear ABL? The one stored in EEPROM or the one done after G28, if you have G29 in the beginning of the gcode to be printed?

[Roxy-3D]

I think I have to increase the size of the grid in order to get the validation pattern on the whole bed and start tuning the mesh.

I think you are trying to say that you need to increase the X Bed Size. (and/or X_MIN_POS and X_MAX_POS). Also... You really should bump up your mesh resolution to 8 x 8 or so.

The reason is... You need to adjust a number of areas on the mesh. Especially the front right. But you are making good progress!

[Zuru1]

Aha now I get. But I can’t really do that since the probe is on the right side of the hotend. If I increase the x pos then the probe will be outside of the bed since it’s already 5 mm from the edge.

[Roxy-3D]

No... Not true... UBL will not probe off the bed. So you may end up with a row (or column) of mesh points that are not auto probed. You can fill those a number of ways. (Manually probe using the nozzle, fill with a fixed value, or...) You can see them by doing a G29 T after the G29 P1. You simply say G29 P3 to 'Smart fill' them with pretty reasonable values. Then when you do a G26, you will be able to see exactly how accurate all those mesh points are and you can quickly edit any area you are not happy with using a G29 P4 R

Oooops.... Sorry.... I saw the G26 pattern and was thinking you were using UBL. You are not, so just ignore all that....

[Zuru1]

No problem.

So in order to fill in the column that the G26 pattern didn't print on, I have to use UBL and there is no other way to do this when using bilinear ABL?

[Roxy-3D]

No! Bi-Linear and UBL will give very similar results if you have a well tuned mesh. I can't tell if that front right corner mesh point is too high or too low. But you aren't getting good adhesion there. If the nozzle is pressing too hard against the bed and that is why it looks bad, you can do a M421 I3 J0 Q.15 to give it a little more room.

[Zuru1]

I finally managed to get a good mesh and can now print on almost the whole bed. This is my current end result after editing the mesh and print a one layer of a square object

Many thanks to all of you for helping in resolving this issue. Even thou is not 100% perfect its better than were I started from and I'm happy with the progress. Now I need to set up the correct centre of my printer and go nuts on printing things.

Again thank you and happy printing

PS: This thread should be pinned in the troubleshooting or ABL section since it holds a lot of good information on troubleshooting other components and not only issues about ABL.

[Roxy-3D]

Good job!

Incidentally... Those waves or contours you see (especially on the right side of the picture) are probably not defects in your mesh point values. Those are very repeatable. If you print that one layer print again, almost for sure you will see the same thing.

I don't know for sure what is causing them. But I'm pretty sure it is not the bed leveling and the Z-Height adjustment. I think it is tied to how the Gerble code ramps up and down acceleration numbers. If you print a G26 pattern and leave it on the bed and then restart this print, you will see the patterns crossing mesh cell boundaries and not really be dependent on where the mesh points are located.

Or conversely... If you want to get more data... Leave the mesh and Z-Offset numbers alone. Just change the Extruders acceleration and max feed rate numbers. You probably are going to see the frequency of the pattern shift. This would be a good science experiment for somebody that wants to help improve things!!!

Can you post your current mesh? It would be interesting to see what parts of it changed and by how much!

[AllenMcAfee]

Hey all. I was struggling with this same problem with Bilinear for about a week - went through all the variables that have been described here, tore down machines, documented everything I could, dug through the code, and always came up with one side printing perfect, but another always too high.

Then I stepped back to see what angle I was missing, and found it in ENABLE_LEVELING_FADE_HEIGHT. I realized I had never handled the M420 Z in our Start GCODE, which I now assume tries to set ENABLE_LEVELING_FADE_HEIGHT to fully flatten out at the first layer. ABL, UBL, and Three Point have had no problems in testing on Robo printers, but Bilinear simply would not do what we wanted, until we disabled ENABLE_LEVELING_FADE_HEIGHT and tested again. Problem seems to be solved with that simple fix.

Our solution: either assign a value for M420 Z in your START GCODE, or disable the feature if you're not planning on using it. We've been testing without any issues after that.

Does anyone have a similar result? I noticed @Zuru1's Configuration.h file has it enabled.

[Zuru1]

@Roxy-3D Aha I thought that had to do with the z height adjustments at the different locations. When I get home I will post the mesh info.

@AllenMcAfee I have it disabled now, but for me that didn't solve my issue.

[Roxy-3D]

Aha I thought that had to do with the z height adjustments at the different locations. When I get home I will post the mesh info.

Yeah... I chased the artifact issue for a while. Once I proved it was dependent on feed rates and accelerations... I quit because nobody was complaining about it. But if you are interested in playing with it (and convincing yourself)... It is very helpful to print a G26 pattern and leave it on the bed. If you cut your acceleration numbers to 3/4 of what they currently are and do a print... You should see the artifacts spread further apart.

[Zuru1]

@Roxy-3D Ok, I will test that later. The strange thing is that, the artefacts are only on the top side and bottom is as smooth as the mirror. Is the solution to the issue with the artefacts to reduce the acceleration speeds?

[Roxy-3D]

Is the solution to the issue with the artefacts to reduce the acceleration speeds?

I'm not sure of the answer. I noticed the artifacts 3 or 4 years ago before any mesh based leveling system even existed. I am convinced it is not being caused by the mesh based leveling systems. With that said... I've seen them when using UBL also. So the artifacts don't seem to care about the bed leveling system in play.

Lastly.... If you deactivate the bed leveling system but use Z-BabyStepping to get the nozzle height correct where you currently see those artifacts... And do the print... Most of the print won't turn out. But I would be willing to bet the part of the bed where you set the nozzle height (using the Z-BabyStepping) will show the exact same pattern. That probably would be a valuable test to prove this is not bed leveling related.

I don't know the answer. But my guess is we are looking at an issue where the stepper motor movement requires different numbers of pulses for each motor and some times you end up in the tough position of giving an extra one or pulling out one for one of the motors to get them all to the right place at the right time.

[bcsteeve]

Curious about this artifact. Am I correct in saying it is machine/brand/style-independent?

[Roxy-3D]

It is my belief... I don't know this as a fact... I think any machine that is made with stepper motors that have distinct 'steps' can be made to have these types of artifacts. I think it is related to the fact we can't position the machine at a floating point position. We have to position each stepper motor at some integer step number. And if you pick the right direction, speed, acceleration, etc... You are going to see artifacts of different shapes form as the layer is printed.

It is my guess that slightly rotating the part and re-slicing it... You will see the artifacts shift in shape and position. (I don't know that for a fact. But if my theory above is true, this would be reasonable to expect.) It might be good to do this and see what happens. It might also be good to start a whole new thread because we would get more attention and contribution if the issue was not buried in an auto bed leveling thread.

[Zuru1]

Here is my grid info at the moment:

Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3
Recv:  0 -0.259 -0.543 -0.852 -1.547
Recv:  1 -0.346 -0.798 -1.055 -1.478
Recv:  2 -0.256 -0.751 -1.061 -1.438
Recv:  3 -0.214 -0.721 -0.889 -1.643

Recv: Subdivided with CATMULL ROM Leveling Grid:
Recv:         0        1        2        3        4        5        6        7        8        9
Recv:  0 -0.25900 -0.35274 -0.44648 -0.54300 -0.62985 -0.71948 -0.85200 -1.05507 -1.30104 -1.54700
Recv:  1 -0.29456 -0.41154 -0.52852 -0.63919 -0.72791 -0.81031 -0.92696 -1.10279 -1.31286 -1.52293
Recv:  2 -0.33011 -0.47033 -0.61056 -0.73537 -0.82596 -0.90115 -1.00193 -1.15050 -1.32468 -1.49885
Recv:  3 -0.34600 -0.50389 -0.66178 -0.79800 -0.89196 -0.96426 -1.05500 -1.18370 -1.33085 -1.47800
Recv:  4 -0.32733 -0.49375 -0.66017 -0.80407 -0.90671 -0.98683 -1.07819 -1.19578 -1.32461 -1.45344
Recv:  5 -0.28900 -0.45837 -0.62774 -0.77659 -0.88940 -0.98167 -1.07948 -1.19334 -1.31273 -1.43211
Recv:  6 -0.25600 -0.42785 -0.59970 -0.75100 -0.86556 -0.95956 -1.06100 -1.18170 -1.30985 -1.43800
Recv:  7 -0.23844 -0.41385 -0.58925 -0.73974 -0.84152 -0.91840 -1.01685 -1.15958 -1.32388 -1.48819
Recv:  8 -0.22622 -0.40470 -0.58318 -0.73037 -0.81097 -0.86027 -0.95293 -1.12825 -1.34692 -1.56559
Recv:  9 -0.21400 -0.39556 -0.57711 -0.72100 -0.78041 -0.80215 -0.88900 -1.09693 -1.36996 -1.64300

[ghost]

I thought I would share my experience on this issue.

This issue happened on my two anet a8 printers with steel frames. Anet a8 guts on a p3steel frame. Recently I had to change some fans on both machines and both started to present this issue.

One was higher on the left and the other was higher on the right.

After much research and troubleshooting my issue turned out to be shifting probes on both machines.

As my x axis traveled left to right during the probe sequence my probe wire was being pulled or pushed (depending on the location) during the travel move and was skewing the distance reading.

To remedy this I took the original model stl file I was using for the holder and modified it to allow a more solid structure as well as two spots along a riser to zip tie the probe and wire to stay at the same angle no matter what.

Since then my grids have been locked and both printers have proper first layer adhesion. My beds are mounted on solid screws, no springs and use nylocs to keep them from becoming loose during use.

I also use bilinear leveling on a 3x3 grid, z fade height set to 3mm and I generated the grid with the bed and extruder heaters on. I am using this probe LJ18A3-8-Z/BX 8mm Approach Sensor Inductive Proximity NPN NO Switch DC 6-36V https://www.amazon.com/dp/B008FZC8F2/ref=cm_sw_r_cp_apa_N.cLAbZZ10QSX on both machines.

The x axis may not be twisted for some but the probe may be shifting just enough. I would check to see if your probe is solidly mounted.

Just wanted to share.

[thinkyhead]

Thank you for the update! We will definitely add a note about these kinds of issues in the Troubleshooting section on the website.

[yoflo]

There have been a number of threads on this issue. So far... Nobody has found the cause or the way to avoid the problem. I've looked at the code and I have not seen anything that is obviously wrong. But with that said... I haven't added debug code to look at the mesh building at each step to see where the problem might be coming in.

In a few (4 or 5) weeks I'll probably get my "To Do" list whittled down to the point where I can help out on this problem. I have not been able to duplicate the problem. My two development machines do not show the problem. But for sure, the problem is real. It would be helpful if somebody that is seeing the problem can add some debug code and help us figure it out. (A machine where the problem happens is very helpful in finding what is causing it!!!!!)

If you can't (or don't want to) add debug code... It might make sense to switch to another bed leveling system for a few weeks until the issue is better understood and fixed.

I am also experiencing this issue with the left side of prints beeing too high, whilst everything else is perfectly fitted. I observe the issue on several printers. Is there any new knowledge on what the root cause might be?

[The-Synthax]

I am also experiencing this issue with the left side of prints beeing too high, whilst everything else is perfectly fitted. I observe the issue on several printers. Is there any new knowledge on what the root cause might be?

As in, the nozzle gets too low on the left side, and is too high on the right side? I've been experiencing this on 1.1.9 as well as the 1.1.x bugfix branch. It's totally wrecking my bed on the left side, not even sticking on the right side- making large prints impossible without manual leveling.

Edit: This might be a hardware issue, will report back after I rebuild this printer with a better frame.

[dagnabitboy]

I see this thread is still open, so I wanted to contribute my 2 cents: I've been following this thread and many others for some time. I installed a BLtouch on my CR-10S and although the readings from the probe are very repeatable, I end up with the left side of the bed too high and the right side too low. Also, the mesh value at the rear center of the bed seem to be off. Consistent, but off. When I print with the resulting mesh my result is poor. Squished on the left, lifting off the bed on the right. I spent considerable time evaluating my machine for x-gantry twist, gantry looseness, wires or bowden tube pulling, etc etc, but when I remove the probe and manually align using paper at the 4 corners I get beautiful test prints (single layer squares at strategic places on the bed). I then tried manual mesh bed leveling and the mesh values for each point are very consistent, but different and smaller values from the BLtouch readings. I realized the BLtouch uses a HALL Effect sensor (magnetic) and all the areas that the readings are in question are in very close proximity to the stepper motors. On the left side there are the z stepper and the extruder, and at the center rear is of course the y stepper. These seem to roughly correlate where the problem areas are. I can't prove it's a magnetic issue, but it sure looks like it to me. If I install another probe it will be a simple mechanical switch type. Using manual mesh leveling and getting perfect results certainly confirms the mesh algorithms are good. Anyway, I hope this helps!!

[ituri]

Highly interesting conversation, even though the issue is marked as solved!

I made similar observations on my Ender 3: The right side of my bed has a very consistent and mostly repeatable height measured by my bltouch, whereas the measurements from the left half always make my extruder go up way too high. I second @dagnabitboy's assumption that this is due to EMI (electromagnetic interferences). On the Ender 3 this could be from the Z-axis stepper motor, which is conveniently located in the vicinity of the part where proving produces weird results. Therefore I enabled all the features that try to circumvent these problems related to interferences:

#if ENABLED(PROBING_HEATERS_OFF)
  #define WAIT_FOR_BED_HEATER     // Wait for bed to heat back up between probes (to improve accuracy)
#endif
#define PROBING_FANS_OFF          // Turn fans off when probing
#define PROBING_STEPPERS_OFF      // Turn steppers off (unless needed to hold position) when probing
#define DELAY_BEFORE_PROBING 200  // (ms) To prevent vibrations from triggering piezo sensors

I have the feeling that this brought some minor improvements, but here's what really solved all the aforementioned bltouch issues for me. I use a bigger mesh and I probe each point 4 times:

#define MULTIPLE_PROBING 4
#define GRID_MAX_POINTS_X 5

As it says in the sourcecode, the default number of probes (2) only uses the second probe for the mesh. This means that if the second probe is useless, I end up having a useless mesh. Using more than 2 probes causes Marlin to average all the measurements, thereby flattening any useless measurements. Of course probing a 5x5 mesh with 4 probes for each of the 25 points takes a lot longer, but I can finally say that my bltouch works in a way that I expect it to.

[Streeter1981]

Hey all. I was struggling with this same problem with Bilinear for about a week - went through all the variables that have been described here, tore down machines, documented everything I could, dug through the code, and always came up with one side printing perfect, but another always too high.

Then I stepped back to see what angle I was missing, and found it in ENABLE_LEVELING_FADE_HEIGHT. I realized I had never handled the M420 Z in our Start GCODE, which I now assume tries to set ENABLE_LEVELING_FADE_HEIGHT to fully flatten out at the first layer. ABL, UBL, and Three Point have had no problems in testing on Robo printers, but Bilinear simply would not do what we wanted, until we disabled ENABLE_LEVELING_FADE_HEIGHT and tested again. Problem seems to be solved with that simple fix.

Our solution: either assign a value for M420 Z in your START GCODE, or disable the feature if you're not planning on using it. We've been testing without any issues after that.

Does anyone have a similar result? I noticed @Zuru1's Configuration.h file has it enabled.

OH MY GOOD GOD! I was wracking my brain going over everything over and over again, and no luck! Found your comment pretty far down in this thread, and that was it! Thank you SO much for sharing what fixed it for you -- worked for me too!

[Roxy-3D]

OH MY GOOD GOD! I was wracking my brain going over everything over and over again, and no luck! Found your comment pretty far down in this thread, and that was it! Thank you SO much for sharing what fixed it for you -- worked for me too!

If Bi-Linear is not respecting the fade height on the first layer.... We should fix that. And it should be almost trivial to do that. My guess is it will be a 1 line fix. Is anybody interested in finding what that one line should be?

[thinkyhead]

I don't see how the first layer could be any different. The "first layer height" is included in the fade factor. If your first layer is 0.2mm and you have set the fade to 5mm you should have a fade factor on that first layer of 0.96. It is trivial to move the fade code to a separate .cpp file and run a large set of numbers to confirm whether the maths are correct.

[thinkyhead]

Bilinear simply would not do what we wanted, until we disabled ENABLE_LEVELING_FADE_HEIGHT and tested again.

That is odd. When the fade height is set to 0 it is treated just like having the feature turned off. At least, last time I checked, it was.

[thinkyhead]

I see that UBL is setting the fade height to be 10.0 whenever its mesh is "reset." I'm not sure we want that behavior anymore, as I believe we decided to make the default 0.

  void unified_bed_leveling::reset() {
    const bool was_enabled = planner.leveling_active;
    set_bed_leveling_enabled(false);
    storage_slot = -1;
    #if ENABLED(ENABLE_LEVELING_FADE_HEIGHT)
      planner.set_z_fade_height(10.0);
    #endif

[thinkyhead]

Hmm, well I see it gets set to 10 by default in the EEPROM. Fade is a good thing, so I can see why we prefer to have it set as the default.

[thinkyhead]

On examination, it does seem best to remove that from ubl::reset. UBL calls that method on construction, which is fine. But the bed mesh is reset in G29 and other places where it might not be desirable to also set the Z fade value.

So far –apart from this interaction with UBL– I have not discovered why having the feature compiled-in but with the fade height set to 0 should be problematic. I'll keep poking around. But this kind of scavenger hunt is not very likely to find the solution. For this we need those who experience the issue to add some logging to Marlin and see if the data helps narrow down the cause.

@Streeter1981 — Were you experiencing the fade issue with Marlin 2.0 ?

[zigajamnik]

Hi,

I think I have the same problem with BLTouch v3 on my Ender 3 with 1.1.5 board. I dont know what to do, I've tried Creality Marling 1.1.6, then installed Teaching Tech's 1.1.x Bugfix and the problem remains. Lot of people mention X gantry and twisted axis, but I higly doubt this is the problem in my case. Been struggling with it for 3 months already and I just can't find solution. I have re-sassembled X axis, re-tightened both belts and checked Z axis, everything seems correct. Always the same result. I have also tried changing fade height from 0 – 10, still same problem.

[bobemoe]

I may have had the same issue on my Prusia i3 MK2 with a BL Touch using (bi)linear I was getting the same symptoms, consistently high on the left and low on the right, by about .4mm difference. I upgraded to Marlin 1.x-bugfix and now moved onto Marlin 2.x, re-did configuration.h from scratch, tried multiple probes, increased grid to 3x, levelling cold or heated, all having exactly the same issue.

I then changed over to UBL and it worked perfectly first go! Didn't even need to manually tweak the mesh or anything. Now printing full bed size no probs :) I made no hardware changes between using bilinear and UBL, didn't even move the printer.

[ituri]

Unfortunately, with the standard Ender 3 board I'm not able to compile a Marlin firmware image small enough to fit on the board. However, disabling ENABLE_LEVELING_FADE_HEIGHT has completely solved the aforementioned issues for me - even when using ABL.

[bunnitech]

This problem still occurs on the latest v2 bugfix. I don't see why this issue was closed. In my case the nozzle is too low on the front left and too high in the back right. This only occurs with UBL. Before activating UBL, I had MBL active and my bltouch 3.1 created a perfect mesh. M48 gives me 0.005 or less. In UBL mode it is consistently skewed by the same amount. Off by one error? Rounding error? Still digging into it, but if we close the issue without resolution, how can we work to resolve it?

[kursatu]

I am running into this issue as wel,, as of March 18,2020 with the latest bugfix 2 sources. The UBL mesh is a bit negative on one triangular half of the mesh and a bit positive on the other triangular half. It makes UBL unusable.

[randellhodges]

I am running into this issue as wel,, as of March 18,2020 with the latest bugfix 2 sources. The UBL mesh is a bit negative on one triangular half of the mesh and a bit positive on the other triangular half. It makes UBL unusable.

Might want to make a new issue. That being said, are you using octoprint and perhaps have the bed visualizer plugin? I'd be interested in seeing what the triangles look like. I have seen something odd myself but not sure if it's just me.

[Matej1006]

I have same problem and i start thinking that maybe ihave to much poitns set for measure i have 5x5 now i will try 3x3

[adminmat]

I have the same issue. Nozzle is higher on the right side consistently. This causes a line width difference of +/- 24% across my CR-10 300mm bed (45mm inset on left, 10mm on right)

In firmware I have: ENABLE_LEVELING_FADE_HEIGHT enabled RESTORE_LEVELING_AFTER_G28 enabled

My start G-Code has: G28 M420 S1 Z5 (if i replace this with G29 I get same issue)

My testing process has been: Heat bed and nozzle G28 G29 M500 Run print

Tried with and without OctoPrint.

Hope we can find a solution.

[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.