Marlin: G29 Issue

[aaronthomaswebster]

I have built my own CoreXY printer and I am running into issues with G29. It does not seem to be working... My printer is trying to compensate but seems to be too close to the bed in the front right and too far away in the back left. I could post all my firmware settings but I was hoping to ask for some advice first.

I am running Marlin 1.1.0-RCBugFix - 6

[psavva]

Please use the latest RCBugFix as many issues were resolved.
There is an option for Bilinear Bed Leveling, which I suggest you try.

[aaronthomaswebster]

I'm currently using Bilinear Bed Leveling... here is a snip from my configuration.h file

//===========================================================================
//============================ Auto Bed Leveling ============================
//===========================================================================
// @section bedlevel

/**
 * Select one form of Auto Bed Leveling below.
 *
 *  If you're also using the Probe for Z Homing, it's
 *  highly recommended to enable Z_SAFE_HOMING also!
 *
 * - 3POINT
 *   Probe 3 arbitrary points on the bed (that aren't collinear)
 *   You specify the XY coordinates of all 3 points.
 *   The result is a single tilted plane. Best for a flat bed.
 *
 * - LINEAR
 *   Probe several points in a grid.
 *   You specify the rectangle and the density of sample points.
 *   The result is a single tilted plane. Best for a flat bed.
 *
 * - BILINEAR
 *   Probe several points in a grid.
 *   You specify the rectangle and the density of sample points.
 *   The result is a mesh, best for large or uneven beds.
 */
//#define AUTO_BED_LEVELING_3POINT
//#define AUTO_BED_LEVELING_LINEAR
#define AUTO_BED_LEVELING_BILINEAR

/**
 * Enable detailed logging of G28, G29, M48, etc.
 * Turn on with the command 'M111 S32'.
 * NOTE: Requires a lot of PROGMEM!
 */
//#define DEBUG_LEVELING_FEATURE

#if ENABLED(AUTO_BED_LEVELING_LINEAR) || ENABLED(AUTO_BED_LEVELING_BILINEAR)

  // Set the number of grid points per dimension.
  #define ABL_GRID_POINTS_X 3
  #define ABL_GRID_POINTS_Y ABL_GRID_POINTS_X

  // Set the boundaries for probing (where the probe can reach).
  #define LEFT_PROBE_BED_POSITION 50
  #define RIGHT_PROBE_BED_POSITION 250
  #define FRONT_PROBE_BED_POSITION 50
  #define BACK_PROBE_BED_POSITION 225

  // The Z probe minimum outer margin (to validate G29 parameters).
  #define MIN_PROBE_EDGE 10

  // Probe along the Y axis, advancing X after each column
  //#define PROBE_Y_FIRST

  #if ENABLED(AUTO_BED_LEVELING_BILINEAR)
    // Gradually reduce leveling correction until a set height is reached,
    // at which point movement will be level to the machine's XY plane.
    // The height can be set with M420 Z<height>
    #define ENABLE_LEVELING_FADE_HEIGHT
  #endif

#elif ENABLED(AUTO_BED_LEVELING_3POINT)

  // 3 arbitrary points to probe.
  // A simple cross-product is used to estimate the plane of the bed.
  #define ABL_PROBE_PT_1_X 15
  #define ABL_PROBE_PT_1_Y 180  
  #define ABL_PROBE_PT_2_X 15
  #define ABL_PROBE_PT_2_Y 20
  #define ABL_PROBE_PT_3_X 170
  #define ABL_PROBE_PT_3_Y 20

#endif

/**
 * Commands to execute at the end of G29 probing.
 * Useful to retract or move the Z probe out of the way.
 */
//#define Z_PROBE_END_SCRIPT "G1 Z10 F12000\nG1 X15 Y330\nG1 Z0.5\nG1 Z10"


// @section homing

// The center of the bed is at (X=0, Y=0)
//#define BED_CENTER_AT_0_0

// Manually set the home position. Leave these undefined for automatic settings.
// For DELTA this is the top-center of the Cartesian print volume.
#define MANUAL_X_HOME_POS 0
#define MANUAL_Y_HOME_POS -15
#define MANUAL_Z_HOME_POS 0 // Distance between the nozzle to printbed after homing

// Use "Z Safe Homing" to avoid homing with a Z probe outside the bed area.
//
// With this feature enabled:
//
// - Allow Z homing only after X and Y homing AND stepper drivers still enabled.
// - If stepper drivers time out, it will need X and Y homing again before Z homing.
// - Move the Z probe (or nozzle) to a defined XY point before Z Homing when homing all axes (G28).
// - Prevent Z homing when the Z probe is outside bed area.
#define Z_SAFE_HOMING

#if ENABLED(Z_SAFE_HOMING)
  #define Z_SAFE_HOMING_X_POINT ((X_MIN_POS + X_MAX_POS) / 2)    // X point for Z homing when homing all axis (G28).
  #define Z_SAFE_HOMING_Y_POINT ((Y_MIN_POS + Y_MAX_POS) / 2)    // Y point for Z homing when homing all axis (G28).
#endif

// Homing speeds (mm/m)
#define HOMING_FEEDRATE_XY (50*60)

[FHeilmann]

(not relevant anymore since the comment was fixed)

[ghost]

define LEFT_PROBE_BED_POSITION 50

define RIGHT_PROBE_BED_POSITION 250

define FRONT_PROBE_BED_POSITION 50

define BACK_PROBE_BED_POSITION 225

This is your probe rectangle. If it's not getting to where you want, check/change these.

[ghost]

I did. I saw it just as I hit the post button....i deleted it and re-posted... You are quick. Lol

[aaronthomaswebster]

My printer does not have any issues reaching the probe positions, my bed is 300x300mm. My problem arises once I go to print. It is as if it over compensating for the tilt of my bed. It seems to be touching the build plate on one corner but floating high above it on the opposite corner.

[ghost]

Give the devel-ubl branch a try. It has a completely different way of bed leveling. It's called Unified Bed Leveling.

[Bob-the-Kuhn]

Right now the devel-ubl branch requires the use of an LCD display.

Please let us know the results if you try devel-ubl.

Did you try the latest RCBugFix?

If the latest RCBugFix didn't fix the problem then another option is to try a 5x5 grid. That's fixed this problem for a couple of people.

[aaronthomaswebster]

I was reading through the read-me for devel-ubl and it seems like there is a much longer process for leveling the bed. Am I going to need to run through this procedure every time I use my printer?

[Bob-the-Kuhn]

Just use M500 to save it to EEPROM and from there out it'll be restored from EEPROM on power up or when reset.

[Roxy-3D]

I was reading through the read-me for devel-ubl and it seems like there is a much longer process for leveling the bed. Am I going to need to run through this procedure every time I use my printer?

In an hour of time... Your bed (with a particular piece of glass) will be perfectly tuned. Much of that time is spent doing the initial probing and doing several Mesh Validation Prints. And the first time you are doing it... It is cool to watch.

But when you are done, your mesh is saved in EEPROM and if you choose to configure the system this way, you can have the correction applied at power up and/or reset. You don't need to do anything again. In reality... after a few weeks, you might notice you have a spot that is a little too high or low. You just spend 10 seconds to edit that spot and save the mesh. You should be good for another 2 or 3 weeks.

[thinkyhead]

It would be good to try and address / investigate the bug in the bed leveling code rather than diverting users to the UBL branch, especially as this appears to be consistent with 2 or 3 other issues reporting the same thing. We should determine whether it's a problem with the bed leveling code or something at a more general level that would also affect future-merged UBL.

Potentially related? #5616 #4612 #5437 #5890 #5804 #5666 #5694 #5727

[ghost]

I have had this issue with ABL in every version (except for devel-ubl) I've tried. That is why I'm still using MBL.

[aaronthomaswebster]

Is there anyway for me to get more information from G29 than what is provided through G29 V4? I want to try to troubleshoot this. I want to know if it is an issue with Marlin or with my hardware setup.

[james94jeans2]

I think I saw a DEBUG switch for G29. Also I'm not sure if you are allready doing it this way, but you don't need to start a print to test G29. Just do a G29 and the move the head with the host of your choice or the controller. You can then see the leveling applied to you movements and check the results using a piece of paper.
If you got a heated bed:
Have you got different results in the differences when bed is heated or not?

[aaronthomaswebster]

I hope that this is helpful... I'm not sure it means much to me but here is my G29 V4 output with DEBUG enabled.

Bed Height Topography:
+--- BACK --+
   |           |
L |    (+)    | R
E |           | I
F | (-) N (+) | G
T |           | H
   |    (-)    | T
   |           |
   O-- FRONT --+
 (0,0)
-1.72440 -1.36440 -0.92440 -0.53440 -0.19440
-1.35440 -0.93440 -0.52440 -0.05440 +0.45560
-0.89440 -0.43440 +0.04560 +0.55560 +1.06560
-0.56440 -0.12440 +0.37560 +1.00560 +1.63560
-0.18440 +0.31560 +0.87560 +1.43560 +2.04560

Corrected Bed Height vs. Bed Topology:
+0.42267 +0.29451 +0.24634 +0.14817 +0.00000
+0.32876 +0.26059 +0.18242 +0.16426 +0.18609
+0.32485 +0.29668 +0.28851 +0.31034 +0.33217
+0.19093 +0.14277 +0.15460 +0.29643 +0.43826
+0.10702 +0.11885 +0.19068 +0.26252 +0.38435

 Bed Level Correction Matrix:
+0.999936 +0.000000 +0.011353 
+0.000122 +0.999942 -0.010789 
-0.011352 +0.010789 +0.999877 

I also ran M48 V4 S and got the following:

Mean: -0.011000 Min: -0.040 Max: 0.010 Range: 0.050
Standard Deviation: 0.018138

Edit: Placed Code inside code block. @Tanoo Thanks for the help.

[ghost]

Can you edit that with the ``` ```around the snipplet? I will hold its format that way.

[oderwat]

@aaronthomaswebster You said you are using Bilinear but that output is showing a linear matrix. Did you switch your levelling method?

Some questions to all: I don't understand how the measured points can be -1.72 to +0.04 to +2.04 from one corner to the other while the "Corrected Bed Height vs. Bed Topology" shows +0.4 to +0.28 to +0.38. Can anybody explain what those values are supposed to represent?

[aaronthomaswebster]

@oderwat I just checked, and yes I did switch to Linear. here is the output i get on Bilinear setting.

 Bilinear Leveling Grid:
       0            1              2             3            4
0 -0.29      +0.21     +0.79      +1.41      +2.04
1 -0.57      -0.15      +0.36      +0.95      +1.61
2 -0.99      -0.51      -0.03       +0.48      +1.00
3 -1.33      -0.95      -0.51       -0.04       +0.46
4 -1.76      -1.41      -0.98       -0.62       -0.24

[aaronthomaswebster]

Is there a way to repeat G29 and test it against the created mesh to make sure it is really level?

[benlye]

I have the same problem - my nozzle is too close to the bed on the right side, and in the back right corner it is especially bad.

I'm using bi-linear with a 7x7 grid. Final output from G29 looks like this:
Recv: Bilinear Leveling Grid: Recv: 0 1 2 3 4 5 6 Recv: 0 +0.03 +0.07 +0.07 +0.04 +0.09 +0.15 +0.19 Recv: 1 -0.00 +0.02 +0.03 +0.03 +0.04 +0.07 +0.12 Recv: 2 -0.02 +0.02 +0.01 -0.00 -0.00 +0.03 +0.06 Recv: 3 -0.03 +0.02 -0.00 -0.00 -0.02 +0.05 +0.05 Recv: 4 +0.02 +0.05 +0.06 +0.05 +0.01 +0.04 +0.06 Recv: 5 +0.10 +0.13 +0.12 +0.10 +0.07 +0.10 +0.10 Recv: 6 +0.21 +0.21 +0.19 +0.15 +0.14 +0.13 +0.17

G29_V4_Output.txt

I have tested by running G28 then G29, then moving the nozzle to a selection of the measured points, moving to Z0 then using M114 to get the step count, which I divide by the number of steps/mm (399 on my printer). The actually stepper offset always matches the expected offset e.g. at X165 Y165, point 5,6 in the table, where the correction should be 0.13mm, M114 tells me I'm at 53 steps, which should be spot on. I also took a few samples between probed points and the steps look as I would expect.

Nevertheless, when actually printing, the right side is so near the bed the extruder motor grinds the filament because it can't extrude. The left side prints fine, and if I baby-step to try to fix the right the left will stop sticking to the bed.

Happy to try anything I can to help diagnose this further. I've already disabled Z fade height (although I never used it).

Ben

[gmdriscoll]

Hi, I have the same problem as benlye above.
Marlin-RC8
10" bed
Using BLTOUCH sensor.
Offset are x 40, y0, z -1.94
4x4 linear grid (same results with 4x4 bilinear)
0,0 position after G28 and G29, then G1 z0, hot end goes into bed
220,220 position after g28 and g29, then g1 z0 hot end is where I want it.
Also enabled/disabled z-fade height

<-Eqn coefficients: a: -0.00564137 b: -0.00329498 d: 3.66078925
<-Mean of sampled points: 2.50992202
<-
<-Bed Height Topography:
<-   +--- BACK --+
<-   |           |
<- L |    (+)    | R
<- E |           | I
<- F | (-) N (+) | G
<- T |           | H
<-   |    (-)    | T
<-   |           |
<-   O-- FRONT --+
<- (0,0)
<- -0.08492 -0.28617 -0.46617 -0.57242
<- +0.36758 +0.04258 -0.24867 -0.46367
<- +0.76133 +0.30883 -0.11367 -0.47242
<- +1.17258 +0.57883 -0.00117 -0.52242
<-
<-Corrected Bed Height vs. Bed Topology:
<- +0.02368 +0.17783 +0.35323 +0.60238
<- +0.25872 +0.28912 +0.35327 +0.49367
<- +0.43501 +0.33791 +0.27081 +0.26746
<- +0.62880 +0.39045 +0.16585 +0.00000
<-
<-Bed Level Correction Matrix:
<-+0.999984 +0.000000 -0.005641 
<--0.000019 +0.999995 -0.003295 
<-+0.005641 +0.003295 +0.999979 

Thanks,
-Greg

[benlye]

Just had time to do a little more testing. Thought I would start by trying to print just a snippet of gcode from a file - basically the skirt up until it reaches the back right, then run an M114. Something is definitely screwy.

The initial layer height is 0.12mm. At the end of the print code, when it runs M114, the nozzle position is X204.036, Y201.723 and the height should be 0.12 above the bed. The M114 output at the end is this:

Send: N74 M114*20
Recv: X:204.04 Y:201.72 Z:0.12 E:7.42 Count X:20129 Y:1612 Z:125

But, If I then issue G1 Z10 followed by G1 Z0.12 I get a different number of steps:

Send: G1 Z10
Recv: ok
Send: G1 Z0.12
Recv: ok
Send: M114
Recv: X:204.04 Y:201.72 Z:0.12 E:7.42 Count X:20363 Y:20376 Z:153
Recv: ok

The difference is only small - 28 steps = 0.07mm - but why is it there at all? Is there a problem applying ABL corrections during moves?

This is the gcode I ran:
ABL_Test_1.gcode.txt

Ben

[lrpirlet]

@benlye

Are you sure that your gcode stream include some sort of synchronization? Use m1 or m400 just before m114 to insure that no move are still in the queue... m114 will execute immediately while some move located before in the gcode stream are pending in the move queue...

Please do not conclude anything about position without synchronization...

[lrpirlet]

@benlye

Just for fun, re-run you gcode again... wait for prompt then re-issue m114 as the first command after your gcode script...

[benlye]

@lrpirlet Funnily enough, I was thinking exactly that on my way to work. I can't recall if I ran another M114 outside the gcode to validate the one in the gcode before I did the next move or not. I will definitely re-test, but it won't be possible until I get back from work later today.

In any case, the small discrepancy I saw in steps is not enough to make the difference I see in printing (which appears to be >0.1mm). I'm just trying to think of ways to try to diagnose what is going on. I'm happy to take any suggestions or other tests and checks to help try to figure out why I and others are seeing this behaviour.

[benlye]

@lrpirlet you were right - adding M400 to the code after the last move command takes away the discrepancy. Sorry for jumping to the wrong conclusion there.

Send: N73 M400*19
Recv: ok
Send: N74 M117 ETA 19 24 07 Day 28*24
Recv: ok
Send: N77 M114*23
Recv: X:204.04 Y:201.72 Z:0.12 E:7.42 Count X:20363 Y:20376 Z:112
Recv: ok
Send: N78 G1 Z3*94
Recv: ok
Send: N79 M400*25
Recv: ok
Send: N80 M114*31
Recv: X:204.04 Y:201.72 Z:3.00 E:7.42 Count X:20363 Y:20376 Z:1262
Recv: ok
Send: N81 G1 Z0.12*118
Recv: ok
Send: N82 M400*29
Recv: ok
Send: N83 M114*28
Recv: X:204.04 Y:201.72 Z:0.12 E:7.42 Count X:20363 Y:20376 Z:112

And this was when the print was over:

Recv: ok
Changing monitoring state from 'Printing' to 'Operational'
Send: M117 Print Done
Recv: ok
Send: M114
Recv: X:204.04 Y:201.72 Z:0.12 E:7.42 Count X:20363 Y:20376 Z:112
Recv: ok
Send: G0 Z10
Recv: ok
Send: G0 Z0.12
Recv: ok
Send: M114
Recv: X:204.04 Y:201.72 Z:0.12 E:7.42 Count X:20363 Y:20376 Z:112
Recv: ok

So I thought I was onto something, but I wasn't :-(

[Bob-the-Kuhn]

I’ve spent several days trying to get my head wrapped around this issue. I think I’ve finally made some progress.

I think the bilinear leveling is working as intended. My next post will have the algorithm as I understand it. I definitely want someone to try to verify this. To that end the next post has a couple of files with added print statements. They are modified versions of Marlin_main.cpp and planner.cpp – both from yesterday’s RCBugFix. Just drop them into your directory & re-compile.

The other thing is we need to do is get a handle on things like the following. That’s the subject of my third post.

• Desired accuracy
• Where the errors are occurring
• How big the errors are
• How good the Z sensor is.

I expect that we’ll find out that probing errors are the cause of some of the problems. I’ll put together something that does 5 probes at each point and returns the average. I just had a major head crash so it’ll be tomorrow or the next day before I can test it.

[Bob-the-Kuhn]

Bilinear leveling algorithm

G29 creates a grid matrix of the Z offsets at the probed points.

The planner calls the routine bilinear_z_offset to determine how much to offset the destination Z on all moves after G29 is run.

bilinear_z_offset does the following:

1. Computes the indices for the four points in the grid matrix that surround the destination X.Y.
2. Does a linear interpolation of the Z offset by doing the following:
   2a. Draws a line between the left points in the grid and then calculates the Z for the destination Y.
   2b. Draws a line between the right points in the grid and then calculates the Z for the destination Y.
   2c. Draws a line between the calculated left & right points and then calculates the Z for the destination X. This is the Z offset returned to the planner.

---

If you’re having offset issues within the probed area then either more points are needed or the probing isn’t accurate enough or I don't understand the software as well as I thought..

---

Outside the probed area the offset will NOT be as accurate as within.

• If you’re in one of the corners then it just uses the Z offset from that corner of the grid.
• Top or bottom side - applies just the Y linearization.
• Left or right side - applies just the X linearization.

---

I’d like someone to confirm my conclusions. I’ve attached a ZIP that has two files that were modified to print out the variables used by bilinear_z_offset and the Z offset that was calculated.

bilinear.zip

[Bob-the-Kuhn]

I’ve been trying to get my mind around how to investigate this issue for several days now. I’ve gotten three things out of it:

• A nasty headache
• Confidence that the M48 command is accurately reporting when the probe is triggering. I did this by strapping a digital dial indicator to my print head, adding a 2 second delay after it triggers, recording what the indicator is saying and then comparing the min/max of the indicator to the M48 results. In all cases the M48 results were within the indicator’s margin of error (+ - 0.01mm).
• An understanding of the bilinear leveling algorithm.

I’d like to limit this to the bilinear leveling system. That’s what most of us need and it limits the scope of the investigation.

The first step is to figure out what level of accuracy is needed from the bed leveling system. If we do a first layer of 0.25mm, is half of that (+ - 0.125mm) a reasonable accuracy? It would result in 0.125 – 0.375 thickness of the first layer. Quarter accuracy (+ - 0.0625mm) would give you 0.1875 – 0.3125

Next step is measuring the height of the nozzle above the bed. We’ve all used the paper method . My gut feel is that it’s only probably + - 0.1mm. Anyone have a better method?

After that we need to try to quantify the errors. To that end I propose:

• Include the type of printer (cartesian, coreXY or delta) and probe (servo, BLTouch, GEEETECH, BLTouch clone).
• Include your desired accuracy.
• Include the results of a M48 test. The accuracy of bed leveling can’t be any better than what M48 reports.
• Do a G29 V4 and Include the Bilinear Leveling Grid.

G29 V4
G29 Auto Bed Leveling
Bed X: 75.000 Y: 0.000 Z: -44.662
Bed X: 237.000 Y: 0.000 Z: -45.075
Bed X: 399.000 Y: 0.000 Z: -45.453
Bed X: 399.000 Y: 225.000 Z: -45.211
Bed X: 237.000 Y: 225.000 Z: -44.582
Bed X: 75.000 Y: 225.000 Z: -44.043
Bed X: 75.000 Y: 450.000 Z: -43.685
Bed X: 237.000 Y: 450.000 Z: -44.365
Bed X: 399.000 Y: 450.000 Z: 5.431
Bilinear Leveling Grid:
0     1     2
0 -44.66 -45.08 -45.45
1 -44.04 -44.58 -45.21
2 -43.69 -44.37 +5.43

• Move the nozzle to the points that were probed and measure the relative heights (M114 when the paper can just feel resistance from the nozzle when lowering the nozzle). These should be pretty close to each other. The probe points are the X & Y points in the G29 V4 printout.
• Measure some points INSIDE the probe area. My expectation is that the area inside the probe area should be fairly good. If these are significantly off then try increasing the number of grid points
• Measure some points OUTSIDE the probe area. Since these are extrapolated from the probe area data these should have the biggest errors.

It would be really nice if you were to include a summary near the top in addition to your data.

[benlye]

@Bob-the-Kuhn I tried the average-of-multiple probes approach previously (#5746) and found it didn't make a noticeable improvement - my probe (an inductive prox. sensor) is pretty accurate and the time the extra probes took didn't significantly increase the accuracy. You might implement something better than me though, so I'd be happy to have another go when you're ready.

I'll gather the full info you've asked for and report back. At a high level I can say that I see the problem both inside and outside the probed area. My printer is a cartesian Prusa i3 clone. With M48 I see a max 0.03mm variation. I'll compile your code and give it a try tonight.

After my tests yesterday, where I could see that the steppers were being moved to what looked like sensible offsets for the measured distance at the probed points I was coming to the conclusion that this must be a hardware mechanical/electrical issue - the software appears to be doing the right thing.

Then it occurred to me that I only looked at the positioning on the side where the nozzle was too near the bed, and for completeness I need to verify that the issue isn't actually on the too-high side. I think your test code will help validate that.

[benlye]

@Bob-the-Kuhn I tried to compile with your files but get a couple of errors. Looking in your Marlin_main.cpp it seems like you might have based that on a branch other than the current RCBugFix as it contains code I don't see in the main Marlin repository.

[Bob-the-Kuhn]

RATSSS!!!

Yes, it has code in it that's still in the PR state.

I'll post one without the custom code in it in 30-60 minutes.

[Bob-the-Kuhn]

Was "... /Marlin_main.cpp:3715: undefined reference to `ABL_grid_valid'" the only error?

If yes then try the attached file.
Marlin_main_corrected.zip

[aaronthomaswebster]

@Bob-the-Kuhn I tried to include the info you asked. Just let me know if I am missing anything.

I downloaded a fresh copy of Marlin-RCBugFix today.
I changed as little as possible to make sure that we can narrow down the problem.

the changes I made:

Configuation.h

//============================= Mechanical Settings 
#define COREXY
//============================== Endstop Settings
#define X_MIN_ENDSTOP_INVERTING true 
#define Y_MIN_ENDSTOP_INVERTING true 
#define Z_MIN_ENDSTOP_INVERTING true 
#define Z_MIN_PROBE_ENDSTOP_INVERTING true 

//============================== Movement Settings
#define DEFAULT_AXIS_STEPS_PER_UNIT   { 100, 100, 100, 625 }
#define DEFAULT_MAX_FEEDRATE          { 600, 600, 10, 600 }
#define DEFAULT_MAX_ACCELERATION      { 3000, 3000, 100, 10000 }


//============================= Z Probe Options
#define FIX_MOUNTED_PROBE

#define X_PROBE_OFFSET_FROM_EXTRUDER 30  
#define Y_PROBE_OFFSET_FROM_EXTRUDER -70  
#define Z_PROBE_OFFSET_FROM_EXTRUDER -3   

#define Z_MIN_PROBE_REPEATABILITY_TEST

#define X_MAX_POS 300
#define Y_MAX_POS 300
#define Z_MAX_POS 700

//============================ Auto Bed Leveling
#define AUTO_BED_LEVELING_BILINEAR

#define DEBUG_LEVELING_FEATURE
 #define ABL_GRID_MAX_POINTS_X 5
 #define LEFT_PROBE_BED_POSITION 50
 #define RIGHT_PROBE_BED_POSITION 250
 #define FRONT_PROBE_BED_POSITION 50
 #define BACK_PROBE_BED_POSITION 225
 // #define ENABLE_LEVELING_FADE_HEIGHT
#define MANUAL_Y_HOME_POS -15
#define Z_SAFE_HOMING
#define HOMING_FEEDRATE_Z  (40*60)

//============================= LCD and SD support
#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER


configuration_ADV.h

#define DISABLE_INACTIVE_Z false 

Printer Information:

Home built CoreXY ramps with LJ18A3-8-Z/BX Inductive sensor

Result of G29 V4

ok T:20.4 /0.0 B:19.6 /0.0 @:0 B@:0SENT: G29 V4G29 Auto Bed Leveling
Bed X: 50.000 Y: 50.000 Z: -0.860
Bed X: 100.000 Y: 50.000 Z: -0.130
Bed X: 150.000 Y: 50.000 Z: 0.610
Bed X: 200.000 Y: 50.000 Z: 1.370
Bed X: 250.000 Y: 50.000 Z: 2.160
Bed X: 250.000 Y: 93.000 Z: 1.780
Bed X: 200.000 Y: 93.000 Z: 1.020
Bed X: 150.000 Y: 93.000 Z: 0.270
Bed X: 100.000 Y: 93.000 Z: -0.360
Bed X: 50.000 Y: 93.000 Z: -0.990
Bed X: 50.000 Y: 136.000 Z: -1.200
Bed X: 100.000 Y: 136.000 Z: -0.580
Bed X: 150.000 Y: 136.000 Z: 0.050
Bed X: 200.000 Y: 136.000 Z: 0.680
Bed X: 250.000 Y: 136.000 Z: 1.320
Bed X: 250.000 Y: 179.000 Z: 0.770
Bed X: 200.000 Y: 179.000 Z: 0.210
Bed X: 150.000 Y: 179.000 Z: -0.310
Bed X: 100.000 Y: 179.000 Z: -0.850
Bed X: 50.000 Y: 179.000 Z: -1.390
Bed X: 50.000 Y: 222.000 Z: -1.690
Bed X: 100.000 Y: 222.000 Z: -1.170
Bed X: 150.000 Y: 222.000 Z: -0.690
Bed X: 200.000 Y: 222.000 Z: -0.290
Bed X: 250.000 Y: 222.000 Z: 0.060
Bilinear Leveling Grid:
      0     1     2     3     4
 0 -0.86 -0.13 +0.61 +1.37 +2.16
 1 -0.99 -0.36 +0.27 +1.02 +1.78
 2 -1.20 -0.58 +0.05 +0.68 +1.32
 3 -1.39 -0.85 -0.31 +0.21 +0.77
 4 -1.69 -1.17 -0.69 -0.29 +0.06

X:220.00 Y:292.00 Z:13.15 E:0.00 Count A:51200 B:-7200 Z:1300

Result of M48 P10 X220 Y292 S

Mean: 3.084000 Min: 3.060 Max: 3.110 Range: 0.050
Standard Deviation: 0.016248

M48 P10 X150 Y150 S

Mean: 2.900000 Min: 2.860 Max: 2.930 Range: 0.070
READ: Standard Deviation: 0.018974

M48 P10 X100 Y100 S

Mean: 2.555000 Min: 2.540 Max: 2.580 Range: 0.040
READ: Standard Deviation: 0.012845

M114

X:50.00 Y:50.00 Z:1.63 E:0.00 Count A:10000 B:0 Z:77
X:200.00 Y:93.00 Z:1.90 E:0.00 Count A:29300 B:10700 Z:292
X:100.00 Y:179.00 Z:1.50 E:0.00 Count A:27900 B:-7900 Z:65
 X:200.00 Y:222.00 Z:2.00 E:0.00 Count A:42200 B:-2200 Z:171

[Bob-the-Kuhn]

@aaronthomaswebster

From the M114 prints it looks like it's trying to compensate but doing a poor job.

The M48 results look like you should be seeing much better compensation.

Strange - the M48 results are in the 2.5 - 3.1 area but the G29 results are in the 0.06 - 0.21 area for nearly identical probing points. My understanding is that the values should be the same. The differences between points will definitely be the same.

Please try the following:

• Turn off bed leveling
• Go to three of the probing points - preferably ones that show a big difference in the G29 results.
• At each of these 1) do M48 and 2) record the Z when using the paper test to set the nozzle on the bed.
• Do 29 V4

All three methods should result in values where the differences from point a to point b, a - c and b-c should all be within the M48 range results.

[Roxy-3D]

M48 doesn't really care about the absolute Z numbers... It just does a standard deviation of the numbers. The mean is calculated and subtracted off of each sample number.

[aaronthomaswebster]

M48 P10 X250 Y93 S

Mean: 4.700000 Min: 4.690 Max: 4.720 Range: 0.030
Standard Deviation: 0.010000
Z 3.8

M48 P10 X200 Y179 S

Mean: 3.154000 Min: 3.140 Max: 3.180 Range: 0.040
Standard Deviation: 0.011136
Z 2.1

M48 P10 X100 Y222 S

Mean: 1.777000 Min: 1.740 Max: 1.810 Range: 0.070
Standard Deviation: 0.017916
Z 0

G29 V4

SENT: G29 V4
G29 Auto Bed Leveling
Bed X: 50.000 Y: 50.000 Z: -1.010
Bed X: 100.000 Y: 50.000 Z: -0.320
Bed X: 150.000 Y: 50.000 Z: 0.440
Bed X: 200.000 Y: 50.000 Z: 1.130
Bed X: 250.000 Y: 50.000 Z: 1.990
Bed X: 250.000 Y: 93.000 Z: 1.670
Bed X: 200.000 Y: 93.000 Z: 0.900
Bed X: 150.000 Y: 93.000 Z: 0.130
Bed X: 100.000 Y: 93.000 Z: -0.540
Bed X: 50.000 Y: 93.000 Z: -1.150
Bed X: 50.000 Y: 136.000 Z: -1.290
Bed X: 100.000 Y: 136.000 Z: -0.650
Bed X: 150.000 Y: 136.000 Z: -0.050
Bed X: 200.000 Y: 136.000 Z: 0.580
Bed X: 250.000 Y: 136.000 Z: 1.230
Bed X: 250.000 Y: 179.000 Z: 0.700
Bed X: 200.000 Y: 179.000 Z: 0.100
Bed X: 150.000 Y: 179.000 Z: -0.480
Bed X: 100.000 Y: 179.000 Z: -1.010
Bed X: 50.000 Y: 179.000 Z: -1.520
Bed X: 50.000 Y: 222.000 Z: -1.830
Bed X: 100.000 Y: 222.000 Z: -1.250
Bed X: 150.000 Y: 222.000 Z: -0.730
Bed X: 200.000 Y: 222.000 Z: -0.350
Bed X: 250.000 Y: 222.000 Z: 0.060
Bilinear Leveling Grid:
      0     1     2     3     4
 0 -1.01 -0.32 +0.44 +1.13 +1.99
 1 -1.15 -0.54 +0.13 +0.90 +1.67
 2 -1.29 -0.65 -0.05 +0.58 +1.23
 3 -1.52 -1.01 -0.48 +0.10 +0.70
 4 -1.83 -1.25 -0.73 -0.35 +0.06

[Bob-the-Kuhn]

By any chance could there be a typo for point X100 Y222 on the paper test?

If the real value is 0 the data implies one thing. If it's about 0.9 then it points in a different direction.

The deltas in Z values between the three points are what matters.

No matter what a test where one data point could sway things so dramatically needs to be re-run with more points. Could you do another test with the same three points plus throw in two more probed points.?

---

If it's about 0.9 then here's the analysis:

       point  location   M48    paper  G29          
A      X250 Y93   4.7    3.8    1.67        
B      X200 Y179  3.154  2.1    0.1         
C      X100 Y222  1.777  0.9    -1.25       

       delta A-B  1.546  1.7    1.57        
       delta A-C  2.923  2.9    2.92        
       delta B-C  1.377  1.2    1.35   

The deltas are all consistent which implies that the measurements are accurate. In that case I have absolutely no idea of what could be wrong.

---

If it's really 0 then:

point  location   M48    paper  G29         
A      X250 Y93   4.7    3.8    1.67        
B      X200 Y179  3.154  2.1    0.1         
C      X100 Y222  1.777  0      -1.25       

       delta A-B  1.546  1.7    1.57        
       delta A-C  2.923  3.8    2.92        
       delta B-C  1.377  2.1    1.35 

The M48 and G29 deltas are within the uncertainty reported by M48. That's what we expect.

The paper test deltas are very different than the M48/G29 differences.

Something is lying to us.

I don't think it's a mechanical problem with Z axis repeatability. If it were then I'd expect discrepancies in the M48/G29 deltas.

I have a hard time believing the paper test is that far off.

[aaronthomaswebster]

OK lets try this again. Thank you @Bob-the-Kuhn so much for the help. I hope that this data is not overkill but here we go.

M48 P10 X 72 Y 202 S

Mean: 1.787000 Min: 1.770 Max: 1.810 Range: 0.040
Standard Deviation: 0.011000
Z -0.9

M48 P10 X 72 Y 88 S

Mean: 2.342000 Min: 2.320 Max: 2.380 Range: 0.060
Standard Deviation: 0.017205
Z 0.7 

M48 P10 X 94 Y 69 S

Mean: 2.619000 Min: 2.580 Max: 2.660 Range: 0.080
Standard Deviation: 0.028089
Z 1.3

M48 P10 X 94 Y 145 S

Mean: 2.368000 Min: 2.360 Max: 2.380 Range: 0.020
Standard Deviation: 0.007483
z 0.8

M48 P10 X 116 Y 183 S

 Mean: 2.371000 Min: 2.360 Max: 2.390 Range: 0.030
Standard Deviation: 0.009434
Z 0.8

M48 P10 X 138 Y 88 S

Mean: 3.162000 Min: 3.130 Max: 3.180 Range: 0.050
Standard Deviation: 0.013266
Z 1.9

M48 P10 X 182 Y 107 S

Mean: 3.680000 Min: 3.650 Max: 3.690 Range: 0.040
Standard Deviation: 0.011832
Z 2.6

M48 P10 X 182 Y 164 S

Mean: 3.223000 Min: 3.200 Max: 3.240 Range: 0.040
Standard Deviation: 0.010050
Z 2

M48 P10 X 226 Y 126 S

Mean: 4.033999 Min: 4.010 Max: 4.060 Range: 0.050
Standard Deviation: 0.014283
Z 3

M48 P10 X 226 Y 202 S

Mean: 3.181000 Min: 3.170 Max: 3.200 Range: 0.030
Standard Deviation: 0.008307
Z 2.2

G29 V4

SENT: G29 V4
G29 Auto Bed Leveling
Bed X: 248.000 Y: 50.000 Z: 1.990
Bed X: 226.000 Y: 50.000 Z: 1.580
Bed X: 204.000 Y: 50.000 Z: 1.280
Bed X: 182.000 Y: 50.000 Z: 0.890
Bed X: 160.000 Y: 50.000 Z: 0.510
Bed X: 138.000 Y: 50.000 Z: 0.220
Bed X: 116.000 Y: 50.000 Z: -0.160
Bed X: 94.000 Y: 50.000 Z: -0.400
Bed X: 72.000 Y: 50.000 Z: -0.800
Bed X: 50.000 Y: 50.000 Z: -1.080
Bed X: 50.000 Y: 69.000 Z: -1.050
Bed X: 72.000 Y: 69.000 Z: -0.740
Bed X: 94.000 Y: 69.000 Z: -0.410
Bed X: 116.000 Y: 69.000 Z: -0.110
Bed X: 138.000 Y: 69.000 Z: 0.230
Bed X: 160.000 Y: 69.000 Z: 0.520
Bed X: 182.000 Y: 69.000 Z: 0.890
Bed X: 204.000 Y: 69.000 Z: 1.160
Bed X: 226.000 Y: 69.000 Z: 1.530
Bed X: 248.000 Y: 69.000 Z: 1.860
Bed X: 248.000 Y: 88.000 Z: 1.700
Bed X: 226.000 Y: 88.000 Z: 1.420
Bed X: 204.000 Y: 88.000 Z: 1.000
Bed X: 182.000 Y: 88.000 Z: 0.730
Bed X: 160.000 Y: 88.000 Z: 0.380
Bed X: 138.000 Y: 88.000 Z: 0.070
Bed X: 116.000 Y: 88.000 Z: -0.230
Bed X: 94.000 Y: 88.000 Z: -0.500
Bed X: 72.000 Y: 88.000 Z: -0.790
Bed X: 50.000 Y: 88.000 Z: -1.070
Bed X: 50.000 Y: 107.000 Z: -1.120
Bed X: 72.000 Y: 107.000 Z: -0.830
Bed X: 94.000 Y: 107.000 Z: -0.530
Bed X: 116.000 Y: 107.000 Z: -0.250
Bed X: 138.000 Y: 107.000 Z: 0.010
Bed X: 160.000 Y: 107.000 Z: 0.370
Bed X: 182.000 Y: 107.000 Z: 0.650
Bed X: 204.000 Y: 107.000 Z: 0.930
Bed X: 226.000 Y: 107.000 Z: 1.210
Bed X: 248.000 Y: 107.000 Z: 1.580
Bed X: 248.000 Y: 126.000 Z: 1.370
Bed X: 226.000 Y: 126.000 Z: 1.050
Bed X: 204.000 Y: 126.000 Z: 0.770
Bed X: 182.000 Y: 126.000 Z: 0.440
Bed X: 160.000 Y: 126.000 Z: 0.160
Bed X: 138.000 Y: 126.000 Z: -0.150
Bed X: 116.000 Y: 126.000 Z: -0.370
Bed X: 94.000 Y: 126.000 Z: -0.660
Bed X: 72.000 Y: 126.000 Z: -0.910
Bed X: 50.000 Y: 126.000 Z: -1.180
Bed X: 50.000 Y: 145.000 Z: -1.220
Bed X: 72.000 Y: 145.000 Z: -1.000
Bed X: 94.000 Y: 145.000 Z: -0.720
Bed X: 116.000 Y: 145.000 Z: -0.450
Bed X: 138.000 Y: 145.000 Z: -0.220
Bed X: 160.000 Y: 145.000 Z: 0.120
Bed X: 182.000 Y: 145.000 Z: 0.340
Bed X: 204.000 Y: 145.000 Z: 0.620
Bed X: 226.000 Y: 145.000 Z: 0.870
Bed X: 248.000 Y: 145.000 Z: 1.150
Bed X: 248.000 Y: 164.000 Z: 0.950
Bed X: 226.000 Y: 164.000 Z: 0.680
Bed X: 204.000 Y: 164.000 Z: 0.410
Bed X: 182.000 Y: 164.000 Z: 0.170
Bed X: 160.000 Y: 164.000 Z: -0.130
Bed X: 138.000 Y: 164.000 Z: -0.360
Bed X: 116.000 Y: 164.000 Z: -0.550
Bed X: 94.000 Y: 164.000 Z: -0.860
Bed X: 72.000 Y: 164.000 Z: -1.050
Bed X: 50.000 Y: 164.000 Z: -1.320
Bed X: 50.000 Y: 183.000 Z: -1.380
Bed X: 72.000 Y: 183.000 Z: -1.160
Bed X: 94.000 Y: 183.000 Z: -0.920
Bed X: 116.000 Y: 183.000 Z: -0.690
Bed X: 138.000 Y: 183.000 Z: -0.440
Bed X: 160.000 Y: 183.000 Z: -0.190
Bed X: 182.000 Y: 183.000 Z: 0.060
Bed X: 204.000 Y: 183.000 Z: 0.200
Bed X: 226.000 Y: 183.000 Z: 0.460
Bed X: 248.000 Y: 183.000 Z: 0.700
Bed X: 248.000 Y: 202.000 Z: 0.430
Bed X: 226.000 Y: 202.000 Z: 0.180
Bed X: 204.000 Y: 202.000 Z: 0.060
Bed X: 182.000 Y: 202.000 Z: -0.230
Bed X: 160.000 Y: 202.000 Z: -0.420
Bed X: 138.000 Y: 202.000 Z: -0.630
Bed X: 116.000 Y: 202.000 Z: -0.870
Bed X: 94.000 Y: 202.000 Z: -1.070
Bed X: 72.000 Y: 202.000 Z: -1.270
Bed X: 50.000 Y: 202.000 Z: -1.490
Bed X: 50.000 Y: 221.000 Z: -1.590
Bed X: 72.000 Y: 221.000 Z: -1.440
Bed X: 94.000 Y: 221.000 Z: -1.220
Bed X: 116.000 Y: 221.000 Z: -0.970
Bed X: 138.000 Y: 221.000 Z: -0.800
Bed X: 160.000 Y: 221.000 Z: -0.510
Bed X: 182.000 Y: 221.000 Z: -0.380
Bed X: 204.000 Y: 221.000 Z: -0.220
Bed X: 226.000 Y: 221.000 Z: 0.010
Bed X: 248.000 Y: 221.000 Z: 0.140
Bilinear Leveling Grid:
      0     1     2     3     4     5     6     7     8     9
 0 -1.08 -0.80 -0.40 -0.16 +0.22 +0.51 +0.89 +1.28 +1.58 +1.99
 1 -1.05 -0.74 -0.41 -0.11 +0.23 +0.52 +0.89 +1.16 +1.53 +1.86
 2 -1.07 -0.79 -0.50 -0.23 +0.07 +0.38 +0.73 +1.00 +1.42 +1.70
 3 -1.12 -0.83 -0.53 -0.25 +0.01 +0.37 +0.65 +0.93 +1.21 +1.58
 4 -1.18 -0.91 -0.66 -0.37 -0.15 +0.16 +0.44 +0.77 +1.05 +1.37
 5 -1.22 -1.00 -0.72 -0.45 -0.22 +0.12 +0.34 +0.62 +0.87 +1.15
 6 -1.32 -1.05 -0.86 -0.55 -0.36 -0.13 +0.17 +0.41 +0.68 +0.95
 7 -1.38 -1.16 -0.92 -0.69 -0.44 -0.19 +0.06 +0.20 +0.46 +0.70
 8 -1.49 -1.27 -1.07 -0.87 -0.63 -0.42 -0.23 +0.06 +0.18 +0.43
 9 -1.59 -1.44 -1.22 -0.97 -0.80 -0.51 -0.38 -0.22 +0.01 +0.14

[Bob-the-Kuhn]

Attached is my analysis.
analysis 2 MAR data.zip

The paper measurements show some really significant deviations from the sensor measurements. Even if we throw out points 1 and 10 there's enough nasties to scratch our heads.

@aaronthomaswebster - please do one more set of measurements. Please do the paper measurements on the same 10 points but this time have bed leveling active. If the paper measurements in your latest post are correct then you should find the head a large distance (greater then 0.5mm) from the bed at some locations.

[oderwat]

BTW... you should use G29 V4 T (maybe also without the V4 using V2 or no V at all). T should print the Data for all scanned points in a matrix similar to the Leveling Grid. That way you do not have such long reports but still the single scan point results. If you compile with Linear you can also do G29 P7 T to scan 7x7 or G29 P10 T .. with bilinear the P parameter is not supported (yet and afaik) because the matrix is hardcoded. This could be changed for example by rewriting the code to reserve a bigger matrix and use lower values or by rewriting it to allocated it on the fly.

[oderwat]

Related: http://www.maui-3d.com/cgi-bin/plotG29 .. to visualise the results. I removed the output of the "+" signs in our Anet Port of Marlin, such that one can feed the results directly to the website.

[Bob-the-Kuhn]

I like that plot.

I couldn't get it to work with anything other than a 7x7 matrix.

[aaronthomaswebster]

Same here @Bob-the-Kuhn I'm working now but will run those tests you suggested. here is part of the grid from last night http://www.maui-3d.com/cgi-bin/plotG29?plotG29ID=10129

[oderwat]

Yeah. Sadly it just supports the 7x7 matrix. I forgot to mention that. I always wanted to ask the creator to add other matrix and a more forgiving parser.

[Bob-the-Kuhn]

Here's the 9x9 plot using Excel's surface plot.

The only nasty is you have save the data as a text file and then open it in Excel as a delimited file.

I see 3D rotatable PDFs. Anyone know of any easy (no cost) way of doing that?

[elliotboney]

I was going nuts in R and Matlab trying to do this so thank god for this thread! We need maui-3d.com to take GET arguments so we can tweak the firmware to output a URL after G29 is run!

[Bob-the-Kuhn]

I've been playing with the numbers & it looks like the paper measurements have a semi-decent agreement with the G29 data on the interior 6 points. If I apply the relative offsets from those points to the paper measurements then it predicts that, at point 1, the nozzle will be above the bed by 1.1 - 1.5 mm more than the other points.

[Bob-the-Kuhn]

I finally repaired my Geeetech 3D Touch probe and was able to verify that the bilinear auto-level software is working as designed.

I was able to:

• Verify the Z offsets used by the planner match the grid at the probed points.
• Verify the change in counts for the Z axis, when moving from probed point to probed point, matched (within + - 1 count) the difference in the grid between the points.
• Verify that the corners outside the probed areas had a Z compensation that matched the offset in the corresponding corner in the grid.
• Verify that areas outside the probed area that weren't in a corner behaved as expected. On my machine that is the left side and the rear. On the left side there was compensation when moving in the Y direction but not when moving in the X direction. On the rear there was compensation when moving in the X direction but not when moving in the Y direction.
• Verify several points within the grid (not at probe points) were compensated properly.

[aaronthomaswebster]

Ok, You guys have been so helpful and I think I am going to try to redesign my printer a little bit. As you can see above in my configuration file my z probe is a pretty good distance from my hot end, I'm going to redesign the mount for my probe and see if I can get more consistent results.

[benlye]

@Bob-the-Kuhn I'm not massively surprised - you seem to be at the same point I got to with this - for all intents and purposes the software seems to be doing the right thing.

Nonetheless, this issue affects multiple people, so something is still up. If we can conclude that the software is working, I guess we then need to look at our hardware.

The only other question I had was whether somehow the printer isn't capable of calculating and applying the Z-offset compensation quickly enough in a printing situation, which is why our non-printing tests conclude that everything is fine, but prints don't come out as expected. I'm new to this, but from looking at the code it seems that all of this happens in the planner, and the z-offset compensation gets applied to the moves as each g-code line is processed. I can't see any reason why it would, but I wonder if (for example) print speed would have an effect? Is there anything else different in a printing situation?

@aaronthomaswebster I'm interested in how you get on. One of the things I'm looking at is my z-axis and replacing the motor couplers with ones with much less vertical give. I'm wondering if the springy-type couplers have too much play in them when the extruder is at the edge (where I see this problem) , therefore putting more weight on the coupler, compressing it, and reducing the Z height.

Thanks all for your continued effort.

[Bob-the-Kuhn]

@benlye - The print speed won't affect the compensation.

The planner creates a structure for each move command that includes the number of steps and direction for each axis. The stepper then executes that block. The compensated Z is computed as part of creating that structure.

---

@aaronthomaswebster - getting the probe closer to the nozzle just means you can probe more of the bed. It shouldn't affect the probe's accuracy.

You may want to consider switching to another type of probe. It appears that your inductive probe triggers at different heights around the edges vs. in the interior.

[oderwat]

Well I posted it here before and it helped some people in a community I frequently participate in:

; Heat up like for printing
M851 Z0 ; Z-Offset Reset
G28 ; Homing all axis (in the middle of the bed)
G1 X110 Y110 ; put nozzle! into the middle
; move nozzle down to hardly grip some paper
G92 Z0 ; mark this position as Z zero
G30 X110 Y110 ; let the sensor probe in the middle (where z for the nozzle actually is zero now)
; G30 Z Bed is the (negative) Z offset
M851 Z-1.23 ; 1.23 as example .. set the offset 
M500 ; store it to the eeprom

This procedure is able to compensate tilts between nozzle and probe (from bed or axis) which otherwise is ignored by the original procedure. This way you measure Z offset at the same spot where you let the nozzle touch the bed.

I suspect a lot of problems in Z-offset shifting between different positions of the bed. So you may want to try the above procedure at X20 Y20 and X200 Y200 and other parts of the bed. If you get different values for the z-offset it can't never work reliable!

[oderwat]

@Bob-the-Kuhn "getting the probe closer to the nozzle just means you can probe more of the bed. It shouldn't affect the probe's accuracy." ... not not fully true. It does effect the difference I describe in the post above. Just think of a 2mm height bump where the nozzle is while there is none where the sensor is. But it also changes how much tilting in the axis affect the z-offset stability. just think of a change in the tilt when the head moves. the farther the distance between sensor and nozzle tip, the more variance in the z-offset when the head tilts.

[Bob-the-Kuhn]

@oderwat - you got me to scratching my head.

Yes, the bed tilt definitely affects the relative heights but I don't think that makes a difference when doing bilinear auto leveling.

With bilinear leveling the software stores the probe's location along with the Z compensation for that point. When printing the planner uses that same compensation when the nozzle is at that point.

It does point out one thing I hadn't considered. You need to be fairly accurate in the X & Y offsets in the configuration file. If you have a 200mm bed that tilts 2mm, then a 5mm error in the X,Y offsets will give you a 0.05mm error in the compensated height.

Using the procedure you detailed, the bed has to be very flat or else you'll get different z-offsets. Doesn't matter if the bed is tilted, just that it's flat.

It appears to me that, with bilinear leveling, the main error contributors are:

• probe accuracy & repeatability
• accuracy of the X & Y probe offsets
• step size
• mechanical hysteresis
• if you're within the probed area

[oderwat]

I am talking about the z-offset measurement, not about probing points. People had the problem that their G28 fits at X110 Y110 but not at other points e.g. after G29. I can only repeat: Think of a bed with a "bend" at the place where the nozzle is, but distant to the probe location. Your initial probe-z-offset measurement will be off from the real value. This is true for bends and tilts of bed or axis. To compensate for that I came up with the z-offset measuring procedure I described above. Until you understand what this is about, there is an important piece missing in my opinion. As mentioned before, I had multiple people which complained about not working G29 ... and after "begging" them to use above procedure for z-offset measuring, the problem vanished.

Besides that, measuring the z-offset at different points is very interesting. As I said: It needs to be constant everywhere and "logically" it should be in the range of the probe accuracy. But in reallity it may not be constant! Take the normal prusa setup with two horizontal rods holding the printer head carriage. If one of the rods is "farther back" on the right side, the whole head will tilt backwards with increasing x position. This will introduce a change in the distance between the nozzle and the probe position (the z-offset), as with the tilting head, the probe may be higher in relation to the bed than the nozzle at that point. So you may probe there and even compensate for the XY offset, but you can't compensate for the sudden Z offset.

People get confused about "z-offset" and probing points. Z-offset is the distance from the nozzle tip to the probe trigger location, which has to be constant over the whole bed. If it is not, you can't reliably probe at another location. Technically it degrades the probe accuracy and may be related to the XY position and "could" be another factor which needs compensation. Afaik this is even implemented in some firmware which uses the IR difference sensor.

[oderwat]

With bilinear leveling the software stores the probe's location along with the Z compensation for that point. When printing the planner uses that same compensation when the nozzle is at that point.

This is the problem :) if the nozzle and the probe at this position have a new error introduced which makes the stored z-offset (which was measured at just one point in the middle of the bed) not reflecting the real distance between nose and sensor trigger point at this place.

One easy to see and understand way to describe a similar effect: Think of having the probe cable being too stiff and "bending" the probe different at different bed positions. It would be immediately clear, that this destroys everything. Having a (variable) tilt in the head will do the same.

[thinkyhead]

There's another "hidden" way to find out exactly how much compensation is being applied at the current XY position. This should probably be added to M114, but for now…

If you have DEBUG_LEVELING_FEATURE enabled (and use M111 S8 to enable it) then you can use G29 Q to get a report that includes how much Z adjustment is being applied at the current point. The line looks like this:

echo: ABL Adjustment Z-0.04

...or for planar leveling...

echo: ABL Adjustment X0.01 Y0.03 Z-0.01

[Bob-the-Kuhn]

@oderwat - I'm aware that there can be a significant difference in the bed height between the probe's position and the nozzle's position. I just don't think it matters when the nozzle is within the probed area and bilinear leveling is used.

Having a consistent Z_offset across the bed is very important if you're using 3 point or linear bed leveling. These methods assume the bed is a tilted plane. You can't have a consistent Z_offset if the bed has peaks and valleys.

[oderwat]

@Bob-the-Kuhn well you still don't get it, but I tried. Hint: "Z-Offset = Distance from nozzle tip to probe trigger (needs to be constant to create a valid measurement)" "Z-Compensation = Value of the ABL correction (is changing and calculated from probed points)".

[Bob-the-Kuhn]

A mighty fine discussion of apples vs. oranges.

I agree with the above statements.

My comments were aimed at when having a constant Z offset mattered and when it didn't (assuming that the probe wasn't the source of the inconsistencies).

[BillStruve]

Seems to me that G29 should have 3 offsets, z, x, and y between the nozzle and the probe. As I understand, the z correction is applied to the nozzle position (x,y) but it is calculated from data when the probe is at position (x+dx,y+dy). In my printer it doesn't matter since both dx=0 and dy=0, but commonly both will not be zero.

[ghost]

I know that the issue that I have with Bilinear ABL is, it was air printing in the position of X120 - X185 (worse when closer to the edge (X185)) and was scraping tape from X0 - ~X70.

I seriously thought my probe was inconsistant. I ran repeatability test at every point that it would probe in the 3x3 grid (9 points). I gathered data from the repeatability test ever 5 different times and plotted them in Excel. I was looking for an issue. I found that my probe was within .003mm throughout all of that.

My glass and bed is fairly flat and can get it to print ok without any software bed leveling.

MBL has worked better than without it. I never thought to check the Z offset at each point. Mainly thinking that my probe isn't moving.

I have more testing to do.. Thanks guys!

[Bob-the-Kuhn]

@BillStruve - during G29 the head is moved to (X, Y) which means the probe is at (x+dx,y+dy). G29 then saves (x+dx,y+dy) and the probe results. During moves the planner applies the probe results when the nozzle is at (x+dx,y+dy).

[Bob-the-Kuhn]

@BillStruve - can you point me to the info on your print head system?

I've heard of systems where the nozzle is the sensor but I haven't found any.

How repeatable is your system (M48 type results)?

[Bob-the-Kuhn]

What inductive sensors are you guys using?

I'd like to play with a couple and see how they perform.

[benlye]

I use this one:
https://www.aliexpress.com/item/M18-8mm-sensing-DC-5V-NPN-NO-LJ18A3-8-Z-BX-5V-cylinder-inductive-proximity-sensor/32719316657.html

It seems to work very well, with good repeatability and accuracy across the bed. For example:

M48 P10 X105 Y93
M48 Z-Probe Repeatability Test
Finished!
Mean: -0.062250 Min: -0.065 Max: -0.060 Range: 0.005
Standard Deviation: 0.001750

The worst range I've seen across a 10-probe sample is 0.015, with SD of 0.004899.

[oderwat]

@Bob-the-Kuhn please get your terminology right "Z-Offset" is what is stored with M851. This needs to be constant on the physical side for any type of ABL to work. What I am talking about us not comparing apples with oranges and can't be ignored. It simply is the explanation for problems real people have with their real systems.

@benlye try the following to see if your system reports constant z-offsets:

Get the four extrem points for you abl measuring from the configuration. For example X20 Y20, X200 Y20, X200 Y200, X20 Y200. You can also just choose 4 points in the corners of your bed.

Then do the full procedure below for each of those points and for X and Y at half your bed size (aka middle of your bed), for example at X110 Y110. Using your values for the 5 different positions instead of 110 in the example below.

; do this once
M851 Z0 ; Z-Offset Reset
G28 ; Homing all axis (in the middle of the bed)

; do this for every point
G1 X110 Y110 ; put nozzle to the measure point
; move nozzle down to hardly grip some paper
G92 Z0 ; mark this position as Z zero
G30 X110 Y110 ; let the sensor probe in the middle (where z for the nozzle actually is zero now)
; note Bed Z value for X110 Y110

This will measure at which height relative to the nozzle the probe does trigger at your chosen points. The value should be as accurate as your M48 Sensor results and constant over all points. If there are bigger differences at different bed positions your z-offset is not constant and ABL can't not work probably. If that is the case you need to find the problem with your hardware first.

[ghost]

Shouldn't that be G28 Z, if you want to home in the middle of the bed?

[oderwat]

@Tannoo not with a probe setup, they usually (always?) probe at the center of the bed. It also doesn't matter here. It is only needed to initialise the positioning. The important factor is that you G1 and G30 to the same point. This is the only way you can check if your z-offset (aka M851 aka distance between nozzle and probe trigger point) is constant over your whole bed. This is the basis for everything else and as important as the probe repeatability error.

I made a small correction to the procedure because you only need to reset the z-offset and initialise the coordinates once.

[ghost]

Ok, but a G28 with or without probe will put my nozzle at 0,0,0. Center of the bed is roughly 80,80.
So, G0 X100 Y100 to put it near the center then home Z wit G28 Z.
Then continue as you stated.

I'm just getting it clear on what you want done for when I get to do it later this morning.

[ghost]

Well, with the probe, the nozzle doesn't get that close to the bed. Nevermind about the swap.

I haven't used the probe for quite some time.. You'll have to forgive me.

[ghost]

Z_SAFE_HOMING needs to be enabled to home Z in the center by default.

[benlye]

Well, what do you know, my Y_PROBE_OFFSET_FROM_EXTRUDER was out by 2mm!

I just reset and recalibrated by bed settings as accurately as I think I can. I'll repeat some tests later today, including checking the Z-offset in each corner as well as the centre.

[BillStruve]

@Bob-the-Kuhn I'm confused, how can "G29 then saves (x+dx,y+dy) and the probe results" if it does not know dx and dy.
The Mini Metal Maker z-min (which I use for z-probe) is not in the print head, it is 3 microswitches under the bed. Z0 is set to 0.35 in the post G29 gcode, so the nozzle is at the surface of the bed instead of the microswitch trip point.
M48 results: Mean: -0.327813 Min: -0.330 Max: -0.325 Range: 0.005 Standard Deviation: 0.001348
Raw data for G29 and M48:

>>> g28
SENDING:G28
echo:busy: processing
echo:busy: processing
echo:busy: processing
>>> g29 v4
SENDING:G29 V4
G29 Auto Bed Leveling
echo:busy: processing
Bed X: 20.000 Y: 5.000 Z: 0.009
echo:busy: processing
Bed X: 40.000 Y: 5.000 Z: 0.011
echo:busy: processing
Bed X: 60.000 Y: 5.000 Z: 0.044
echo:busy: processing
Bed X: 60.000 Y: 25.000 Z: 0.063
echo:busy: processing
Bed X: 40.000 Y: 25.000 Z: -0.004
echo:busy: processing
Bed X: 20.000 Y: 25.000 Z: 0.022
echo:busy: processing
Bed X: 20.000 Y: 45.000 Z: -0.025
echo:busy: processing
Bed X: 40.000 Y: 45.000 Z: 0.064
echo:busy: processing
Bed X: 60.000 Y: 45.000 Z: 0.067
Eqn coefficients: a: 0.00140104 b: 0.00035417 d: -0.03697918
Mean of sampled points: 0.02791666
Bed Height Topography:
   +--- BACK --+
   |           |
 L |    (+)    | R
 E |           | I
 F | (-) N (+) | G
 T |           | H
   |    (-)    | T
   |           |
   O-- FRONT --+
 (0,0)
 -0.05292 +0.03646 +0.03896
 -0.00542 -0.03229 +0.03521
 -0.01917 -0.01729 +0.01646
Corrected Bed Height vs. Bed Topology:
 +0.00031 +0.06167 +0.03615
 +0.05490 +0.00000 +0.03948
 +0.04823 +0.02208 +0.02781
Bed Level Correction Matrix:
+0.999999 +0.000000 +0.001401
-0.000000 +1.000000 +0.000354
-0.001401 -0.000354 +0.999999
echo:enqueueing "G1 Z0.35 F600"
echo:enqueueing "G92 Z0"

>>> m48 p20 x 40 y25 v4
SENDING:M48 P20 X 40 Y25 V4
M48 Z-Probe Repeatability Test
Positioning the probe...
echo:busy: processing
Bed X: 40.000 Y: 25.000 Z: -0.323
echo:busy: processing
1 of 20: z: -0.326 mean: -0.3256 sigma: 0.000000 min: -0.326 max: -0.326 range: 0.000
2 of 20: z: -0.326 mean: -0.3256 sigma: 0.000000 min: -0.326 max: -0.326 range: 0.000
echo:busy: processing
3 of 20: z: -0.327 mean: -0.3263 sigma: 0.000884 min: -0.327 max: -0.326 range: 0.002
echo:busy: processing
4 of 20: z: -0.327 mean: -0.3266 sigma: 0.000937 min: -0.327 max: -0.326 range: 0.002
echo:busy: processing
5 of 20: z: -0.326 mean: -0.3265 sigma: 0.000848 min: -0.327 max: -0.326 range: 0.002
6 of 20: z: -0.327 mean: -0.3267 sigma: 0.000859 min: -0.327 max: -0.326 range: 0.002
echo:busy: processing
7 of 20: z: -0.329 mean: -0.3270 sigma: 0.001079 min: -0.329 max: -0.326 range: 0.003
echo:busy: processing
8 of 20: z: -0.328 mean: -0.3271 sigma: 0.001080 min: -0.329 max: -0.326 range: 0.003
echo:busy: processing
9 of 20: z: -0.327 mean: -0.3272 sigma: 0.001025 min: -0.329 max: -0.326 range: 0.003
10 of 20: z: -0.327 mean: -0.3271 sigma: 0.000976 min: -0.329 max: -0.326 range: 0.003
echo:busy: processing
11 of 20: z: -0.328 mean: -0.3272 sigma: 0.000974 min: -0.329 max: -0.326 range: 0.003
echo:busy: processing
12 of 20: z: -0.329 mean: -0.3274 sigma: 0.001107 min: -0.329 max: -0.326 range: 0.004
echo:busy: processing
13 of 20: z: -0.330 mean: -0.3276 sigma: 0.001270 min: -0.330 max: -0.326 range: 0.004
14 of 20: z: -0.329 mean: -0.3277 sigma: 0.001260 min: -0.330 max: -0.326 range: 0.004
echo:busy: processing
15 of 20: z: -0.328 mean: -0.3277 sigma: 0.001222 min: -0.330 max: -0.326 range: 0.004
echo:busy: processing
16 of 20: z: -0.325 mean: -0.3275 sigma: 0.001353 min: -0.330 max: -0.325 range: 0.005
echo:busy: processing
17 of 20: z: -0.328 mean: -0.3276 sigma: 0.001319 min: -0.330 max: -0.325 range: 0.005
18 of 20: z: -0.329 mean: -0.3276 sigma: 0.001310 min: -0.330 max: -0.325 range: 0.005
echo:busy: processing
19 of 20: z: -0.329 mean: -0.3277 sigma: 0.001333 min: -0.330 max: -0.325 range: 0.005
echo:busy: processing
20 of 20: z: -0.329 mean: -0.3278 sigma: 0.001348 min: -0.330 max: -0.325 range: 0.005
Finished!
Mean: -0.327813 Min: -0.330 Max: -0.325 Range: 0.005
Standard Deviation: 0.001348

[Bob-the-Kuhn]

@BillStruve - thanks for the info.

On (x+dx,y+dy) - I thought you meant dx was the X offset of the probe and dy was the Y offset of the probe.

[Bob-the-Kuhn]

@oderwat - attached is the logic sequence I went through to arrive at my "constant M851 Z offset is not needed when using bilinear leveling" conclusion.

Please review.
Z offsets.xlsx

[BillStruve]

@Bob-the-Kuhn Sorry about that, I did a (too) quick look at Configuration.h and did not find Y_PROBE_OFFSET_FROM_EXTRUDER, X_PROBE_OFFSET_FROM_EXTRUDER, so I thought that they were not specified. Boy, my memory is going since I had set both of these to zero a couple of months ago!

[benlye]

I need to do a few more prints, but the few tests I've done since fixing my probe X and Y offset values and re-calibrating the bed settings have had much more consistent first layers.

Before now, if I printed a skirt it would almost never come off in one piece because it would be nonexistent in one corner. For the last few prints it is paper-thin (my initial layer is 0.12) and consistent all the way around, and comes off in one piece.

:-)

EDIT: Just to be clear, by 're-calibrating the bed settings' I mean that I adjusted some settings relating to bed / positioning in configuration.h, namely the travel after homing settings, as I found that the center coordinates were slightly off the actual bed center. I did not adjust the levelling screws.

[aaronthomaswebster]

I have an ignorant question.... is G29 all i need to do to enable auto bed leveling or is there something to do after G29 to apply the leveling?

[Bob-the-Kuhn]

G29 automatically enables auto leveling.

You can use M420 to enable/disable auto bed leveling once G29 has been run.

[jamhot1]

hey guys, I've decided to double my 3d printer into a PCB milling machine and have run into a few issues trying to issue specific commands appended to the G29 procedure. I need to probe as many as 15 points in specific area's on the PCB so that I can use them to mill out my designs. It also saves me trying to probe the entire bed and reduces time. I just can't seem to get it to play ball. If I send G29 X8 Y8 L25 R65 F110 B160, It will only probe out the 1st 2 rows of 8 before resetting itself. I have AUTO_BED_LEVELING_LINEAR set which I believe allows me to modify the G29 parameters in this way. I thought it might be a memory issue because the latest release uses 97% of flash memory but I revert to previous that used 92% and i still get the same issue. It this a related issue? i am running on an Anet A8 machine.

[thinkyhead]

@jamhot1 — Are you using 32x microstepping? What kind of Z feedrate are you using between probes? Try reducing your feedrates to see if it prevents the reset.