I've just re-uploaded correct Configuration.txt in previous post.

tnw513 on 12 Aug 2016

I think there's an issue with gri(d) bed leveling? Try without "#define AUTO_BED_LEVELING_GRID". Comment it out to use the 3 point leveling and also try G29 with and without v4 ("G29 v4"). I've had luck with that, but I'm still trying to track down the issue.

nicksears on 13 Aug 2016

FYI, this is being discussed in both #4577 and #4593 also.

bgort on 13 Aug 2016

@bgort I know but I didn't see any solution to this.
I'll do a test with ABL debug enabled.

tnw513 on 13 Aug 2016

@tnw513 As far as I know, there isn't one yet. Was just letting you know in case you hadn't seen the others.

bgort on 13 Aug 2016

@bgort Actually I had not seen one of the two :)

tnw513 on 13 Aug 2016

running into a similar issue. using UBL, after doing calibration. once I start a print it starts over 1mm above bed, i end up compensating in my slicer

adamfilip on 14 Aug 2016

I see something similar on my delta.
The probe is calibrate so that it triggers at the same height as the nozzle so the Z offset is 0.
Yet the debugging seems to return probe values of around 2.00
Then once the print starts the head is above the bed 2mm or so.
I have thought about adjusting the Z offset of the probe in marlin by 2mm.
But this doesn't seem like the right thing to do.

aljscott on 17 Aug 2016

running into a similar issue. using UBL, after doing calibration. once I start a print it starts over 1mm above bed, i end up compensating in my slicer

Hmmmmm... We may need to add more debugging code to find where the problem is. I'm not seeing that issue. But I haven't been printing much the last week. I've been re-writing the mesh_buffer_line() routine to be faster.

The good news (on the UBL) side is if we have to add debug code to figure this out, it shouldn't take too long to find the problem. Can you get a set of steps that reliably duplicates the problem?

Roxy-3D on 17 Aug 2016

not sure.. ive tried too much stuff and now am confused more then ever.
trying to compensate in my slicer isn't working.

im trying G29 Z to get an offset
im changing Probe offset in config h.
ive tried set home offset from the menu

only way i seem to be able to get the nozzle to the right height is using babystepping during the first layer.

I need to start from scratch
I know that my z probe offset from my nozzle -17mm

adamfilip on 17 Aug 2016

I had to create a new mesh a bunch of times while writing the software. Here is a shortcut: Put the nozzle in the center of the bed and let it grab 10 points. That is enough you should be able to start printing a Mesh Validation pattern. Verify you can get those 10 points dialed in and accurate. You can keep adding to the Mesh a whole bunch of different ways.

Roxy-3D on 17 Aug 2016

For others with the issue, is it exactly 1 and 2 mm as you say? Or approximate? I'm definitely getting variation: 1.37, 1.35, 1.36. Usually clustered, making me think its based on the bed leveling plane, but can change significantly over time.

This is definitely not an issue in rc4 with my configuration. I'm going to pull a fresh copy of rc7 (is this any different than rcbugfix?) And make as few changes as necessary to see if that even works with auto bed leveling.

nicksears on 17 Aug 2016

I just started over. reflashed, M502, M500
Created new mesh, Filled extra points with a similar value
Ran G26 test print. and it was too close. then i did a I did a G29 Z offset 0f .9mm
did a test print. it wasnt perfect but it was printing..

when i did a test print of a file.. the nozzle was aprox 2mm over the surface
slicing has zero Z compensation.

adamfilip on 17 Aug 2016

I'm not at home at the moment so I can't pasted any output.
If I "G29 V4"
I get values returned in the range ~ 2.01, 2.02
Seems like its 2mm + - the bed levelling???
There are also a few 0.00 around the edges that was raised as concern on another issue.
The probe and the nozzle are at the same level, and I observe them both just touching the bed.

Then went I print a file from an SD card it would end up ~2mm off the bed.
Pretty much what @adamfilip describes.
If I don't auto level I get a pretty good print with just the MANUAL_Z_HOME_POS that I've set.

aljscott on 17 Aug 2016

(is this any different than rcbugfix?)

RC is just there as a historical point in time. It is when RCBugFix started getting fixes applied to it (for the current RC-#). You really want to be using RCBugFix.

Roxy-3D on 17 Aug 2016

Ran G26 test print. and it was too close. then i did a I did a G29 Z offset of .9mm
did a test print. it wasnt perfect but it was printing..

OK! That helps! Remember G29 Z is pretty much untested. If it can print... Can you do a G26 C P O2 and dial in 10 or 15 points? Does it start to print almost normal? And a G29 W will tell you all of the current important numbers that control the system.

Roxy-3D on 17 Aug 2016

@adamfilip I just had an idea. The big difference between what you and I have is this: I have my Z_PROBE_OFFSET_FROM_EXTRUDER set perfectly so I don't have a Z_OFFSET. Can you try to move towards what I have? I'm going to do the exact opposite. I'm going to deliberately move my Z_PROBE_OFFSET_FROM_EXTRUDER out of calibration and try to do what you are doing (correcting with Z_OFFSET).

Roxy-3D on 17 Aug 2016

Dear contributors to this thread.
As long as all of you are talking about different levelling systems and branches in one tread, there is no realistic chance to find a solution for any of you. Please be very clear about what you are talking about. Ideally in every message. Ideally in separate issues.
UBL
MBL
Grid levelling
Delta levelling

UBL-branch
RC7
RCBugFix
older branches

Please let's return here to RCBugFix, Grid levelling, different Z_PROBE_OFFSET_FROM_EXTRUDER for G28 and G29.

Blue-Marlin on 17 Aug 2016

With ABL (no UBL :-) ) and RCBugFix.
this matrix seems fine (for "3-point" mode as asked)?

Bed Level Correction Matrix:
+0.999999 +0.000000 +0.001470 
-0.000002 +0.999999 +0.001586 
-0.001470 -0.001586 +0.999998 
X:182.02 Y:128.02 Z:14.92 E:0.00 Count X: 14560 Y:10240 Z:61575

Seems that my probe is working fine:

M48 E V4 L8: Standard Deviation: 0.009595
M48 X 100 Y 100: Standard Deviation: 0.003785
M48 X 100 Y 100 E: Standard Deviation: 0.004267

tnw513 on 17 Aug 2016

@tnw513
No. The rotation matrix should be perfectly symmetrical along the [0,0]-[n,n] diagonal. The -0.000002 looks wrong to me.

Blue-Marlin on 17 Aug 2016

mmm... and what can I do to test?

I've done a test with DEBUG_LEVELING_FEATURE defined.
So
-RCBugFix
-Grid

EDIT: new log. RCBugFix as of today:
log08172016.txt

and

>>> G29 v4
SENDING:G29 V4
G29 Auto Bed Leveling
Bed X: 190.000 Y: 25.000 Z: 9.851
Bed X: 10.000 Y: 25.000 Z: 9.617
Bed X: 10.000 Y: 160.000 Z: 9.842
Bed X: 190.000 Y: 160.000 Z: 10.136
Eqn coefficients: a: 0.00146388 b: 0.00188704 d: 9.54043579
Mean of sampled points: 9.86137580
Bed Height Topography:
   +--- BACK --+
   |           |
 L |    (+)    | R
 E |           | I
 F | (-) N (+) | G
 T |           | H
   |    (-)    | T
   |           |
   O-- FRONT --+
 (0,0)
 -0.01938 +0.27413
 -0.24413 -0.01062
Corrected Bed Height vs. Bed Topology:
 +0.00000 +0.03000
 +0.03000 +0.00000
Bed Level Correction Matrix:
+0.999999 +0.000000 +0.001464
-0.000003 +0.999998 +0.001887
-0.001464 -0.001887 +0.999997
sending:G29 V4G29 Auto Bed LevelingBed X: 190.000 Y: 25.000 Z: 9.851Bed X: 10.000 Y: 25.000 Z: 9.617Bed X: 10.000 Y: 160.000 Z: 9.842Bed X: 190.000 Y: 160.000 Z: 10.136Eqn coefficients: a: 0.00146388 b: 0.00188704 d: 9.54043579Mean of sampled points: 9.86137580Bed Height Topography:   +--- BACK --+   |           | L |    (+)    | R E |           | I F | (-) N (+) | G T |           | H   |    (-)    | T   |           |   O-- FRONT --+ (0,0) -0.01938 +0.27413 -0.24413 -0.01062Corrected Bed Height vs. Bed Topology: +0.00000 +0.03000 +0.03000 +0.00000Bed Level Correction Matrix:+0.999999 +0.000000 +0.001464-0.000003 +0.999998 +0.001887-0.001464 -0.001887 +0.999997

and after G29 head is at exactly 0.5mm over the bed.

tnw513 on 17 Aug 2016

In MarlinMain.cpp please add:

@@ -2259,11 +2259,14 @@ static void clean_up_after_endstop_or_probe_move() {
             DEBUG_POS(">>> set_bed_level_equation_lsq", current_position);
           }
         #endif

         vector_3 planeNormal = vector_3(-plane_equation_coefficients[0], -plane_equation_coefficients[1], 1);
+        planeNormal.debug("plane_Normal");
+        planner.bed_level_matrix.debug("identity?");
         planner.bed_level_matrix = matrix_3x3::create_look_at(planeNormal);
+        planner.bed_level_matrix.debug("directly after create_look_at");

         vector_3 corrected_position = planner.adjusted_position();
         current_position[X_AXIS] = corrected_position.x;
         current_position[Y_AXIS] = corrected_position.y;
         current_position[Z_AXIS] = corrected_position.z;

And repeat the test you made the log with - but with G29 V4 to get more intermediate results.

Blue-Marlin on 17 Aug 2016

Example output:

14:04:27.616 : Bed X: 190.000 Y: 189.000 Z: 0.529
14:04:27.616 : <<< probe_pt
14:04:27.620 : current_position=(190.00, 139.00, 5.00) : set_probe_deployed
14:04:27.620 : deploy: 0
14:04:27.620 : do_probe_raise(15.00)
14:04:27.623 : >>> do_blocking_move_to(190.00, 139.00, 15.00)
14:04:28.402 : echo:busy: processing
14:04:30.400 : echo:busy: processing
14:04:30.794 : >>> do_blocking_move_to(190.00, 139.00, 15.00)
14:04:30.798 : current_position=(190.00, 139.00, 15.00) : clean_up_after_endstop_or_probe_move
14:04:30.798 : current_position=(190.00, 139.00, 15.00) : > probing complete
14:04:30.810 : Eqn coefficients: a: -0.00026620 b: -0.00013527 d: 0.65249114
14:04:30.810 : Mean of sampled points: 0.60963892
14:04:30.814 : uncorrected_position=(190.00, 139.00, 15.00) : >>> set_bed_level_equation_lsq
14:04:30.818 : current_position=(190.00, 139.00, 15.00) : >>> set_bed_level_equation_lsq
14:04:30.818 : plane_Normal x: 0.000266 y: 0.000135 z: 1.000000
14:04:30.818 : identity?
14:04:30.822 : +1.000000 +0.000000 +0.000000
14:04:30.822 : +0.000000 +1.000000 +0.000000
14:04:30.823 : +0.000000 +0.000000 +1.000000
14:04:30.827 : directly after create_look_at
14:04:30.827 : +1.000000 +0.000000 -0.000266
14:04:30.827 : -0.000000 +1.000000 -0.000135
14:04:30.831 : +0.000266 +0.000135 +1.000000
14:04:30.831 : corrected_position=(189.99, 138.99, 15.07) : <<< set_bed_level_equation_lsq
14:04:30.835 : current_position=(189.99, 138.99, 15.07) : sync_plan_position
14:04:30.835 : Bed Height Topography:
14:04:30.835 : +--- BACK --+
14:04:30.839 : |           |
14:04:30.839 : L |    (+)    | R
14:04:30.839 : E |           | I
14:04:30.839 : F | (-) N (+) | G
14:04:30.839 : T |           | H
14:04:30.843 : |    (-)    | T
14:04:30.843 : |           |
14:04:30.843 : O-- FRONT --+
14:04:30.843 : (0,0)
14:04:30.843 : +0.05736 +0.00486 -0.08089
14:04:30.847 : +0.03061 -0.01889 -0.03039
14:04:30.847 : -0.00214 -0.01389 +0.05336
14:04:30.851 : Corrected Bed Height vs. Bed Topology:
14:04:30.851 : +0.09033 +0.06179 +0.00000
14:04:30.855 : +0.05425 +0.02871 +0.04117
14:04:30.855 : +0.01217 +0.02437 +0.11558
14:04:30.855 : Bed Level Correction Matrix:
14:04:30.859 : +1.000000 +0.000000 -0.000266
14:04:30.859 : -0.000000 +1.000000 -0.000135
14:04:30.859 : +0.000266 +0.000135 +1.000000

If

14:04:30.827 : directly after create_look_at
14:04:30.827 : +1.000000 +0.000000 -0.000266
14:04:30.827 : -0.000000 +1.000000 -0.000135
14:04:30.831 : +0.000266 +0.000135 +1.000000

is not symetrc we have numerical problems in the calculation of the matrix from the normal. That would be not very nice but a thing we probably have to live with.
If

14:04:30.827 : directly after create_look_at
14:04:30.827 : +1.000000 +0.000000 -0.000266
14:04:30.827 : -0.000000 +1.000000 -0.000135
14:04:30.831 : +0.000266 +0.000135 +1.000000

!=

14:04:30.855 : Bed Level Correction Matrix:
14:04:30.859 : +1.000000 +0.000000 -0.000266
14:04:30.859 : -0.000000 +1.000000 -0.000135
14:04:30.859 : +0.000266 +0.000135 +1.000000

something is altering the matrix. Hard to find.

Blue-Marlin on 17 Aug 2016

👍1

@Roxy-3D

I just had an idea. The big difference between what you and I have is this: I have my Z_PROBE_OFFSET_FROM_EXTRUDER set perfectly so I don't have a Z_OFFSET. Can you try to move towards what I have? I'm going to do the exact opposite. I'm going to deliberately move my Z_PROBE_OFFSET_FROM_EXTRUDER out of calibration and try to do what you are doing (correcting with Z_OFFSET).

When I started over my Z Probe offset from extruder is set to the correct amount of -17mm and my Z offset was Zero. but then i needed to add Z offset .9mm

so Im adding the .9mm to my -17 to get -16.1 for my Z_PROBE_OFFSET_FROM_EXTRUDER
and Z_OFFSET is 0

adamfilip on 17 Aug 2016

Please let's return here to RCBugFix, Grid levelling, different Z_PROBE_OFFSET_FROM_EXTRUDER for G28 and G29.

I understand who has what... But I agree. @adamfilip let's start a separate thread for UBL Z_OFFSET issues. Otherwise, we are going to confuse everybody.

Here is one more thing you are doing differently than me. You are actually measuring things, and trying to plug in numbers. In theory, that should work just fine. But the way I operate is I've always looked at what the error was, and corrected most of it, but always made sure I would not drive the nozzle into the glass. So, it takes me 3 or 4 tries to get the nozzle's Z_OFFSET_FROM_EXTRUDER exactly correct. But it is perfect after those 3 or 4 iterations.

The reason I'm mentioning it is this: With the Z-Fade-Height active, it is possible there is a disconnect and either too much or too little Z-Height compensation is being done. And that compensation is going to change based on how much you are tying to correct.

Please try 3 or 4 (or 7) iterations to get Z_OFFSET_FROM_EXTRUDER set perfectly. And try to do it on a place on the bed where you know things are relatively flat. And don't forget to do a M502 and M500 each cycle (I always forget to do that!!!)

Mean while... I'm going to start setting up to go the opposite route and see what I find.

Roxy-3D on 17 Aug 2016

@Blue-Marlin

New log:
log08172016-2.txt

Matrix seems non altered.
But it is not symmetric.

tnw513 on 17 Aug 2016

@tnw513

and after G29 head is at exactly 0.5mm over the bed.

The position after G29 (grid/3point) is mostly determined by your settings for Z_PROBE_DEPLOY_HEIGHT, Z_PROBE_TRAVEL_HEIGHT, Z_HOMING_HEIGHT.

To make a valid statement about the levelling, measure after G1 Z0 and also tell the related x/y coordinates.

Blue-Marlin on 17 Aug 2016

@Blue-Marlin Sure.
After G1 Z0 there are 0.5mm under the nozzle.
X=100 and Y=100.
Same behavior for X=107.5 and Y=97.5 (center).

In addition I've disabled min software endstop and I can go down until -0.5mm (nozzle is touching standard paper 0.1mm) on z axis.

I've the following value defined:

define Z_PROBE_DEPLOY_HEIGHT 15

define Z_PROBE_TRAVEL_HEIGHT 15

//#define Z_HOMING_HEIGHT 4 //(commented)

Even with Z_HOMING_HEIGHT undefined Z will go up before home (probably in order to deploy z probe).

tnw513 on 17 Aug 2016

@Blue-Marlin

No. The rotation matrix should be perfectly symmetrical along the [0,0]-[n,n] diagonal. The -0.000002 looks wrong to me.

This is a little bit fuzzy for me to talk about. I don't remember all of the details. But I looked at this 3 or 4 months ago. I believe the non-symmetry is coming from the fact we don't have an .inverse() method to modify a matrix. Instead, in set_bed_level_equation_lsq() we use .create_look_at() to give us the correction matrix.

The problem is, it does not assume the ability to create an inverse matrix to do its math. I think I remember it approximates the solution. The y_row is not even scaled an appropriate amount to compensate for the scaling of the x_row (and the non-scaling of the z_row). As a first level correction, it might make sense to calculate the y_row to get the y entry, but then use the x and z rows to fill in values to force the symmetry.

And some extra reading I did at that time to understand things: stackoverflow.com/questions/349050/calculating-a-lookat-matrix

Note all the comments about 'inverse' and 'inversion' of a matrix. If I remember right, I finished with the opinion that create_look_at() is not exactly correct. But it is a reasonable approximation.

matrix_3x3 matrix_3x3::create_look_at(vector_3 target) {
  vector_3 z_row = target.get_normal();
  vector_3 x_row = vector_3(1, 0, -target.x / target.z).get_normal();
  vector_3 y_row = vector_3::cross(z_row, x_row).get_normal();
  matrix_3x3 rot = matrix_3x3::create_from_rows(x_row, y_row, z_row);
  return rot;
}

Roxy-3D on 17 Aug 2016

For every correct rotation matrix the transposed is equal to the inverse. We do use that fact in Planner::adjusted_position().
Calculating the matrix is rare - so we could try to do it correct. Digging in the math.

Blue-Marlin on 17 Aug 2016

For every correct rotation matrix the transposed is equal to the inverse.

If this is true... My guess is the rotation matrix needs to be symmetrical. Because if it is not symmetrical, it will distort the coordinate system that it is mapping points into.

And this might explain why the transpose of a rotation matrix is equal to the inverse. Remember... The inverse does not always exist. So if it does exist and is simply the transpose, my bet is the matrix has to be symmetrical.

I eagerly await to hear a deeper analysis!

Roxy-3D on 17 Aug 2016

I'm posting this here, but I think all issues like this (#4577, #4220, and #4612) stem from an error in G29 giving the wrong position after leveling. I took a fresh copy of RCBugFix and made my absolute minimum necessary changes:

#define USE_YMAX_PLUG //I home to y max
#define all "#_ENDSTOP_INVERTING" true // that's how mine are connected
#define FIX_MOUNTED_PROBE   // my probe is my nozzle
#define all "#_PROBE_OFFSET_FROM_EXTRUDER" 0 // my probe is my nozzle
#define Z_PROBE_DEPLOY_HEIGHT  1 // my probe is my nozzle so I dont need to lift much
#define Z_PROBE_TRAVEL_HEIGHT  1 // my probe is my nozzle so I dont need to lift much
#define Z_HOMING_HEIGHT 4 // lift to avoid collisions
#define Y_HOME_DIR 1 // home towards max
#define Y_MAX_POS 140 //y max is 140
#define AUTO_BED_LEVELING_FEATURE //obviously need this
#define LEFT_PROBE_BED_POSITION 160 // I have a small bed that I print on in an odd location
#define RIGHT_PROBE_BED_POSITION 180
#define FRONT_PROBE_BED_POSITION 60
#define BACK_PROBE_BED_POSITION 80
#define Z_SAFE_HOMING // home on that small bed location only
#define Z_SAFE_HOMING_X_POINT (((X_MIN_POS + X_MAX_POS) / 2)+70) // bed position is off center
#define HOMING_FEEDRATE_Z  (1*60) // slow it down z feedrate
#define DEFAULT_AXIS_STEPS_PER_UNIT   {533.333,533.333,3840,435} // calibration for my axes
#define DEFAULT_MAX_FEEDRATE          {30, 30, 5, 25}    // WTF was the default ever 300?!?
#define REPRAP_DISCOUNT_SMART_CONTROLLER // lcd

i know my probing postion is in a weird spot and that's a potential issue, but it still doesn't explain why it works in RC4 and not RC7...Anything here anyone recognizes that would break anything? If this doesn't work correctly, there's no way this isn't a major bug with G29.

nicksears on 17 Aug 2016

@nicksears It's possibly a real bug in G29 so let's not go round-and-round. I may have a chance to look more closely at gcode_G29 soon, but no guarantees. I've got a lot on my plate right now.

Your Z_PROBE_OFFSET_FROM_EXTRUDER should be a positive number, not zero, because most certainly your nozzle needs to depress before it triggers. The only exception is if you're conducting electricity through your nozzle and touching it to a metal ground plate, in which case it can trigger quite fast.

thinkyhead on 19 Aug 2016

@thinkyhead Did you you see the log at https://github.com/MarlinFirmware/Marlin/issues/4612#issuecomment-240414578 ?

I don't think that I have uneven bed but I don't know how to check if it is ok or not.
However with RC6 G29 works well for me without modification to probe offsets.

tnw513 on 19 Aug 2016

Did you you see the log

I'm only now getting around to actually trying to make sense of it.

with RC6 G29 works well for me without modification

We're probably past the point where we can just revert the code to RC6. And it's not all that simple to compare, either. Our most viable course at this time is to keep testing RCBugFix and locate the specific cause in the current codebase.

thinkyhead on 21 Aug 2016

After looking at the log, it seems more or less correct to me. But I need to analyze it more.

RF:  9.85,  9.85
LF:  9.64,  9.65 (0.2 lower than RF and LB)
LB:  9.85,  9.86
RB: 10.16, 10.17 (0.31 over RF and LB)

The probing result shows the bed to be tilted diagonally, with the left-front low and the right-back high. After probing, the nozzle is moved to 15mm above the bed, and then the Z is corrected according to the matrix. It goes from 15.00 to 14.32, so it thinks the bed is raised by 0.68mm at that final probe position, which is at the back-right of the bed. (Thus it assumes the nozzle is actually closer to the bed than 15mm.)

@Roxy-3D In the distant past we would figure the true Z position at the final probe point in a different way, and perhaps we can re-apply that same principle again. The idea was, since we know that Silvio's Z probe is 9.91mm below the nozzle, and we know that the last probe point triggered at 10.17, the bed must actually be 0.26mm higher at this final point than it is at the homed Z position. So the true Z distance to the bed at this final resting point is "known" to be 15 - 0.26, or 14.74mm. (The XY correction at this point is small, only X+0.02 and Y+0.03.)

The probe result from the log (14.32) doesn't match this. I'm thinking this might be due to some assumptions that no longer hold. First, does it matter where in the XY plane Z first homed? If it didn't home at 0,0 then the correction for position 212, 188 should not be based on 0, 0 but the homed position. In other words, it's just like any slope calculation. If you multiply the slope by 212, 188 to get the difference from Z at home but the actual XY distance from home is only 106, 94 then the XYZ will be over-corrected by double.

That's why I think it makes the most sense to re-correct Z using the last probe result before moving anywhere else. The correction to XY matters less, but on a very tilted bed it might also be off enough to notice.

@tnw513 If the final Z point were 14.74 rather than 14.32 then a G1 Z0 F1000 command would move the nozzle 0.42mm closer to the bed. That would apparently put the nozzle right on the bed in your case, based on your statement…

After G1 Z0 there are 0.5mm under the nozzle.

thinkyhead on 21 Aug 2016

@thinkyhead So sorry for uncleaned log. I didn't know it is needed.

That would apparently put the nozzle right on the bed in your case, based on your statement…

I'm not sure I understand what you mean.
I've done the following steps:
G28 --> G29 --> G1 Z0 F1000
after the last command the nozzle is not touching the sheet of paper between it and the bed.

After, with min_software_endstops disabled:
G28 --> G29 --> G1 Z0 F1000 --> G1 Z-0.1 F1000 --> G1 Z-0.2 F1000 --> G1 Z-0.3 F1000 --> G1 Z-0.4 F1000 --> G1 Z-0.5 F1000

at Z-0.4 nozzle gently touches the paper.
at Z-0.5 nozzle "scrapes" the paper
This sheet of paper is exactly 0.10mm thick. Tested with the caliper.

I hope I have clarified what I meant

tnw513 on 21 Aug 2016

I understood you. What I said was: _If the final Z point were 14.74 rather than 14.32 then it would place the nozzle closer._ In fact, I see from the log that the final position was set as 14.24 (not 14.32 as previously assumed). So that would make the solution I'm proposing produce exactly -0.5mm difference. Which of course matches your observation.

thinkyhead on 21 Aug 2016

👍1

However I don't want to leap too far ahead. There's always the possibility of a warped or curved bed, in which case simply correcting the position at the far corner might lead to the nozzle being too close or too far at other points on the plane. So perhaps there does need to be some "fudge factor" based on the "standard deviation." To be more accurate in that regard would probably require more than 4 sampled points. Alternatively, one final probe at the center just to get the difference in Z.

//         final_z : The uncorrected Z position (relative to homed Z)  (e.g., 15.0)
//      measured_z : The last probed Z, (ideally -zprobe_zoffset)      (e.g.,  5.1)
// -zprobe_zoffset : If the measured_z is matches this, perfect probe  (e.g.,  5.0)
//
// Using these values, the true Z is: 15 + (5.0 - 5.1) == 14.9
//
current_position[Z_AXIS] = final_z + (-zprobe_zoffset - last_measured_z);

thinkyhead on 21 Aug 2016

@thinkyhead I can test with 9, if you want. If yes what kind of log is better?
with debug enabled and G29 V4?
What kind of rows can I delete to make it cleaner? the keepalive messages?

tnw513 on 21 Aug 2016

@tnw513 All this log reading is killing my eyeballs. Let's try this instead. If you would test with my branch at https://github.com/thinkyhead/Marlin/tree/rc_final_z_correction and see if it produces a good height across the bed, that would give a good clue that I'm on a positive track. Do the usual G28 and G29, then move the nozzle down close to the bed and see if it remains nice and close to the bed as you go to different XY positions. If it scrapes the bed or gets too far off at different points, then we know the bed is a bit warped. Otherwise, if the bed is flat, it should follow the plane perfectly.

thinkyhead on 21 Aug 2016

Test done. Seems fine but in the back-left corner (gradually from a 5cm distance) of the bed nozzle is a bit too high. So probably it is warped. But it's a sheet of glass 22x22 (I have 2 of this and this happen on both), it's weird.

However during this test (with rc_final_z_correction but also RC6) I've discovered a potential issue. Z position is updated without any movement:
G28 --> G29 --> G1 X0 --> G1 Z{value greater than 0}

So, if X or Y endstop is pressed if I send G1 Z{value} Z axis doesn't move but Z position is updated.
without G29 all works fine.

tnw513 on 21 Aug 2016

if X or Y endstop is pressed if I send G1 Z{value} Z axis doesn't move but Z position is updated

Interesting. I've never heard of that one. Endstops shouldn't have any effect after homing/leveling unless ENDSTOPS_ALWAYS_ON_DEFAULT is turned on. If that's an issue in RCBugFix generally, would you mind posting a bug report with the full details for our friendly volunteers? I'd test this myself, but I don't have a 3D printer on hand.

thinkyhead on 21 Aug 2016

@Roxy-3D In the distant past we would figure the true Z position at the final probe point in a different way, and perhaps we can re-apply that same principle again. The idea was, since we know that Silvio's Z probe is 9.91mm below the nozzle, and we know that the last probe point triggered at 10.17, the bed must actually be 0.26mm higher at this final point than it is at the homed Z position. So the true Z distance to the bed at this final resting point is "known" to be 15 - 0.26, or 14.74mm. (The XY correction at this point is small, only X+0.02 and Y+0.03.)

Yes... What it was actually trying to do was compensate for the way the bed tilt affected the offset nozzle (from the probe). It knew where it wanted to set the 0.000 point for the probe, but it also knew the nozzle was offset (at a small angle) from where the probe was measuring things. So it extrapolated over to where the nozzle was, and added in extra correction to make that right.

Test done. Seems fine but in the back-left corner (gradually from a 5cm distance) of the bed nozzle is a bit too high. So probably it is warped. But it's a sheet of glass 22x22 (I have 2 of this and this happen on both), it's weird.

You can also try flipping the glass, and rotating the glass to see if that changes things. It is very possible it isn't the glass but is the bed as it travels down the axis.

You might want to consider bringing up the devel-ubl branch. (assuming you have a Cartesian machine) It is going to handle that very easily. The UBL G29 and G26 are a matched pair. You can dial in the amount of correction you need at each Mesh Point.

Roxy-3D on 21 Aug 2016

@thinkyhead Sure. I will do it today.

@Roxy-3D I've tried 2 glass and I've already tried all that.
Even with RC6 in the back-left angle the nozzle is a bit higher.

I will test UBL today. Thank you

tnw513 on 21 Aug 2016

👍1

If you bring up the UBL code, go with a 10 x 10 grid. Do a G29 P1 R to probe what you can easily. And I think you can ignore the 'old thinking'. Go ahead and leave the unreachable areas of the bed un-probed. Just fill them with a G29 P3 C0.0 R Then jump straight to G26 C P O2.000 and see what needs to be edited.

Roxy-3D on 21 Aug 2016

@thinkyhead, I'm using a conducting probe on a grounding surface. I just tried a fresh copy of RCBugFix and I'm having the same issue. I'm getting an offset of ~1.2 +/- 0.05 mm. I'm probing a small area so that may be why the number changes, but I'm not sure. Seems like the exact same problem.

With your corrected z branch it seems like it's working, but I'm not sure if it's completely correct. I get very close to 1.0 mm, but shouldn't this read as 1.0mm if that's what it's supposed to be? (and internally handle how much it needs to lift in order to be 1.0 mm above the platform). Again this is the way RC4 handled it.

Edit: attached debug output:
Marlin-RCBugFix b.txt
Marlin-rc_final_z_correction b.txt

nicksears on 22 Aug 2016

Hey @nicksears — Be sure to re-download RCBugFix and test again soon, as there have been a few tweaks in this area. And if you still see issues, please test this othere branch too…

This one now adjusts Z based on the homing position:
https://github.com/thinkyhead/Marlin/tree/rc_fix_leveling_maths

thinkyhead on 28 Aug 2016

@nicksears have you retested?

boelle on 3 Sep 2016

Just finished (sorry, I got it to work with RC4 so I've been in
dissertation-writing mode)

The original RCBugFix (after RC7) with my minimal changes give me a height
of ~0.69 after G28 and G29. However, even after bringing it down to 0 it's
nowhere near two sheets of paper, more like 4. Same issue as before.

It looks like "Marlin-rc_final_z_correction" works ok. It gives me a
position of ~0.83 and is appropriately tight at 0.20-0.25 with two sheets
of paper.

"Marlin-rc_fix_leveling_maths" gives me an error "'bed_level_matrix' was
not declared in this scope" and I haven't been able to figure out why so I
haven't been able to test it.

On Sat, Sep 3, 2016 at 3:24 PM, Bo Herrmannsen [email protected]
wrote:

@nicksears https://github.com/nicksears have you retested?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/4612#issuecomment-244567922,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGTjvC_yOsZFpV_fM4Hl9VqeaFehNmaXks5qmdd7gaJpZM4JjLVy
.

Nick Sears, M.S.
Ph.D. Candidate
Biomedical Engineering
Texas A&M University '10
832-289-5518

nicksears on 5 Sep 2016

https://github.com/MarlinFirmware/Marlin/pull/4710#discussion_r77503888

Blue-Marlin on 5 Sep 2016

"'bed_level_matrix' was not declared in this scope"

Sorry, was making tweaks last night and fell asleep before checking Travis CI. Fixed.

thinkyhead on 5 Sep 2016

That one works now, too. A slightly different result ~1.04, but I think I bumped it.
Just tried a new copy (latest) of the RCBugFix and it has the same incorrect behavior as before.

To clarify, it is much too high (~1.2 and two sheets of paper become tight at a height of ~0.4 instead of 0.2) I know paper Isn't the best, but I have plenty of scrap and replace it VERY often, so I'm confident in the results.

nicksears on 5 Sep 2016

Just tried a new copy (latest) of the RCBugFix and it has the same incorrect behavior as before.

Well it hasn't been patched, so the result _should_ be the same.

thinkyhead on 5 Sep 2016

Yup, just checking. I also thought you had also said to check it again
because there had been updates.

On Mon, Sep 5, 2016 at 3:01 PM, Scott Lahteine [email protected]
wrote:

Just tried a new copy (latest) of the RCBugFix and it has the same
incorrect behavior as before.

Well it hasn't been patched, so the result should be the same.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/4612#issuecomment-244805490,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGTjvElP8Uyf2t2fPLLygI3lVk4k0JI8ks5qnHUngaJpZM4JjLVy
.

Nick Sears, M.S.
Ph.D. Candidate
Biomedical Engineering
Texas A&M University '10
832-289-5518

nicksears on 5 Sep 2016

@nicksears in general i think you should restest when you see that RCbugfix is updated

@thinkyhead is that not the strategy more or less?

boelle on 7 Sep 2016

Sure enough. But before I venture to merge my minor overhaul of bed leveling into RCBugFix I need to get more feedback from testers on the branch I linked above. That's a preview of how RCBugFix will behave. So far the results look positive, but I'm awaiting reports from a few more testers. Once it's merged we can close the several duplicate issues relating to the problem.

thinkyhead on 7 Sep 2016

I will try to test this tonight and provide some details since I am also having the issues with Z-Offset after leveling.

bleugray on 7 Sep 2016

👍1

@bleugray did it kill your machine? :-D hope it survived

boelle on 10 Sep 2016

😄1

unfortunately i didnt have time during hte week to try it. Plan is to do it today.

bleugray on 10 Sep 2016

been testing the new RCBugFix and seems to be working now. i do have an issue where the front left corner/quadrant of the bed seems to be lower than the rest of the bed while printing. had to raise z to .2mm after finding z to be -.3 otherwise it was dragging

bleugray on 11 Sep 2016

@bleugray I've been working on refining the Z position in my rc_final_z_correction branch today. Would you mind giving it a test?

If you find it acts in any way badly, please enable DEBUG_LEVELING_FEATURE and do M111 S32 to enable logging of homing and probing events. Then we can look at the log to see what's amiss.

thinkyhead on 11 Sep 2016

Working great so far. Doing a little tweaking since I am experimenting with PETG

bleugray on 11 Sep 2016

Good to hear. How long ago did you test it? Because I've been continuing to tweak today. Chances are with your setup it's using the "simplifed" Z adjustment method, which takes the last probe point as indicating the distance between the nozzle and the bed.

thinkyhead on 12 Sep 2016

@thinkyhead started testing right after you said to try it,

bleugray on 12 Sep 2016

Cool. As suggested, try again in case my changes were wrongheaded.

thinkyhead on 13 Sep 2016

which branch has all the latest updates in regards to z that should i be testing at this point. the main bugfix?

bleugray on 18 Sep 2016

@bleugray At the moment, RCBugFix has the latest code, including an updated approach to Z correction at the end of G29. I have another report (#4830) saying the Z position isn't exactly correct after G29. So I'm looking for feedback on how far off Z is with the new code, and asking people to do a full logging and post the results.

Could you do a G29 with DEBUG_LEVELING_FEATURE enabled (after M111 S255 or at least M111 S32), and post the log output? Also right after G29 try moving the nozzle down towards the bed and see if it's touching at zero, or where exactly it ends up.

I have another set of changes pending, including some potential bug fixes, so you might want to also test with that branch.

I'd do more testing myself, but I don't have a 3D printer handy at this time. I'll be here all day working on this, so I hope it will all be cleared up soon.

thinkyhead on 18 Sep 2016

sounds good. thanks for all the work you guys do. I was out this morning but hope to get some testing in tonight as an aside should i bother looking into UBL at this time? if so where to start? I am using a mendelmax3 with a mic6 10,5" x 12" aluminum bed with the bltouch at this point.

bleugray on 19 Sep 2016

as an aside should i bother looking into UBL at this time? if so where to start? I am using a mendelmax3 with a mic6 10,5" x 12" aluminum bed with the bltouch at this point.

It is in a development branch, but it might work very well for you. Give it a try and if you run into anything that doesn't make sense. just ask... You should get a response fairly quickly.

Where to start? Just cross your current settings over to the UBL Configuration.h. Make sure you can home and move the nozzle around. Then you just do a G29 P1 R to build the bulk of the Mesh. Fill in the unreachable areas with a G29 P3 R C0.0 Save and activate it with a G29 A and a G29 S1 . Then build a Mesh Validation Pattern with G26 C P O2.5 With that still on the bed, do a G29 P4 R to edit any (or all) mesh points that you want to shift. Save again with G29 S1. And you are good to go. If one iteration is not accurate enough, you can build a 2nd Mesh validation pattern and do a more precise edit.

Roxy-3D on 19 Sep 2016

I patched the Z offset code at the end of G29 earlier. Stupid typo.
The current RCBugFix should be doing much better now.

thinkyhead on 19 Sep 2016

👍1

@nicksears @tnw513 @bleugray had time to restest with latest RCBugFix?

boelle on 20 Sep 2016

@boelle I'll try to test it today

EDIT: test done. Seems that G29 works fine now. 👍

tnw513 on 20 Sep 2016

@boelle I have not. Will try in the next couple days. (hopefully tonight)

bleugray on 20 Sep 2016

I just tried the latest RCBugFix (7ae351c), and nozzle position following G28 is different than following G28->G29, again. The difference is ~200um.

Using a M851 Z offset of -2.0 results in nozzle-on-glass at Z0 after G28, while a Z offset of -1.8 is necessary for nozzle-on-glass at Z0 after G28->G29.

With the rc_fix_leveling_maths branch my Z offsets following both G28 and G28->G29 were more-or-less the same at -2.1.

bgort on 20 Sep 2016

@bgort To help track down issues like this, we ask folks to grab the latest RCBugFix, enable the DEBUG_LEVELING_FEATURE, and re-flash the firmware. Then issue the command M111 S255 before doing G28 and G29 V4 to get a complete log of homing and leveling. Please post the log output here and we can look it over to see where the problem lies.

thinkyhead on 21 Sep 2016

@thinkyhead Yeah, of course. No problem at all. I just wasn't sure - given all the recent work on this - that that was necessary in this case.

Here it is: serial-092116.txt

And my Configuration.h, in case it's relevant: Configuration.txt

bgort on 21 Sep 2016

I've been patching up some leveling issues that slipped through in recent days, so we might want to do another test after I merge #4868.

Meanwhile, looking at the log, I see that the front-left and back-right corners of your bed appear to be pulled lower than the rest. The corners are quite a bit lower than the middle where you're homing for sure. (1.626 … 1.809) I think this is throwing off the height at the end of probing, and as I look closer at the probed points, it does seem to be a main root of problem.

 +0.32215 +0.29942 +0.26295 +0.14898 +0.00000 <=== this and the opposite corner
 +0.27782 +0.29010 +0.25488 +0.24090 +0.14318      are apparently bent
 +0.22725 +0.29827 +0.29555 +0.31283 +0.19135
 +0.09542 +0.22145 +0.32498 +0.31350 +0.27953
 +0.00110 +0.16962 +0.26440 +0.28667 +0.29770

But, not the entire root.

I recently modified G29 so that the last probe point is used as a final corrective for the Z position. Since the last probed point is lower than most of the bed, the final position is being set a little higher than it would if some average were taken instead. That's why the final Z position is 15.19 — because the last probe point triggers when Z is at 1.81 (15 + 2.00 - 1.81 == 15.19).

Since your probe offset is -2.00 you would expect the Z position to be very close to 2.00 wherever the bed is level with the point where you homed Z (in the middle). And if that last point wasn't significantly lower than most others, especially the middle, that final Z wouldn't be off nearly as much. It also wouldn't matter in the case of a flat — not "curved" bed.

The bed itself may not be curved, but the XY carriage or gantry might somehow be farther from the bed at the corners, perhaps being lifted up by a tight roll of filament…

So there are a couple of things that can be done.

Your first option is to try and flatten the bed and make sure those corners aren't bent downward quite as much. This can be caused by having clips that push too much on the bed corners. (It might also be a fluke of the probe, pushing the bed down, or triggering differently in the corner spots.)

In the near future it will be possible to use automated Mesh (or "non-linear grid") Leveling, which does a better job of compensating for a rounded or warped bed, or an imperfect XY gantry. But until then, with "planar-grid" leveling, a truly flat bed and accurate gantry is essential.

All that said, the technique of taking the last probe offset as "gospel" is the proximal cause of this issue for you — and I have been thinking that this technique could lead to this kind of issue, because beds do sometimes have more warping at the corners. It's hard to decide how much to apply the final offset, and in fact in your case the correction would still be a little off in the other direction. There's not much that planar leveling can do when the bed isn't flat. It will always be off somewhere.

Z from Probe:15.19  Matrix:14.88  Discrepancy:0.31

The 15.19 is based on the last probe point. The 14.88 is based on correcting from your homing position (in the center) to the last position. 15.19 is ~0.2 off in one direction, while 14.88 brings it closer, but is still about 0.12 off in the other direction. I could modify the code to take the average between these two instead of just the final probe point, which would make the final position ~15.03, which would be pretty much right on target for your case.

So, I will make a patch and take that approach, methinks. It seems like a good middle-ground, even though it can't correct for the most warped of beds.

Meanwhile, after doing a simple G28 homing, move the nozzle close to the bed and take note of where it gets closer and farther from the bed. If it seems to be keeping a good distance, then you should look at M48 to test the reliability of your probe. Sometimes these servo arms can be a little loose, so tightening that up may be able to help.

thinkyhead on 23 Sep 2016

Thanks very much for the detailed response, and in advance for the possible future fix, @thinkyhead.

I'll definitely test again after #4868 is committed, and I'm also going to play with my bed to see if I can sort out the flatness issue. As you suggest, it may be as simple as tightening or loosening the bed glass clips. They are currently uniformly tight, but I'd guess the glass is slightly warped and that differential tightening will help.

I'm also looking forward to trying UBL soon-ish. Maybe in the next few days, even.

Will report back here what I learn/find.

bgort on 23 Sep 2016

If it seems to be keeping a good distance, then you should look at M48 to test the reliability of your probe. Sometimes these servo arms can be a little loose, so tightening that up may be able to help.

And when you do the M48, you may want to do M48 S L10 to shake the nozzle back and forth. Usually, you will get worse readings with a S L10 run than a straight up and down run of M48. Also, it would not hurt to do an M48 in those low corners and make sure the mean numbers you are getting there make sense. That will help you have confidence the bed really is warped and it isn't the nozzle or the carriage deflecting at the corner.

I'm also looking forward to trying UBL soon-ish. Maybe in the next few days, even.

If you bring up UBL with a 10 x 10 Mesh, those low corners you have won't be an issue. You will get full use of the entire bed! :)

Roxy-3D on 23 Sep 2016

👍1

A few quick updates:

Have pulled the latest (da16443) and am seeing basically the same 0.2 difference in nozzle position following G28 and G29. *_EDIT: Disregard this. I had carelessly eyeballed and was mistaken. Sorry for the confusion. Will respond to this issue again when I've sorted out what's going on with the changes. *_ Also, @thinkyhead, you missed renaming a variable in commit d0796fc @ Marlin_main.cpp:2202 - 'where' should be 'distance'.
Wasn't able to 'fix' the warped/low corner issue by adjusting the glass clips without bowing the center, unfortunately. Strongly suspect this is just a 'non-flat' bed situation.

And:

And when you do the M48, you may want to do M48 S L10 to shake the nozzle back and forth. Usually, you will get worse readings with a S L10 run than a straight up and down run of M48. Also, it would not hurt to do an M48 in those low corners and make sure the mean numbers you are getting there make sense. That will help you have confidence the bed really is warped and it isn't the nozzle or the carriage deflecting at the corner.

Thanks, Roxy. After the BLTouch-related changes @thinkyhead just made, and further M48 testing, I'm seeing pretty solid standard deviations in the center of the bed. And per your suggestion, I just did a series of M48 S L10 in the center and in all 4 corners. The standard deviations I'm seeing in the corners are mostly the same as in the center. Actually, and oddly (I think), the corners are better than the center: They're giving me 3-5um consistently w/S L10, whereas the center is 8-10um pretty consistently (while the center was averaging 5-6um yesterday - go figure). In any case, I think they're all close enough that I wouldn't be seeing such a difference with the bed leveling if the nozzle/carriage were deflecting somehow.

Though here's something odd: after I finished the corners I went back to the center and did another few 'M48 S L10's for good measure, and the first one had a standard deviation of 28um, the second 63um, the third 6um, then 18um, and then back to ~10um (repeatedly) after that. Very strange - it was really consistent before I did the corners. I imagine this is a hardware issue of some kind, but any guesses?

If you bring up UBL with a 10 x 10 Mesh, those low corners you have won't be an issue. You will get full use of the entire bed! :)

Should be able to try it out in a day or two. Thanks!

bgort on 24 Sep 2016

Though here's something odd: after I finished the corners I went back to the center and did another few 'M48 S L10's for good measure, and the first one had a standard deviation of 28um, the second 63um, the third 6um, then 18um, and then back to ~10um (repeatedly) after that. Very strange - it was really consistent before I did the corners. I imagine this is a hardware issue of some kind, but any guesses?

So I really don't know. I'm just guessing. But I think what you are seeing is the linear bearings and belts get seated better in the new position. Like I say, I don't know. But my guess is if you go back to the corner and do a few M48 S L10's and then come back to the center you will see a similar pattern repeat. That's the really hard thing about 'repeat-ability'. You would hope that the measurement of it is 'repeatable'. But even that depends on a number of things.

Roxy-3D on 24 Sep 2016

So I really don't know. I'm just guessing. But I think what you are seeing is the linear bearings and belts get seated better in the new position. Like I say, I don't know. But my guess is if you go back to the corner and do a few M48 S L10's and then come back to the center you will see a similar pattern repeat. That's the really hard thing about 'repeat-ability'. You would hope that the measurement of it is 'repeatable'. But even that depends on a number of things.

Thanks. That's the only explanation I could come up with, too. The rails, belts, etc. are 'seating' (to use the term loosely) in the new position. Not sure I can come up with another explanation.

EDIT: I'm actually having a significant mechanical or hardware problem. Not sure what's going on yet. Seeing wildly varying M48 standard deviations, etc. Will circle back to this over the weekend. Thanks again for your help.

bgort on 24 Sep 2016

Thanks for keeping in touch. Looking forward to the next report.

thinkyhead on 24 Sep 2016

Turns out a wispy piece of filament (~a hairwidth thick) had gotten stuck to the side of the BLTouch pin probe, and that was throwing things off by interfering with its motion (I imagine). Removed it, and everything went back to normal. It's the little things, apparently..

Anyway, just pulled the latest (9cebbab) and am seeing a smaller difference in required Z offsets: -2.18 for nozzle on glass following G28 alone, and -2.1 for nozzle on glass following G28 -> G29.

Here's an annotated debug log: serial-092616.txt

Will endeavor to try UBL tomorrow (er, today).

bgort on 26 Sep 2016

If you change the probe offset with M851 Z-2.1 between G28 and G29 it only skews the result in a confusing manner. I would rather you left it at 2.18 and posted that G29 log.

The thing is, that final probe point really does find the bed lower – it comes up with 1.99 as the position of the nozzle when the probe is triggered. Which means that the probe is registering 0.19mm lower at that point than it is at the homing point. If the bed is really 0.19mm lower, then the Z position should be increased by 0.19mm because the Z position is relative to the home position (at the middle of the bed).

v ---- 12.18 (nozzle final Z) ---- 12.37 v  adjusted distance by +0.19
v                                        v
v                                        v
v                                        v
------ 2.18 (nozzle height at home) ---- v
====== 1.99 (bed Z at last probe) ========

thinkyhead on 26 Sep 2016

If you change the probe offset with M851 Z-2.1 between G28 and G29 it only skews the result in a confusing manner. I would rather you left it at 2.18 and posted that G29 log.

Sorry. I didn't do the G29 after the G28 at Z-2.18 because there would have been a bed strike at Z0 (albeit a 'small' one), and I didn't figure there'd be much difference between doing G28 -> G29 at -2.1 vs. -2.18 (other than the final position). (I did redo the G28 after changing the offset to -2.1.)

Anyway, here's G28->G29 at Z-2.18: serial-092616-2.txt

(Z0 put the nozzle hard on [into] the glass, as expected.)

If the bed is really 0.19mm lower, then the Z position should be increased by 0.19mm once it's raised back up to a Z position relative to the home position (at the middle of the bed).

I'll try to use my 1um dial indicator at some point today to see if I can learn more about the bed that way. Problem is I'll have to design and print a part to properly mount it to the carriage, and I'm not sure where to attach it. EDIT: Yeah, that's not going to work. The carriage is the carriage and so any deflection or whatnot will affect the dial indicator just the same. Need coffee or something.

bgort on 26 Sep 2016

Those dial indicators are pretty helpful. Coffee even moreso.

thinkyhead on 27 Sep 2016

😄1

@tnw513 is this one still present in the latest bugfix (updates a few hours ago)?

boelle on 2 Nov 2016

@boelle unfortunately I can't test the latest bugfix sooner than 1-2 weeks.

tnw513 on 6 Nov 2016

@tnw513 np, @thinkyhead has n ot run dry for bugs to fix but i think he would still want to hear what you find out

boelle on 6 Nov 2016

I can't test the latest bugfix sooner than 1-2 weeks.

Definitely releasing 1.1.0-RC8 ~~within the week~~. We'll get lots of feedback after that, I'm sure.

thinkyhead on 7 Nov 2016

👍1

@thinkyhead would there be any difference between manual and auto bed correction ?

boelle on 20 Nov 2016

@tnw513 had time to test latest RCBugfix?

boelle on 26 Nov 2016

@boelle hopefully tomorrow

tnw513 on 26 Nov 2016

oki, i tested the manual mesh level and it works fine, but as i dont have a probe so i can't test that.

i hope that it doesn't make a difference, but the perfect 1st layer can be tricky to get just spot on

i started out with doing it at 0.3mm then 0.2 and last 0.1m. A real PITA

boelle on 26 Nov 2016

@tnw513 any luck?

boelle on 1 Dec 2016

@boelle tested. It's ok with AUTO_BED_LEVELING_LINEAR, same height as RC6. Good!

Only one thing:

Auto-home behavior is different than before, with double touch feature enabled, AFTER the first touch nozzle goes up for the same distance as Z_CLEARANCE_DEPLOY_PROBE (and then goes down slow as expected). I don't know if it is a feature.

I will try AUTO_BED_LEVELING_BILINEAR soon (My bed is not so flat). Is it a new type of auto bed level?

tnw513 on 2 Dec 2016

i think i have seen a demo of doubletouch where it goes down from deploy and then up and down again but slower.

I'm forced to use Manual bed level until after xmas as presents ate up all my pocket money.

once i have a servo and probe added i can play along fully.

but manual bed level/correction is not bad either. it just takes a lot longer :-D

@thinkyhead can you shine a few words of wisdom on this?

boelle on 2 Dec 2016

with double touch feature enabled, AFTER the first touch nozzle goes up for the same distance as Z_CLEARANCE_DEPLOY_PROBE…

It should be using Z_HOME_BUMP_MM value for the raise after the first probe in all cases. (See the run_z_probe function.)

I will try AUTO_BED_LEVELING_BILINEAR soon (My bed is not so flat). Is it a new type of auto bed level?

Previously this was the _only_ kind of bed leveling available when you enabled auto-bed-leveling on DELTA. I extended it to work on all machines. It is essentially the same as MESH_BED_LEVELING, except that it is automated.

thinkyhead on 3 Dec 2016

It should be using Z_HOME_BUMP_MM value for the raise after the first probe in all cases. (See the run_z_probe function.)

That's weird, it raises more than 2mm (at least 10mm). I'll try it again.

It is essentially the same as MESH_BED_LEVELING, except that it is automated.

👍 thanks

tnw513 on 7 Dec 2016

I have also multiple users which have 2 mm offset.

oderwat on 25 Jan 2017

Can all people which have this problem please confirm what G30 outputs after these commands:

M502
M500
M851 Z0
G28
G30

Technically G30 should in this case output something close to 0.00 +/- the tolerance of the sensor. I get reports that this does indeed output values around 2.00 (1.86 for example). I spent already hours to figure out what happens as this should not be possible at all. I even used the same code and Configuration.h on my printer and for me it works.

oderwat on 25 Jan 2017

Edit: I have since changed the ABL type to 3 point, and instead of m851 z-6.1 Im using m851 z-1.9
I came up with this after running the ABL procedure (trial and error) and -1.9 works perfectly. My aluminum bed is thin and a little wavy, but this gets it close enough that the print will have good adhesion and I do not have to turn the bloody little screws before I can print.

thanks.

Gents,

first, thanks for all your hard work!

I'm not sure if my problem is related exactly. but I am getting a Z 0 that is not correct after a g29 command. I'm going crazy, been all over github checking similar problems and trying different things(which usually works). But in this case I've been at it for 2 days and can't figure it out. I'm running skynet 2.3.1, with a fixed proximity sensor that is precisely located 10mm forward and 20 mm to the right and just slightly higher than my nozzle, and linear leveling(9points). The printer is an ANET A8, 5 button LCD. Board is an ANET V1.0.

after g28, and with a m851 z-6.1 I'm perfect. paper slid between nozzle and bed has slight resistance. Then I run g29, or g29 v4 and leave X,Y in same position as last probe. And I'm off by approx 3.7mm, that is if I step Z axis toward the bed, I have slight paper-slip-resistance when my printer thinks z is at +3.7mm, if I were to go to 0 i would crash the bed.

I have attached my full config.h, enabled and attached the debug running G28, G29, then G29 v4 (printlog), and the information oderwat requested.
CONFIG.H.txt
ODERWAT.txt
print_log.txt

ProffesorD on 11 Feb 2017

@ProffesorD Your bed seems to be too warped to produce a good flat matrix. Try using AUTO_BED_LEVELING_BILINEAR and see if you get better results.

thinkyhead on 12 Feb 2017

You are correct... I figured it out (had to dig out a straight edge). Even bilinear has a tough time. New bed ordered. Thanks again

ProffesorD on 12 Feb 2017

I am now advising people to z-offset like this:

M851 Z0 ; reset a previous offset
G28 ; just for the printer to have coordinates
G1 X110 Y110 ; nozzle into center (on my bed)
; nozzle tip onto bed
G92 Z0 ; tell printer this is z = 0
G30 X110 Y110 ; read out Bed:Z .. this is where the sensor triggers
M851 Z-Bed:Z ; store Bed:Z negated
M500 ; store everything into the eeprom

This way you probe in the same point where the nozzle is. That helped some guys to get a better Z-offset when their bed is tilt. But if the angle between nozzle and sensor trigger moves with the X axis there is nothing you can really do besides of stopping to use "auto-level" and simply level manually but still using z-probing for easier overall setup.

oderwat on 14 Feb 2017

Good tip, G92 would definately save some trial and error with m851. Also, I found that I had to set the Z offset AFTER bed leveling procedure. Not every time, but definately on the first setup I found the G29 would mess up my offset.

ProffesorD on 14 Feb 2017

Hello,
I have similar problem.
I am using Kossel XL delta printer (RAMPS 1.4) with Marlin RC8
(specifically configured for this printer, downloaded from the Anycubic Google Drive https://drive.google.com/open?id=0B8VIB533cgdMSVMxNm43aG1OQ0U)
configured with BLTouch Z probe.

G29 probes like it should, but offset is wrong afterwards, even at 0,0 (midpoint in round bed) and even if the nozzle was perfectly leveled on this point before.
Pretty much like the problem of OP.
G30 probes single point but also does not correct Z0.

Have put log of G29 into gnuplot to see if probe measurements are way off, but
seems to correctly display my bed (the extreme one in the corner was a clamp in the way and printer thought it was way more down because of motor grinding)
some slight bending going on but mostly a tilt.
http://plotshare.com/sessions/921918436/Plot1.png

Have tried to put EEPROM on, off, deleted, reloaded multiple times.

Rotated the bed.

G29 gives also deviations across multiple measurements, but not always on all points, of up to 0.3.
BLTouch seems tightly secured.

GesaP on 18 Feb 2017

@GesaP what kind of leveling are you using and are those values in the plotting mm, like +/- 2mm? That would be a lot. I would suggest you level the bed first manually and try again. You may also try to switch the leveling method. I wonder if there is a bug with leveling in a way that the G28 probing Z0 gets overridden by G29. Probably the whole G29 calculation should be normalised by the difference at the point where Z0 was taken. Or... G29 should "fail" if it is off by some amount.

oderwat on 18 Feb 2017

Hi oderwat, thanks for your reply.
I am using AUTO_BED_LEVELING_BILINEAR with the ABL_BILINEAR_SUBDIVISION turned on, but also turned off it doesn't change bad results.
If I try to switch on the other methods AUTO_BED_LEVELING_3POINT or
AUTO_BED_LEVELING_LINEAR, it won't compile because then Arduino says delta can only have bilinear.

Yes, the results in the plot are mm. Do you mean by "manually" to tilt the bed until it is somewhat accurate/turn the leveling screws or to do G30 and then M851 on every point?

And yes, my fixed delta height configured in the firmware gets overridden, but isn't that normal with the results of G29 stored in EEPROM? But my knowledge of how the printer stores the leveling results is limited (and they can't be accessed via M501).
It seems like a good idea to keep the G28 value included in the G29.

Just downloading the latest bugfix, can I just copy+paste all the files and migrate my config.h and config-adv.h changes? Maybe this will change things, though in the description it only says it fixed MBL.

GesaP on 18 Feb 2017

Used the latest bugfix now, still same behaviour.

GesaP on 21 Feb 2017

This is still an issue - i have had this for nearly a week, now with no reliable results.
with G29 z0 I get a better distance, but the correction rotation isn't enough, or is inverted....

prusa I3, rumba.

rhinorap on 23 Feb 2017

I have the same issue with marlin 1.1.8

Blisk on 24 Jul 2018

I have the similar issue where it performs the auto bed levelling and if you get a piece of paper and check height it is fine but when you attempt to print it is approx 2-3mm off the bed, however this no longer is the issue when you turn off stealthchop and run the steppers noisy. works fine at that point. Just putting my problem out there, heck I even downloaded the latest version, changed my drivers over, recompiled and init the eprom and still exactly the same issue with bltouch 3.1 so I am at a loss but printing with noisy stepper motors.

DoneWorld on 30 May 2020

Hi all.

I see this old thread is closed but people are still seeing the issue.

I have the same with my Ender 3 and Marlin 2.0.5.3

Anyone found a solution already?

TravellingTechGuy on 25 Jun 2020

Yeah I found the Z-Offset issue is related to some sort of driver problems namely with stealth chop but not limited to that alone.

I originally had 2130 steppers and used the stepper drivers for those and in stealth chop it had the issue, I tried, with square wave, I tried with current settings (which made it better but still random issues), I tried with 0.9 deg steppers and 1.8 deg steppers and it was more obvious on 0.9 deg steppers, none the less anything I tried was still inaccurate with stealth chop mode on. (Finally found that S-Curve = off and Junction Deviation = off as well as Stealth Chop = off was the only way to get good performance and accurate prints and z-offset issues went away)

When I changed the stepper drivers to 5160's the problem went away, at this point I also noticed an issue that I had with the Hemera E3D direct drive unit went away, the Hemera use to click randomly at higher speeds making me think my maximum feed rate was lower than it is now, my printing of Nylon can be done at 120mm/s where as before the maximum was 80mm/s and printing of PLA can be done at 150mm/s where before maximum was 100mm/s so mathematically I gained 50% more performance with the new drivers that use a different driver set in the firmware.

Anyone who wants to challenge my finding can simply get those drivers and compare the two based on what I have placed above for information because I cant go back now as it put me out of action for 4 weeks chopping and changing.

The issue with S-Curve and Junction Deviation is a separate issue to the Z-Offset but two issues made it all that harder to work out.

Summary: 2130 Driver issue when using stealth chop and attempting maximum speeds increases problems and using stealth chop is impossible, this does not happen with 5160 drivers. Junction Deviation and S-Curve are separate issues to the inaccuracies of z-offset as those settings will mainly cause zitting issues and blobs on corners where speed changes on bends and hard corners effect the print quality and reverting back to original acceleration setting and classic jerk solve that issue and are not driver related.

DoneWorld on 26 Jun 2020

Please test the bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

thinkyhead on 26 Jun 2020

Same here. Tested latest bugfix-2.0.x branch, with TMC2209 (UART Mode) and BLTouch (Triangelab Clone, May 2020) the Z-Offset is completely wrong after a G29.

Tested the current scenarios, all failing at the end due to a wrong z-offset when print starts:

Stealthchop ON, Fade Leveling ON, Bilinear Bed Leveling
Stealthchop ON, Fade Leveling OFF, Bilinear Bed Leveling
Stealthchop OFF, Fade Leveling OFF, Bilinear Bed Leveling
Stealtchop ON, Unified Bed Leveling
Stealtchop OFF, Unified Bed Leveling

Various combinations of S-Curve and LinAdvance doesn't seem to afflict the problem, at least in my case.

While using Unified Bed Leveling I managed to "guess" by trial-and-error a usable value for Probe Z-Offset so that the first layer wasn't either printing in mid-air or scraping the bed. But of course, the value is completely wrong to what can be found with the proper calibration.

While using Biniliear Bed Leveling instead, the only thing that made a difference was the "fade at height" option: if it was enabled, the print started far away from the bed; when disabled, the nozzle scratched the bed during the first layer. Manually adjusting the Z-Offset via baby-stepping would lead to a successful print, but that should not be the case scenario when using a probe and a bed levelling system.

NeoMod on 1 Jul 2020

For what it is worth, I went back to 1.1.9 with this build below and don’t have the issue anymore on my Ender 3.

https://www.danbp.org/p/en/node/136

TravellingTechGuy on 1 Jul 2020

@NeoMod — It would be better to post a new issue. General issues like "leveling is weird" can be due to any number of bugs, not necessarily the same bug that was involved in this August 2016 issue.

thinkyhead on 3 Jul 2020

Had the same issue today with Marlin 2.06 on a Anet A8 after messing about with the capacitive sensor position.
Followed the Z probe offset calibration procedure and yet every print was roughly 0.5mm above the bed.
Turned out the sensor is pretty sensible to temp changes, do your G28, z probe offset and G29 with the bed and nozzle at print temperature (in my case 45 with 195 ). Problem solved !!!

catalinbuica on 10 Oct 2020

Marlin: Incorrect Z position after Auto Bed Leveling (HOME is fine)

All 122 comments

define Z_PROBE_DEPLOY_HEIGHT 15

define Z_PROBE_TRAVEL_HEIGHT 15

Related issues