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

[Roxy-3D]

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.

[Zuru1]

Hi,

With debug code, do you mean the output from running G28 and G29 in debug mode with M111 S247? Or did you mean something else?

[Roxy-3D]

I'm not sure where the problem is. It is possible it is in the mesh generation logic. So, it maybe that putting verbose debug code there would help find it. It is also possible that the problem is in the interpolation of the nozzle's position between mesh points (and comes up with the wrong answer for the correction on one side of the bed versus the other).

If I was debugging it... I would try some simple things to help isolate where the problem is. I might try printing with a mesh set to all 0.000's. That should print identically to having no bed level correction active. I would also try using G26 to print a mesh validation pattern and use that to edit the mesh points such that the G26 pattern is perfect. And then compare that to the automatically generated mesh.

Doing those things would probably provide some good hints on where the problem is. And those things can be done without adding any debug code.

[Zuru1]

Can you guide or assist me in doing that?

[Festivejelly]

I was having the problem. Found my X axis was twisted, installed a Z brace so that I could straight it out. Made a HUGE difference.

[Zuru1]

@Festivejelly How did you go about it to detect the twistedeness in the rods? Can you post the link to the z brace? Also if you can post a picture of the on the solution, would be great.

Thank you.

[MarioStoilov]

I'm having this issue too. Whenever I get the grid and try to adjust accordingly, I get e completely different result, that often has nothing in common with the adjustments I've made

[Roxy-3D]

Have you done a G26 Mesh Validation Pattern? Seeing that will tell us a lot and give us ideas on how to proceed.

[MarioStoilov]

No, I haven't

I will try it in a moment. In the mean time, take a look at these 3 consecutive levels. They have been done one after another without any changes to the bed (just reran commands)

20:15:58.063 : Bilinear Leveling Grid:
20:15:58.063 : 0      1      2      3
20:15:58.094 : 0 -0.712 -0.498 -0.421 -0.163
20:15:58.094 : 1 -1.725 -1.681 -1.676 -1.677
20:15:58.094 : 2 -1.777 -1.658 -1.557 -1.466
20:15:58.094 : 3 -1.741 -1.529 -1.357 -1.191
20:15:58.094 : X:151.00 Y:189.00 Z:6.44 E:0.00 Count X:12080 Y:15044 Z:8192
20:16:26.721 : X:61.00 Y:107.00 Z:5.12 E:0.00 Count X:4880 Y:8517 Z:8192
20:17:37.319 : Bilinear Leveling Grid:
20:17:37.319 : 0      1      2      3
20:17:37.319 : 0 -0.398 -0.242 -0.219 -0.161
20:17:37.319 : 1 -0.613 -0.757 -0.737 -0.727
20:17:37.319 : 2 -1.026 -0.892 -0.780 -0.519
20:17:37.319 : 3 -0.990 -0.765 -0.584 -0.445
20:17:37.319 : X:151.00 Y:189.00 Z:5.67 E:0.00 Count X:12080 Y:15044 Z:8192
20:18:21.882 : X:61.00 Y:107.00 Z:5.12 E:0.00 Count X:4880 Y:8517 Z:8192
20:19:33.593 : Bilinear Leveling Grid:
20:19:33.593 : 0      1      2      3
20:19:33.593 : 0 -3.495 -3.519 -0.215 -0.152
20:19:33.593 : 1 -3.589 -3.523 -3.493 -3.469
20:19:33.593 : 2 -3.637 -3.496 -3.377 -3.261
20:19:33.593 : 3 -3.602 -3.369 -3.178 -2.988
20:19:33.593 : X:151.00 Y:189.00 Z:8.26 E:0.00 Count X:12080 Y:15044 Z:8192

The difference is just amazing...

[MarioStoilov]

I really don't know how to "read" the g26 print. And since I can't get a good photo of the whole thing, here's a video:

This is the grid

20:38:01.542 : 0 -0.423 -0.400 -0.263 -0.174
20:38:01.542 : 1 -1.036 -0.960 -0.942 -0.942
20:38:01.542 : 2 -1.094 -0.944 -0.828 -0.732
20:38:01.542 : 3 -1.074 -0.830 -0.647 -0.625
20:38:01.542 : X:151.00 Y:189.00 Z:5.76 E:0.00 Count X:12080 Y:15044 Z:8192
20:38:01.542 : G26 command started. Waiting for heater(s).

https://www.youtube.com/watch?v=4OyhOxukYA8

[Roxy-3D]

That G26 doesn't look too bad. There are a few places where the mesh points should be adjusted... But your mesh values are good enough to print. The way you 'Read' the validation pattern is this: You want the line to be a little bit squished into the bed. It should be a little bit 'flat' on the top surface because the nozzle is on top of it and moving. But you don't want the line squished so thin it has very little thickness. You can adjust the mesh points to make this happen. If you adjust a mesh point, you need very little change from the current values. Try shifting a mesh point by .05mm or .1mm and you will see the difference.

It is hard to tell which way to shift the values because I can't see the line very well in the video. But If you shift the upper right and corner up .05mm and then down .05mm you will see an improvement in one of those directions. (Do 2 more G26's and you will see that one of them 'fixes' the upper right hand corner.)

[MarioStoilov]

So, the Idea here is to manually fix the mesh from this current bilinear instance? I could do that, but if I have to do this before every print (since I have set all my slicers to do a g28 g29 command in the start), this will be tedious.

Is there another way to debug the probing itself? Since I do get some sketchy values in the consecutive probings

[Roxy-3D]

The real reason to do this is to figure out where the problem is. Is the problem in the mesh generation? Or is the problem during the actually printing when the mesh is being used to calculate correction. Right now, we don't know the answer.

Also... Once the mesh is finely tuned, it can be saved. It doesn't have to be generated prior to each print. If you get the mesh perfectly tuned (with respect to G26) it would be smart to save it. Then as part of your start up GCode (in your slicer) you should load the mesh and activate the bed leveling system.

Part of the motivation for developing the G26 Mesh Validation Pattern tool was the probes are not always 100% trust worthy. If an error creeps in... G26 can show where (and how bad) the error is so it can be corrected. Let's see if we can get your mesh perfectly tuned and saved.

Then we can continue and see if any errors show up during the print.

[MarioStoilov]

Alright, can you point me at where do I need to red up on this to get it (close to) perfect?

[Zuru1]

Tried the G26 validation and could only print on the half of the if divided into two triangles. I could only print on the left side (left top to back left and right top) section and not the other side of the bed even with such a grid

Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3
Recv:  0 -0.032 -0.203 -0.154 -0.001
Recv:  1 -0.552 -0.906 -0.738 -0.153
Recv:  2 -0.531 -0.964 -0.766 -0.231
Recv:  3 -0.072 -0.260 -0.231 -0.115

Maybe this problem can be tackled from two different sides, code and printer. If you can let me know which functions or objects handle the use of the mesh during a print, I can take look and see if I find anything there?

Right now I have triple checked every moving part and rods and still no change.

[Roxy-3D]

Another possibility is to turn on UBL and do a G29 P1 and see what that mesh looks like. It should be very similar if both mesh's are probed correctly.

The Z-Height correction is done in the Planner for Bi-Linear. You will be looking for code conditionally compiled into the image with ENABLED(AUTO_BED_LEVELING_BILINEAR)

  void Planner::apply_leveling(float &rx, float &ry, float &rz) {

    #if ENABLED(SKEW_CORRECTION)
      skew(rx, ry, rz);
    #endif

    if (!leveling_active) return;

    #if ABL_PLANAR

      float dx = rx - (X_TILT_FULCRUM),
            dy = ry - (Y_TILT_FULCRUM);

      apply_rotation_xyz(bed_level_matrix, dx, dy, rz);

      rx = dx + X_TILT_FULCRUM;
      ry = dy + Y_TILT_FULCRUM;

    #else

      #if ENABLED(ENABLE_LEVELING_FADE_HEIGHT)
        const float fade_scaling_factor = fade_scaling_factor_for_z(rz);
        if (!fade_scaling_factor) return;
      #elif HAS_MESH
        constexpr float fade_scaling_factor = 1.0;
      #endif

      #if ENABLED(AUTO_BED_LEVELING_BILINEAR)
        const float raw[XYZ] = { rx, ry, 0 };
      #endif

      rz += (
        #if ENABLED(AUTO_BED_LEVELING_UBL)
          ubl.get_z_correction(rx, ry) * fade_scaling_factor
        #elif ENABLED(MESH_BED_LEVELING)
          mbl.get_z(rx, ry
            #if ENABLED(ENABLE_LEVELING_FADE_HEIGHT)
              , fade_scaling_factor
            #endif
          )
        #elif ENABLED(AUTO_BED_LEVELING_BILINEAR)
          bilinear_z_offset(raw) * fade_scaling_factor
        #else
          0
        #endif
      );

    #endif
  }

[MarioStoilov]

I seem to have "worked around" my issue. Since I use bilinear and a probe, I increased my probes per point from 2 (rom which the slower one was taken) to 4 (average between them) and I'm getting more consistent results, which follow my manual observation (manually measured with some tools the offsets)

[lrpirlet]

Reacting on your results from 3 consecutives levels... I am guessing that you made a G28 in between each...

It that is the case, it would be nice to run M48 and display what is the Sigma value. I predict it would be quite big...

Remember that G28 should set the ZERO point (REFERENCE point) to the same physical spot... In practice, the actual spot will be located within a 6 Sigma windows centered over the "ideal" stop... (so says the statistics)... I if it does not matter too much for X and Y coordinate, it becomes quite important for the Z coordinate...

@Roxy-3D do use babystepping to "compensate" error on the ZERO reference, I do use a shim (paper between the hot-end and bed) after each G28, and reissue G28 till I am happy...

I really should write a multi-probe G28 over the Z coordinate and take the mean as the ZERO ref to prove that theory, but I do lack time... (Thanks for your last comment that seems to confirm my feeling)

[MarioStoilov]

It that is the case, it would be nice to run M48 and display what is the Sigma value. I predict it would be quite big...

I don't know how much is big, but this is it

Recv: Finished!
Recv: Mean: 0.002891 Min: 0.000 Max: 0.005 Range: 0.005
Recv: Standard Deviation: 0.001361

[lrpirlet]

This sigma is NOT big...

The range is .001361* 6 = .009785... One may see it as the maximum error between 2 layers this should NOT cause the second layer to squish the first nor prevent the liaison between the 2 layers to be too fragile...

Now, I am surprised with your mean... .002891...

The range should be centered around the mean and anyone probe should land between mean-3Sigma and mean+3Sigma... That resolves in between -.001192 and .006974... and that seems to say that it is VALID that the hot-end could have tried to go under the bed... are you sure that the probe do raise enough to disengage ???

Anyway, this is kind of academic and drag the attention away from your problem: one side NOT sticking to the bed and the other side squished...

Please keep in mind that you (try to) measure the distance between the hot end and the bed at various places... Understand that in a Prusa i3 the planes XY, YZ and ZX are ASSUMED to be perpendicular... Very often this is "just enough" the case... In fact, the x rods are bending as the extruder moves along X... The bed may be bumpy... The plane described by the hot-end moving in the XY plane at a given Z height is not quite parallel to the bed... etc... etc... Does that matter? In practice if you can keep the "errors" smaller than the tolerances of the melted plastic, everything is fine.

To reduce the error due the variable distance from the bed to the hot-end (Z height) function of the XY coordinate, various "bed levelling" (quite inexact naming BTW) exists.

I think UBL is the best approach IF YOU FOLLOW some best practices...

• Make sure you can print a test cube WITHOUT any leveling at all... (If that is NOT possible, take your machine apart and rebuild it :-) )... I also assume that the same probe is used to set the ZERO ref and to probe the mesh (I do not want to handle 2 different error generating systems, one -the probe- is enough).. In a few words, the bed MUST be correctly trammed... The calibrations such as displacement, speed, acceleration and jerk must be good enough to obtain a good looking cube in the bed center WITHOUT bed leveling (m420 S0)... This also implies that G1 Z0 makes the hot-end barely touching the center of the bed when ready to print... So why not decide to use the center of the bed to set the zero reference (G28 Z0)...

• When that is done, it is time to calibrate your UBL mesh... Do select an ODD square mesh in order to have a mesh point just under the ZERO reference... (I use a 9 by 9 map, the fun part is to accept that G29 will never be ZERO but is within -3sigma and +3Sigma from the ZERO ref)... So do G28 followed by G1 Z0 until your shim goes smoothly, this will give you a ZERO reference to built the mesh... DO NOT issue a G28 in the middle of UBL calibration or start over again (you do not want to shoot your zero reference)... Do what is needed to get a final mesh that you save in eeprom... Do save also an executable Gcode (I sent mine by email to me as a backup). That includes using G26 to verify and correct non sticky (or squished) spot

If you want to be picky, and if you are sure that both G28 Z and mesh center point are coincident, use UBL command to shift the mesh until that spot reads ZERO...

All you need now is to insure that the ZERO ref is always correct before you print... G28, G1 Z0 till I get a correct shim feeling... Then enable bed leveling and print... :-)

Well of course do get to learn about your printer reactions. Mine for example do need to be trammed every time I want to print... I print about every other week... I think that the ambiant temperature and humidity are responsible, so I heat the machine 20 minutes, let it cool down for 1 hour -time to eat-, quickly tram using G30 at each corner and adjust till it is less than .05 difference with any other corner...

Note that other proceed differently to get a correct ZERO ref, @Roxy-3D do use babystepping.

Of course, if I was to print as a living business, my approach would be different... I would have a nice looking office instead of the end of my garage, I would not need to dry my filament, I would not have to "negotiate" with the cat for the chair... etc... etc...

[Roxy-3D]

When that is done, it is time to calibrate your UBL mesh... Do select an ODD square mesh in order to have a mesh point just under the ZERO reference... (I use a 9 by 9 map, the fun part is to accept that G29 will never be ZERO but is within -3sigma and +3Sigma from the ZERO ref)...

Good point! But I do the opposite. I want the probe to be able to touch the glass even if there is a prior G26 pattern on the glass. I often times print right on top of a G26 pattern. (This is due to laziness... But sometimes it is helpful when I'm looking for artifacts in the print and want to know where the mesh points are just in case that is factoring into the print.)

[MarioStoilov]

Well:

1. As I said previously, increasing the number of probes per point seems to give me good results
2. I am not the person who opened the issue, I just said I have a similar problem.

But your responses are a good thing to read. I would refer to them if I have further (hope not) problems.

[Zuru1]

I will do an M48 and get you the numbers. Since all that I have tried, almost taken apart the whole printer and put it back together ended up with the same results, I will try UBL out. But moving on to something else without resolving the previous problem does seem odd, since the new solution might not solve the original problem.

[Roxy-3D]

But moving on to something else without resolving the previous problem does seem odd, since the new solution might not solve the original problem

Yeah. But one big difference is I fully understand UBL and how it hooks into the system. It is much easier for me to help you if that is the system you are having trouble with.

[houseofbugs]

I just wanted to chime in here. I have been seeing a lot of issues where one side is higher than the other with a few of my machines and with customer ones that use the ABL kits I make. The sensors are working in the 0.00X accuracy range and I am trying to figure out why its creating a "slope" like the OP described. If I find anything I will update here.

[Roxy-3D]

I have been seeing a lot of issues where one side is higher than the other with a few of my machines and with customer ones that use the ABL kits I make.

It might be helpful to ask them which bed leveling system they are seeing that on. There currently are 5 different bed leveling systems. If they are all seeing it on the same system, that is a valuable clue.

[houseofbugs]

@Roxy-3D I've been playing with the firmware and running tests.

Changed from single probe to 2, 3, and 4. No change in the one side being higher (right in my case, Ender 2, gantry is stiff as can be and level).

My probe is getting under 0.002mm accuracy in all spots on the bed WITH it heated. Probing heaters off is enabled.

I am probing in about 30mm on each side of the 160x150 bed. I turned on EXTRAPOLATE_BEYOND_GRID and that seemed to help a little but the issue is still present. Its about 0.1mm off from left to right with right being 0.1mm too high. I am running the 1.1.8 build right now.

[houseofbugs]

Checked the belts too and the result is still that the right side is higher. Really scratching my head with this one.

[Lord-Quake]

I opened this issue back in July 2017. I am still scratching my head as well. For reference: https://github.com/MarlinFirmware/Marlin/issues/7278 (Unfortunately someone closed my issue)

[Festivejelly]

I honestly think its a twisted X axis. I had the same problem and fixed it by using Z frame braces to "bend" the frame in such a way that when I put a level against the linear rods on the X they both show level.

On my CR-10 the bed levelling works flawlessly and the crappy readings I was getting from the sensor were a result of the heater, for which i've created a PR to fix.

So yeah I dont think this is a software bug its a mechanical issue.

[Lord-Quake]

@Festivejelly Could you post pictures or something to show what you mean by twisted X axis and Z frame braces?

[Festivejelly]

@Lord-Quake Sure thing, i'm at work right now but when I get home ill take a few pics of my setup and how I straightened it out. Which 3d printer do you have? I wonder if this problem happens more with linear rod systems. I also think the location of the probe has a massive impact on the accuracy.

[Lord-Quake]

@Festivejelly Here is my Thingiverse page: https://www.thingiverse.com/thing:2189694 (printer pictured)

[AnHardt]

// x_rotation.scad

// Animated demonstration for nozzle
// and probe seeing not the same height
// caused by rototion of the x-sled,
// around the x-axis,
// when moving in x-dirextion.
// 
// Load in OpenScad.
// Start animation with about 10 FPS
// and 50 steps.
// Observe from all sides, then take
// a look directly along the x-axis.
// See nozle (red) and probe (blue)
// not flying at the same height.
// Play with the next 3 values.

z_till = 10; // misalignment of the z-towers in °.
// when 0 machine is perfectly adjusted.

nozzle_dist = 20; // from center of rotaton in mm.
// When 0 the effect to the nozzles height is minimized.

probe_dist = 40; // from center of rotaton in mm.
// When same as nozzle_dist the probe will see the same height as the nozzle.
// probe_dist > nozzle_dist --> overcompensation
// probe_dist < nozzle_dist --> undercompensation

rod_len = 300;
rod_dia = 8;
x_rod_dist2 = 25;
cone_size = 10;

module rod(){
  translate([0,0,-rod_len/2])
  cylinder(d= rod_dia, h= rod_len);    
}

module z_rod(){
  rod();
}

module x_rod() {
  rotate([0,90,0]) 
  rod();    
};

module nozzle() {
  color("red")
  translate([0,nozzle_dist,0])
  cylinder(d1=0, d2=cone_size, h=cone_size);
}
module probe() {
  color("blue")
  translate([0,probe_dist,0])
  cylinder(d1 = 0, d2 = cone_size, h = cone_size);
}

rotate([-z_till,0,0]) translate([-rod_len/2,0,0]) z_rod();
rotate([z_till,0,0]) translate([+rod_len/2,0,0]) z_rod();

x_end_shift = x_rod_dist2 * tan(z_till);
echo("x_end_shift",x_end_shift);
x_rot = atan2(x_end_shift, rod_len/2);
echo("x_rot",x_rot);

rotate([0,0,x_rot]) translate([0,0,-x_rod_dist2]) x_rod();
rotate([0,0,-x_rot]) translate([0,0,+x_rod_dist2]) x_rod();

x = $t * rod_len - rod_len/2;
x_sled_rot = 2*z_till * $t - z_till; 
echo("x_sled_rot",x_sled_rot);
rotate([x_sled_rot,0,0]) translate([x,0,0]) nozzle();
rotate([x_sled_rot,0,0]) translate([x,0,0]) probe();

[Lord-Quake]

@AnHardt Great illustration. Thanks!

[Festivejelly]

Its not the code. If it was the code it would be happening for everyone but its not.

The CR-10 can also have a twisted x axis, any printer can. Thats why the Z braces were invented to help get around it. Its very easy to use a spirit level or even your phone with a spirit level app to compare both ends of the x axis to see if its twisted. They should be the same.

I've been using UBL exclusively. I used the same code profile for my wanhao and cr-10. My wanhao had the problem you're describing, so I looked at its z brace, and tightened it so that each side of the x axis are level to eachother. Probed bed again, test print, boom problem gone.

Its not the code, it cant be.

It could be you guys are using inaccurate sensors. Are you probing on a heated bed? That makes a big difference. Even with heaters disabled between probes the bed flexes quite a bit. (hence my PR to re heat between probes and wait)

Basically its a mechanical issue, could be twisted X, steppers not in sync, bent Z rod, etc.

Check your X axis to see if its twisted. Even if its only by 1mm itle make a difference.

[Festivejelly]

Just because im currently using UBL that means I couldnt have possibly tested the other methods right?

My CR-10 uses UBL as it has a larger bed my Wanhao i3 uses bi-linear. I gutted my CR-10 it now runs ramps.

See Scotts OpenScad demo. Basically when you twist the axis the nozzle can raise and lower depending on the orientation of the twist. Kinda like when you lean back on your chair your feet go into the air.

honestly, dont use bi linear for the CR-10, the bed is too big, Id highly suggest using UBL

[Festivejelly]

On my wanhao I use this: https://www.thingiverse.com/thing:921948

As you can see tightening or loosening each side will allow one to control the twist in the X axis.

A lot of frame braces merely add rigidity, this one allows you to square your printer, something thats super important on any printer.

[Lord-Quake]

OK, here is my test to see if my printer has a twisted x-axis. I can't see or measure any difference left and right.

[Roxy-3D]

I think it has to be the code. You think it can't be. Truth is, neither of us have enough data to say (but I think I've presented more empirically)

I believe there is a code issue. I don't know where it is yet. All of the bed leveling systems use the same lower level probing code. The problem you are talking about only appears in the Bi-Linear bed leveling system. My guesss (and I don't have facts to prove it) is there is an issue with the Bi-Linear code that is causing this.

[Roxy-3D]

Usually... when there is a problem with the Linear bed leveling, the nozzle is correcting in the wrong direction. Usually... that is caused by having the wrong 'handiness' of the coordinate system. If the origin is in the front left corner, the X axis should go to the right, the Y axis should go towards the back. And the Z axis should go up from the corner.

[Roxy-3D]

The other problem we have seen is the cables going to the extruder can pull up (or push down) more on one side of the X-Axis than the other. This can deflect the extruder a little more or less on one side than the other side. The strange thing is the Z-Probe does not accurately measure this deflection. Maybe because of the amount of time it spends doing the probe versus printing on the affected side of the axis.

That is why G26 is so helpful with the mesh based systems. That shows how the printer will behave during printing.

[Zuru1]

Here are my M48 number of all the four corners of the print bed with the be(d) and extruder heated up to print temperature.

Back-left
Recv: Mean: -0.281374 Min: -0.304 Max: -0.253 Range: 0.050
Recv: Standard Deviation: 0.014563

Back-right
Recv: Mean: -0.069497 Min: -0.083 Max: -0.048 Range: 0.034
Recv: Standard Deviation: 0.009379

Front-right
Recv: Mean: -0.023084 Min: -0.028 Max: -0.019 Range: 0.009
Recv: Standard Deviation: 0.002966

Front-left
Recv: Mean: -0.074642 Min: -0.088 Max: -0.051 Range: 0.037
Recv: Standard Deviation: 0.009076

Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3
Recv:  0 -0.067 -0.298 -0.328 -0.362
Recv:  1 -0.443 -0.781 -0.760 -0.484
Recv:  2 -0.520 -0.803 -0.715 -0.528
Recv:  3 -0.222 -0.342 -0.407 -0.445

[Roxy-3D]

The back left is noticeably worse than the other numbers.

Tried the G26 validation and could only print on the half of the if divided into two triangles. I could only print on the left side (left top to back left and right top) section and not the other side of the bed even with such a grid

Personally... I think your mesh should be larger than 4 x 4. But for now... To try to figure this problem out, 4 x 4 is very manageable.

Why could the pattern only print on the left side? Was the nozzle pressed against the bed too much on the right side? Or was it too high to get good adhesion? Lets manually adjust your mesh numbers on the right side and see if we can get better results.

[Zuru1]

@Lord-Quake I know that this might sound stupid, but I want to make sure that I got it right:

1. Lay an A4 paper on the bed in parallel with the bed edges
2. Move the extruder and mark the points where the extruder is when moved along lets say 3 points on the x-axis.
3. Take a ruler and align it with the z-axis rods
4. Measure the difference between the two lines

Is my understanding of your method correct?

[AnHardt]

@bcsteeve You should really read, run my (not scots) animation and play with the parameters to understand the mechanism. If you have that problem all leveling systems with a y-probe-offset will fail. All leveling systems using a probe compensate for what the probe sees. What the nozzle does can be considerable different.

Test: Disable leveling. Define 2 probable points with the same Y at the right (A) and the left (B) of the bed. Go to A with the nozzle. Make a paper-test. Adjust bed or right z axis. Go to B with the nozzle. Make a paper-test . Adjust that bed corner or the left z-axis. Repeat until both points have the same nozzle-bed distance. For this two points your bed is leveled now. Move the (deployed) probe to A. Put 2-3 coins on the bed at A. Make a paper-test at A by lowering Z with the "housing" of the switch/probe. Not the soft/invisible trigger point Remove the paper. Put the coins to B. Move the nozzle to B without changing Z.

Will the coins still fit? Is there now enough space for more than one sheet of paper?

If the probe housings distance to the bed is not the same - why? Fix that! If not unequal - software is likely broken.

[AnHardt]

A similar less common effect exists for Y.

Only probing systems where the nozzle is the probe are immune for this. (Glory good old manual mesh bed levelling)

[Festivejelly]

My bad AnHardt I quoted the wrong person, had 2 discussions open and didnt have enough coffee.

I experimented today on my wanhao i3 and I cant reproduce the bi linear issue, although its a small bed in comparison to the CR-10. I wonder if the issue is amplified the larger the bed is.

As previously mentioned my issue with one side being higher than the other went away when I squared my frame. I'll try bi linear on my CR-10 to see if I can re produce it there at least then I can generate some data to look at.

[houseofbugs]

Just to rule out the probe (even though M48 shows under 0.002mm across multiple places on the bed) I swapped it out. Same exact issue. I also angled my gantry 5mm left to right (right being 5mm lower) on X and SAME ISSUE.

This is really weird. I tried a 3x3, 4x4, and 5x5 grid. The end result is all the same. There is something weird with the ABL code. If it helps I don't recall this happening on 1.1.5 builds so maybe compare the 2 ABL files and see if anything changed? I am going to do that tonight.

[Festivejelly]

And this is bi-linear right? Ill do more testing on my wanhao