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.

Roxy-3D on 8 Feb 2018

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?

Zuru1 on 8 Feb 2018

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.

Roxy-3D on 8 Feb 2018

Can you guide or assist me in doing that?

Zuru1 on 8 Feb 2018

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.

Festivejelly on 9 Feb 2018

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

Zuru1 on 9 Feb 2018

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

MarioStoilov on 9 Feb 2018

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

Roxy-3D on 9 Feb 2018

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 on 9 Feb 2018

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

MarioStoilov on 9 Feb 2018

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

Roxy-3D on 9 Feb 2018

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

MarioStoilov on 9 Feb 2018

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.

Roxy-3D on 9 Feb 2018

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

MarioStoilov on 9 Feb 2018

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.

Zuru1 on 9 Feb 2018

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
  }

Roxy-3D on 9 Feb 2018

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)

MarioStoilov on 10 Feb 2018

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)

lrpirlet on 12 Feb 2018

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

MarioStoilov on 12 Feb 2018

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

lrpirlet on 12 Feb 2018

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

Roxy-3D on 12 Feb 2018

Well:

As I said previously, increasing the number of probes per point seems to give me good results
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.

MarioStoilov on 12 Feb 2018

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.

Zuru1 on 12 Feb 2018

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.

Roxy-3D on 12 Feb 2018

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.

houseofbugs on 13 Feb 2018

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.

Roxy-3D on 13 Feb 2018

@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 on 13 Feb 2018

2018-02-13 00 46 21

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

houseofbugs on 13 Feb 2018

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)

Lord-Quake on 13 Feb 2018

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.

Festivejelly on 13 Feb 2018

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

Lord-Quake on 13 Feb 2018

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

Festivejelly on 13 Feb 2018

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

Lord-Quake on 13 Feb 2018

// 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();

AnHardt on 13 Feb 2018

👍1

@AnHardt Great illustration. Thanks!

Lord-Quake on 13 Feb 2018

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 on 13 Feb 2018

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 13 Feb 2018

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.

Festivejelly on 13 Feb 2018

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.
x-axis_twist_measurement

Lord-Quake on 13 Feb 2018

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 on 13 Feb 2018

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 on 13 Feb 2018

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.

Roxy-3D on 13 Feb 2018

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.

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

Zuru1 on 13 Feb 2018

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.

Roxy-3D on 13 Feb 2018

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

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

Is my understanding of your method correct?

Zuru1 on 13 Feb 2018

@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 on 13 Feb 2018

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)

AnHardt on 13 Feb 2018

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.

Festivejelly on 14 Feb 2018

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.

2018-02-13 00 46 21

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.

houseofbugs on 14 Feb 2018

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

Festivejelly on 14 Feb 2018

👍1

Yes bi-linear. Trying to turn of ABL fade to see if that has any bearing on this. Also flashed to 1.1.5 and while it wasn't as drastic of a difference there was still the end result of right being higher than the left. This bed is very level and the bed sheet is on with 0 bubbles.

houseofbugs on 14 Feb 2018

I have an Anet A8 and have been fighting this exact same issue since I installed Marlin to enable ABL with a BLTouch. I have been having 1.1.4 since I started this and still have that version. No matter which system I switch to (linear, bilinear, etc) the nozzle is still too low on the left side and too high on the right.

shonsu02 on 14 Feb 2018

Interesting that it's happening with the BL Touch. I am using capacitive sensors here with repeat-ability under 0.002mm. Bed heated and everything, heaters off during probing.

ABL fade has no affect enabled or disabled. Segmented moves also has no effect. Number of probes has no effect.

houseofbugs on 14 Feb 2018

👍1

With ABL bilinear and DEBUG_LEVELING_FEATURE enabled, you can use G29 Q at any time to see how much compensation is being applied at the current XY position of the nozzle. Please give this a test with the bugfix-1.1.x branch.

Enable DEBUG_LEVELING_FEATURE and re-flash the firmware.
Do your usual G29 procedure and enable bed leveling.
Keep your mesh result handy and reference it while testing (M420 V).
Move the nozzle around (with host or G1) to see if the Z height is misbehaving.
Send M111 S247 to the machine to enable extra logging.
At left, middle, right, and various points use G29 Q to see how much Z is being adjusted.

You can also enable M114_DETAIL and then issue M114 D at various points. This will show extra information about the stepper positions in terms of steps.

This data is absolutely vital and essential for us to see what's going on.

(@AnHardt also makes some important points above.)

thinkyhead on 14 Feb 2018

If Marlin won't fit on your board with DEBUG_LEVELING_FEATURE enabled, you may use the branch at https://github.com/thinkyhead/Marlin/tree/bf1_leveling_details_test which makes G29 Q available without the need to enable DEBUG_LEVELING_FEATURE.

thinkyhead on 14 Feb 2018

The test I outlined above will only tell us whether the bilinear leveling code is doing the right thing at each point according to the recorded mesh.

To get a more meaningful result pertaining to your probe and the bed, you must enable PROBE_MANUALLY and compare the mesh that comes from that procedure to the mesh produced by FIX_MOUNTED_PROBE.

If the mesh that comes from PROBE_MANUALLY differs from the mesh produced by FIX_MOUNTED_PROBE it means that the probe is at some slight angle compared to the nozzle and carriage, and so physical adjustment of the probe, carriage, and/or gantry is needed.

thinkyhead on 14 Feb 2018

@AnHardt just did the test and its level at each point. This machine has the issue as well. Always tilted.

Right side:
2018-02-13 22 37 33
2018-02-13 22 37 36

Left Side:
2018-02-13 22 37 58
2018-02-13 22 38 01

houseofbugs on 14 Feb 2018

What can we conclude from your test? That the probe is at a consistent height, I suppose.

I believe there is a code issue. I don't know where it is yet.
If not unequal - software is likely broken.

I don't think this is yet a foregone conclusion. We need to see the probed mesh compared to the manual mesh, and we need to see the output of G29 Q.

Dozens of comments here with essentially useless data. No amount of theorizing will lead us any further.

We very much need the data I requested to narrow down the source of the error.

thinkyhead on 14 Feb 2018

@thinkyhead I will try to get the manual mesh this weekend. I've burned a lot of time on this already.

If someone else gets to it before me thank you in advance.

houseofbugs on 14 Feb 2018

@Zuru1

There are no stupid questions.....

Lay a piece of paper on the heat bed and fixate with tape so it can't move. It doesn't have to be parallel to the heat bed.
Take a ruler and align it with the z-axis rods (red arrows). Make sure you are not aligning with the threaded rods!
Carefully mark a line on the paper from the edge of the ruler.
Remove the ruler and make sure the paper stays fixated.
Carefully move the heat bed about 1mm or so to the rear. This is to make it easier to measure the 2 lines.
Now securely place a pencil or pen to a flat surface on the extruder.
Here comes the tricky part: Carefully move the extruder from one end of the bed to the other end while the pencil/pen is touching the paper. Make sure to only use force on the extruder x direction.
Now you should have two lines on the paper. Measure both ends and compare. You have a twisted x-axis if the measurements differ.

Lord-Quake on 14 Feb 2018

🎉1

Stupid question here. Lets say your bed is slightly tilted and you don't have springs (solid mounts). Do you want the X gantry level with the FRAME of the printer or the bed? I have dual Z on all machines so I can slightly skew the gantry level with the motors without affecting their movement.

I've always heard and done where you level the gantry with the printer frame and let ABL handle the bed tilt.

houseofbugs on 14 Feb 2018

@Roxy-3D

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.

The nozzle was at the right height on the left side while on the right side it was too high (over the bed instead on the bed).
I will first do a check of the X-axis using @Lord-Quake method and see what i have to work with.
One strange thing a saw yesterday when printing a test cube in the centre of the bed is that the right z-motor wasn't doing any adjustments while the left one did during print.

I find this strange since the motors are connected in series on the ramps which is using the TMC2100 drivers.

Zuru1 on 14 Feb 2018

@Zuru1 the motor issue is a machine problem, not firmware. I've replicated this issue on a single Z machine.

houseofbugs on 14 Feb 2018

@houseofbugs
I know that a motor issue may have nothing to do with the software.
I'm just stating my finds on the hunt to resolve this issue.
Maybe this could be a result of a bad coupler or something else.
But until I have done the check of the axis alignment and maybe swap out the couplers I will know more on the matter.

Zuru1 on 14 Feb 2018

I will run the tests stated above later but for now I just want to confirm I have this issue on 2 cr10s printers. Before finding this thread I spent 16 hours yesterday trying to troubleshoot the issue and have adjusted and aligned everything I can, including the x axis. Both printers are low on the left and high on the right, which by eye seems to be the same amount. I have tried both bilinear and linear with both 3 and 5 points.

airexes on 14 Feb 2018

@houseofbugs I am using fixed mounts for the bed, too and I level my X axis to the frame (AM8 aluminium extrusion or the both X axis). That makes sense for me because you don't want to get any mechanical tensions to the Z rods and carriages. The tilted bed should be compensated by the ABL system.

I am using this little helper: https://www.thingiverse.com/thing:2064012

ikarisan on 14 Feb 2018

@Lord-Quake s metod is ok for detecting the x-rotation. My test makes more visible the discrepancy between nozzle and probe and is applicable to the y-axis. You can't touch the bed with (for example) an inductive probe. But you can touch the stack of coins (what is supposed to have a constant height).

AnHardt on 14 Feb 2018

@bcsteeve
Go back and reread the instructions

Make a paper-test at A by lowering Z with the "housing" of the switch/probe. Not the soft/invisible trigger point.

I really can't add anything to that. We want to detect a mechanical problem - for that - a mechanical test. If we do not trust in the software probing/leveling system it's not a good idea to use it.
Different trigger distances on the right than on the left because of earth-rays and bed deformations caused by moons gravity are off my scope today. :-)

I agree. Doing the papertest needs some training. But once you got some experience it's simple, fast and reliable. You'll feel it.

AnHardt on 14 Feb 2018

with the "housing" of the switch/probe. Not the soft/invisible trigger point.

AnHardt on 14 Feb 2018

Paper on stack.

With the paper you have feeling.

AnHardt on 14 Feb 2018

Hi,

Today I was unable to do any diagnostics on the printer due to lack of time and hope to do it tomorrow.

Zuru1 on 14 Feb 2018

@bcsteeve
My test is about detecting if the Z_PROBE_OFFSET_FROM_EXTRUDER at the left is the same as on the right.
If you trust in the bed leveling systems it's already proved not to be the same. Because the levelling systems level the probe (they can't see the nozzle) and the nozzle has a different height at both sides.

If we don't trust the leveling systems we have to find a physical test.
Simplest and most direct is to level the bed for the nozzle and compare the probe-bed distance on both sides. How to do that exactly, is up to you, as long as you don't use the probing or levelling system we don't trust in. Because we can assume the probe/switch case - trigger point distance is constant we can measure the probe/switch housing - bed distance, what is much easier than to measure a invisible trigger point or to find where a mechanical switch actually triggers. If you use a wedge, a micrometer, calipers, the paper test or something else is up to you. You just have to find out if the Z_PROBE_OFFSET_FROM_EXTRUDER on both sides is the same or not. And more important - if not - why?

AnHardt on 15 Feb 2018

How is a value of 0.146 assigned from that?

Weighted average.
https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/Marlin/src/module/probe.cpp#L583-L584

AnHardt on 15 Feb 2018

HELP: Bilinear bed leveling one side higherthan the other

If you can't find the relation between having different Z_PROBE_OFFSET_FROM_EXTRUDER and the title i can't help you.

AnHardt on 15 Feb 2018

@bcsteeve SERIOUSLY!!! You need to try harder to not aggravate the contributors here.

Roxy-3D on 15 Feb 2018

Hey, you got it. I wasn't even here.

bcsteeve on 15 Feb 2018

😄1

Hi,
So from todays check up i found the following:

Using @Lord-Quake method i found that the right side is off by 0.05 mm compared to the left side.
Replaced the z couplers in hopes that might help, still no change

Here are my grids after coupler change with a heated bed and extruder

Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3
Recv:  0 -0.127 -0.279 -0.241 -0.017
Recv:  1 -0.640 -1.055 -0.794 -0.139
Recv:  2 -0.634 -1.085 -0.709 -0.143
Recv:  3 -0.117 -0.293 -0.173 -0.010

Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3
Recv:  0 -0.108 -0.255 -0.220 -0.025
Recv:  1 -0.626 -0.973 -0.750 -0.194
Recv:  2 -0.599 -1.022 -0.656 -0.168
Recv:  3 -0.107 -0.293 -0.167 -0.019

One question:
If the X-axis is leveled to the bed and measuring the distance (z-height) from the hotend to the bed on both sides (x=0 and x = max) differs, what does that mean?

Zuru1 on 15 Feb 2018

@Zuru1
Ok. 0.5/10mm in Y. How much difference in Z between nozzle and probe that is, is hard to guess. That depends on distances of nozzle and probe from the center of rotation. However.
Z_PROBE_OFFSET_FROM_EXTRUDER is not the same at the both sides of the bed. That difference has to be as small as possible. At least less than 1/2 a layer height, better only 1/4, ideally 0. Otherwise bed leveling with a probe can't work. (Bed leveling does not level the bed. It tries to keep the distance of the probe at a constant height. It has only one information about the position of the nozzle. Z_PROBE_OFFSET_FROM_EXTRUDER. That is supposed to be a constant. If that varies with xy-position the height of the nozzle will vary by exact that amount.)

You have to find the mechanical problem and to eliminate that.

There are workarounds.
If you have x-rotation a 0 Y_PROBE_OFFSET_FROM_EXTRUDER will not correct the rotation but will make it invisible because nozzle and probe have the same distance from the center of rotation. (same for y-rotation and X_PROBE_OFFSET_FROM_EXTRUDER. (If you have both it will become difficult.))
The other way is to use UBL an hand tune the mesh. (IMHO we always have one of these rotations, or a similar mechanical defect, when we have to manually adjust the UBL mesh..)

Replaced the z couplers in hopes that might help, still no change

How exactly, do you think, can that improve the squarenes off your printer?

One question:
If the X-axis is leveled to the bed and measuring the distance (z-height) from the hotend to the bed on both sides (x=0 and x = max) differs, what does that mean?

If the nozzle-bed distance is equal at both sides of the bed (is level) and the probe measures different height and you believe in this results, that means the Z_PROBE_OFFSET_FROM_EXTRUDER is not constant. (see above). Or the other way around. If you believe in the leveling system, different print height at the right and the left, indicates a mechanical problem what causes the Z_PROBE_OFFSET_FROM_EXTRUDER to be not the same everywhere.

I personally am trusting the leveling systems. (But I test and compare them on my machines every now and then. And every now and then there are problems with the one or the other system. Usually they disagree a lot then.)

If the bed is level and flat you sometimes can see a pattern (systematic error) in the grid/mesh poins and conclude from that to the reason. In your case i don't see anything. :-(

AnHardt on 16 Feb 2018

@AnHardt
I replaced the flexible couplers thinking that might have been the root of the problem, since the couplers flexing can cause the x axis to be un leveled.
But since that is checked, I will move on to the next part and see were I end at.

What I also found out is that, if I print on the left side of the bed the Z_PROBE_OFFSET_FROM_EXTRUDER needs to be about -0.65mm while on the right needs to be -1.3mm. So something is causing this difference between these sections.

In my current configuration I have the probe on the right side of the extruder and my X_PROBE_OFFSET_FROM_EXTRUDER is = 0, so my that could be reason.
Why I have it set up like this is due to that the when X is homed, the probe is already in position to do its first probe.

Zuru1 on 16 Feb 2018

@AnHardt That animation just made it all "click" in my head. Brilliant. Sure enough my one machine with that issue has a tilted X gantry extrusion. Amazing.

Animation here: https://content.timothyhoogland.com/files/ShareXUpload/2018-02-15_17-32-03.gif

houseofbugs on 16 Feb 2018

@Zuru1
Concentrate on potential parts/problems what could cause the x-rods to be not parallel.

@houseofbugs
Nice gif-animation. May i use that in combination with my scad-script?
I think for a deep understanding what goes on, you have to play with the parameters. But the gif is an excellent teaser to hopefully make curious enough to at least read the comments in the script.

AnHardt on 16 Feb 2018

👍1

To reiterate:

To get a more meaningful result pertaining to your probe and the bed, you must enable PROBE_MANUALLY and compare the mesh that comes from that procedure to the mesh produced by FIX_MOUNTED_PROBE.

If the mesh that comes from PROBE_MANUALLY differs from the mesh produced by FIX_MOUNTED_PROBE it means that the probe is at some slight angle compared to the nozzle and carriage, and so physical adjustment of the probe, carriage, and/or gantry is needed.

thinkyhead on 16 Feb 2018

@AnHardt
Well then, the only thing that I haven't check is the actual frame holding everything together.
I will do that on the weekend and take the printer apart and check how straight the frame is.

Zuru1 on 16 Feb 2018

@thinkyhead
I agree, but. :-)

PROBE_MANUALLY is only save when done with the nozzle (no xy-offsets!).
FIX_MOUNTED_PROBE is not the ideal word. There are fix mounted probes/switches around having no xy-offsets. Servo probes usually have a xy-offset, but you can build them to have not. Until now i have not seen a sled probe with no x-offset, but it's possible to build one. BLtouch always has offsets. Allen keys are rarely seen on cartesian machines, but i can't imagine how to build one without offsets.

DELTAs can have a similar effect, where the effector is tilt when both diagonal rods going to the same tower, don't have the same length. When the rods are horizontal the effector is turned around the vertical z-axis (doesn't really matter). If the rods are vertical the effector is turned around an horizontal axis going from the tower to the center (what matters if the probe has offset to that axis).

Scara machines can have a xy(angle) dependent tilt of the effector. For example, when there is a little play in the barings above the effector and one or more bores in the arms are not vertical.

AnHardt on 16 Feb 2018

An incomplete list of what to check for a i3 type machine when searching for position dependent x-sled/carriage/effector tilt/rotation:

Are frame parts cracked, distorted, rectangular, with straight clean edges (grate, particle)?
Do they have a tight fit?
Are they mounted correctly to each other?
Are there omitted or added washers?
Are the correct washers, nuts, bolts being used?
Are they tightened (too much)?
Do upper and lower z-smooth-rod-holders belong together at both sides? (the lower one may be at the stepper mount)
If printed - have they been printed at the same time using same material and same orientation from the same set of STLs?
Are the models for that ok?
Are z and x smooth-rods straight?
Do they have the same distance to the frame everywhere?
Do the z-sleds belong to the same set (see rod mounts)?
Are the z-bearings mounted correctly into the z-sleds?
Are the x-rods mounted correctly into the z-sleds?
Are there cracks in any part?
Is there any relevant wear on any of the parts? If - why?
Is belt tension ok, or is the structure deformed by too much?

Don't _believe_ in anything.
Be exact - maybe we are looking for a 1/10 mm of difference (depends on where).
Test, measure, look up, think!

AnHardt on 16 Feb 2018

Just updating here. I rebuilt my X gantry on the Ender 2 and the leveling is working correctly now. Going to to the same to my CR-10. This is definitely looking like a mechanical issue. I wish we could somehow set a tilt offset in the software if we know how far off its throwing off the readings. If we used XYZ skew correction would that stack with the ABL and compensate for that? I am going to play with it.

houseofbugs on 18 Feb 2018

🎉1

I fought with this for a week of pretty much full time work (yep, I got nothing productive done all week).

Best results always came with ABL disabled and the bed properly leveled. Any time I turned on ABL, I'd get this strange slant. If it is mechanical, then (in my case anyway), why am I able to print perfectly fine without ABL?

Honestly I don't know why I obsessed with this so much, considering I can print without ABL. I just wanted to justify my ABL purchase I guess. But this frustrating exercise all resolved itself when I simply disabled ABL and went back to good old fashioned mechanical leveling.

IF perfect mechanical performance is a requirement for ABL, then what is the purpose of ABL? And if performance is WORSE with ABL, well...

Finally, I would suggest we stop calling it ABL. Is that really what it is? Of course not. Something like VBF would make much more sense (Virtual bed flattening). "Automatic" isn't really the right term, and "leveling" is certainly misused.

bcsteeve on 18 Feb 2018

I did the same thing. I disabled ABL, leveled the bed manually, and it prints fine.

shonsu02 on 18 Feb 2018

If it is mechanical, then (in my case anyway), why am I able to print perfectly fine without ABL?

It's been explained very well above, but let me try to be succinct.

If the gantry is twisted, this may only introduce a small error at the nozzle, which is right down at the bed, but this will introduce a larger error in the probe result, because it is farther above the bed and aimed at a point away from the nozzle. If the gantry is twisted, the probe distance to the bed will vary as it moves left-right, while the nozzle's relative position is not greatly affected.

|\   When close up an angle translates to a small distance
| \
|  \ When farther away an angle translates to a larger distance

Here's what a probe does on a twisted gantry:

   /        |        \
  /         |         \
 /          |          \
far        near        far

If perfect mechanical performance is a requirement for ABL, then what is the purpose of ABL? And if performance is WORSE with ABL, well...

It is only worse when your probe situation is such that it produces varying measurements. Of course we cannot compensate for nonsensical values. The probe needs to point straight downward consistently.

Try using PROBE_MANUALLY and compare the mesh result, as I have _repeatedly suggested_. Apply the Scientific Method.

thinkyhead on 18 Feb 2018

👍2

@AnHardt: PROBE_MANUALLY is only save when done with the nozzle (no xy-offsets!).

That's what PROBE_MANUALLY requires. It's the paper-under-nozzle method.

@AnHardt: There are fix mounted probes/switches around having no xy-offsets.

The verbiage "FIX_MOUNTED" in our case refers to the fact that the probe doesn't need to be deployed. So, inductive probes, probes that use the nozzle itself, and so on.

@bcsteeve: I would suggest we stop calling it ABL. Is that really what it is? Of course not.

If G29 probes all the points one after the other without need for human interaction, we refer to the procedure as "automatic." This is in contrast to the other form of bed leveling that was introduced early into Marlin, entitled "Manual (Mesh) Bed Leveling," which requires the user to move the Z axis, test with a feeler gauge at each point, and issue a command or click a button to move on to the next point.

The PROBE_MANUALLY option was introduced more recently as a "type of probe" that can be used with ABL. And then Unified Bed Leveling is a mesh-based leveling system, but allows use of the planar matrix method to tilt the mesh data on a plane, and also includes the option to do manual probing of one or more points. It unifies the other forms in one glorious edifice.

@houseofbugs: If we used XYZ skew correction would that stack with the ABL and compensate for that?

Not bloody likely. We can't compensate for what is essentially a randomization of measurements.

@shonsu02: I did the same thing. I disabled ABL, leveled the bed manually, and it prints fine.

If you can print without any bed leveling compensation then of course you should skip it and allow the MCU to do less and run cooler.

thinkyhead on 18 Feb 2018

Hi,

I have now completed the disassemble and reassembled of my printer, in order to check the frame.
The frame had a little bend on the bottom right corner which I corrected as good as I could with a glass table and plywood piece.

G30 on all four corners:
Bed X: 0.00 Y: 0.00 Z: -0.03
Bed X: 160.00 Y: 0.00 Z: -0.04
Bed X: 0.00 Y: 190.00 Z: -0.02
Bed X: 160.00 Y: 190.00 Z: -0.02

Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3
Recv:  0 -0.074 -0.166 -0.131 -0.069
Recv:  1 -0.507 -0.775 -0.634 -0.201
Recv:  2 -0.484 -0.828 -0.626 -0.201
Recv:  3 +0.005 -0.194 -0.085 -0.038

Even after all of this check up and control, the issue still exists.
I also checked the suggested controls/check points in the thread, but still not getting any closer to resolving this.

This is kind of confusing since the nozzle is at the same height on both sides (left and right), it still prints in the air on the right side.
Tomorrow I will try UBL and see if that is the solution to my problem.

Thank you and happy printing

Zuru1 on 18 Feb 2018

Based on what @thinkyhead said recently, I wonder if it's the sensor mount that is just messing with everyone. If it's not in line with the nozzle, it's going to present itself as the twisted gantry maybe? Or a loose hotend that's allowing the nozzle to float? I'm not sure, just throwing it out there.

I went back to manually leveling since I have some stuff to get done.

noxin1 on 18 Feb 2018

Everyone!!! I have the fix!

One of my customers was messing with his machine and noticed the Y belt tension was too much. He loosened it a bit and it fixed the issue. I just tested this on my 2 machines having the issue and IT WORKED ON THE FIRST TRY.

Loosen your Y belt tension. The belt was pulling on the carriage during printing causing the bed to skew.

houseofbugs on 19 Feb 2018

Now explain how that would only affect printing with ANAL?

bcsteeve on 19 Feb 2018

Lol @ autocorrect. That should have been ABL, not ANAL

bcsteeve on 19 Feb 2018

@houseofbugs is that on an Anet A8?

shonsu02 on 19 Feb 2018

FYI:

Here are two grids bi-linear vs manual ABL

Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3
Recv:  0 -0.217 -0.320 -0.403 -0.290
Recv:  1 -0.531 -0.767 -0.744 -0.541
Recv:  2 -0.527 -0.758 -0.672 -0.556
Recv:  3 -0.021 -0.315 -0.354 -0.426

Send: G29 TRecv: State: On
Recv: Num X,Y: 4,4
Recv: Z offset: 0.00000
Recv: Measured points:
Recv:         0        1        2        3
Recv:  0 +0.57500 +0.40000 +0.17500 -0.12500
Recv:  1 +0.30000 +0.30000 +0.27500 -0.22500
Recv:  2 +0.30000 +0.30000 +0.07500 -0.25000
Recv:  3 +0.35000 +0.27500 +0.15000 -0.20000

How come there are so far apart from each other?

Zuru1 on 19 Feb 2018

I have always had trouble accurately doing manual probes with the nozzle touching the glass. It is very easy to have the nozzle touch the glass but not realize it and drive the nozzle harder into the glass (and get a lower Z value). It maybe that is happening here???

Roxy-3D on 19 Feb 2018

I will redo the manual probing tomorrrow and see if that helps.
How is it activated for so that it can be used while printing?

Zuru1 on 19 Feb 2018

Different people do things differently. But for me... If I can get the mesh 'reasonable' enough that G26 will print a pattern... That is what is important to me. The reason is, using that pattern I can edit any mesh point that needs to be adjusted. It doesn't have to be perfect as a result of the automatic probing. I just need it good enough the G26 command can run and then I use that to fine tune things.

Roxy-3D on 19 Feb 2018

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?

Zuru1 on 21 Feb 2018

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!

Roxy-3D on 21 Feb 2018

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.

Zuru1 on 21 Feb 2018

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

Roxy-3D on 21 Feb 2018

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?

Zuru1 on 21 Feb 2018

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.

Roxy-3D on 21 Feb 2018

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.

Zuru1 on 21 Feb 2018

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!

Roxy-3D on 22 Feb 2018

👍1

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.

AllenMcAfee on 22 Feb 2018

👍1

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

Zuru1 on 22 Feb 2018

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.

Roxy-3D on 22 Feb 2018

@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?

Zuru1 on 22 Feb 2018

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.

Roxy-3D on 22 Feb 2018

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

bcsteeve on 22 Feb 2018

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.

Roxy-3D on 22 Feb 2018

👍1

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

Zuru1 on 22 Feb 2018

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.

ghost on 26 Feb 2018

🎉3

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

thinkyhead on 27 Feb 2018

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?

yoflo on 6 Feb 2019

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.

VioSynthax on 9 Feb 2019

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!!

dagnabitboy on 27 Mar 2019

👍2

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:
```#define PROBING_HEATERS_OFF // Turn heaters off when probing

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.

ituri on 29 Apr 2019

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!

Streeter1981 on 26 Sep 2019

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?

Roxy-3D on 26 Sep 2019

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 on 26 Sep 2019

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 on 26 Sep 2019

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 on 26 Sep 2019

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 26 Sep 2019

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 ?

thinkyhead on 26 Sep 2019

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.

ender3

zigajamnik on 26 Sep 2019

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.

bobemoe on 12 Jan 2020

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.

ituri on 23 Jan 2020

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?

GuiltyPixel on 31 Jan 2020

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.

kursatu on 19 Mar 2020

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.

randellhodges on 19 Mar 2020

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

Matej1006 on 1 Apr 2020

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.

adminmat on 7 Jun 2020

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.

github-actions[bot] on 6 Aug 2020

Marlin: HELP: Bilinear bed leveling one side higherthan the other

Most helpful comment

All 138 comments

if ENABLED(PROBING_HEATERS_OFF)

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

define MULTIPLE_PROBING 4

define GRID_MAX_POINTS_X 5

Related issues