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

[silvio-didonna]

As title when i issue G28 all is ok. Test with paper passed (some friction). after send G29 the nozzle is higher than it should be. The same paper pass freely between the nozzle and the bed. I don't know if there is a problem with my config file but seems ok.

Step to reproduce: -Home (from display or G28) //////////////////////////////////////optional -Move Z to 0 -Move X and Y to center with a paper between nozzle and bed (position is ok) ///////////////////////////////////// -Auto bed leveling (from display or G29) -Move Z to 0 -Move X and Y with a paper between nozzle and bed (position is too high)

Latest RCBugFix: @405afec Printer: Prusa i3 Hephestos Configuration.txt

PS: same behavior with RC7. OK with RC6. PPS: EEPROM activated (restored, reloaded ecc). I've tried to increment the distance between the probe and the nozzle (both in configuration file and EEPROM) and when with G28 the nozzle scratch the paper (obviously), with G29 the paper pass without friction.

[silvio-didonna]

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

[nicksears]

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.

[bgort]

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

[silvio-didonna]

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

[bgort]

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

[silvio-didonna]

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

[adamfilip]

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

[aljscott]

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.

[Roxy-3D]

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?

[adamfilip]

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

[Roxy-3D]

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.

[nicksears]

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.

[adamfilip]

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.

[aljscott]

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.

[Roxy-3D]

(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]

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]

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

[Blue-Marlin]

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.

[silvio-didonna]

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

[Blue-Marlin]

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

[silvio-didonna]

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.

[Blue-Marlin]

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]

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.

[adamfilip]

@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

[Roxy-3D]

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.

[silvio-didonna]

@Blue-Marlin

New log: log08172016-2.txt

Matrix seems non altered. But it is not symmetric.

[Blue-Marlin]

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

[silvio-didonna]

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

[Roxy-3D]

@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;
}

[Blue-Marlin]

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.

[Roxy-3D]

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!

[nicksears]

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.

[thinkyhead]

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

[silvio-didonna]

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

[thinkyhead]

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]

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.

[silvio-didonna]

@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

[thinkyhead]

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]

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

[silvio-didonna]

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

[thinkyhead]

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

[silvio-didonna]

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.

[thinkyhead]

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.

[Roxy-3D]

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

[silvio-didonna]

@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

[Roxy-3D]

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.

[nicksears]

@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

[thinkyhead]

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

[boelle]

@nicksears have you retested?

[nicksears]

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 notifications@github.com 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