search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.25k stars 19.23k forks source link

G29 Issue #5898

Closed aaronthomaswebster closed 7 years ago

aaronthomaswebster commented 7 years ago

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 commented 7 years ago

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

aaronthomaswebster commented 7 years ago

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 commented 7 years ago

(not relevant anymore since the comment was fixed)

ghost commented 7 years ago

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 commented 7 years ago

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

aaronthomaswebster commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

oderwat commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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

benlye commented 7 years ago

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:       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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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.

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 commented 7 years ago

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.

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 commented 7 years ago

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:

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:



- 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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

I like that plot.

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

aaronthomaswebster commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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.

image

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

elliotboney commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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: