Auto bed leveling grid on/off Z height difference

[imqqmi]

Just found out after printing a 20x20x50mm empty cube that the Z height is different when I do only a G28 before printing or G28 + G29 before printing. The difference is about 3mm (46.54mm vs 49.54mm). I've repeated the test to be sure and indeed the only setting that was changed was the auto bed leveling.

Is this a known bug? The firmware seems to be from before 14-11-2014 (dd-mm-yyy). I'm printing with a Prusa i3 and a RAMPS 1.4 board.

[nophead]

No the the magnitude of the vectors, not the sum, should be one. That is the square root of the sum of the terms squared. I.e. they should be normalised unit vectors.

So it looks about right to me, given to resolution of floats. In particular the scale of compensated Z is very close to model Z: 0.99999 : 1

The repeatability of your probe looks poor compared deviation you want to measure but I can't see any explanation for the height being 7% off.

On 31 December 2014 at 11:17, Bo Herrmannsen notifications@github.com wrote:

i will upgrade this to a verified error as it seems there really is an error

Reply to this email directly or view it on GitHub https://github.com/ErikZalm/Marlin/issues/1244#issuecomment-68436428.

[imqqmi]

Thanks guys! I'm looking forward to @galexander1 assessment too.

I've made some adjustments to the z wire guide, added some rubber to the nut so it fits really snugly. Sure enough the Z probes are more consistent by a factor of about 3. Deviation without rubber min/max was 0.01 to 0.15mm (average of 3 probe sets). With rubber is min/max: 0 to 0.047mm, also 3 probe sets (consisting of the 9 readings per probe set so 27 readings). I've also slowed down the probe Z motion when it's taking a reading by a factor of 2.

I'm glad you've pointed out to me the Z axis sloppiness! Could it be that the Z axis turns, but the nut doesn't push the carriage up or down immediately while the software thinks it is moving. So moving up and down constantly like the ABLG forces it to do will give a netto error with each up/down combination of motion resulting in a reduced height. Could you confirm that this assessment is correct?

Here is a graph of what I'm talking about:

If the ABLG forces the last Z motion to be downwards just before going to the next layer (large Z motion) it could add up to the 7% that I'm seeing. For a 25mm object to be 23.25mm 25-23.25 = 1.75mm. With a layer height of 0.3 there are 83 layers for 25mm So each layer looses 1.75/83 = 0.021mm

The thing is this doesn't happen in 3P ABL because there's no Z motion between layer movements and with ABLG there is. It can also explain why with one object the height was correct in ABLG, because the last Z motion could've been upward so there was no 'Z nut slop'. It only happens when the last ABLG Z motion before layer movement was downwards. I think we've solved another mystery ;)

[nophead]

Backlash in the Z axis should give a fixed error, not one that increases linearly with height.

Three point levelling should give Z motion between layers just the same as grid. They both result in a rotation matrix. The only difference is the rotation will be very slightly different if the bed isn't flat as the plane is the best compromise through all points instead of an exact plane through three points. So the maths and motion after the matrix has been filled in should be exactly the same with a very slightly different rotation.

[imqqmi]

@nophead you've got a good point. I will do another test with 3P ABL and see what the matrix looks like and compare it to ABLG.

[wgm4321]

I was doing some printing last night and having all sorts of problems getting the first layer right. I'm beginning to suspect that my glass is slightly higher in the center where the homing position resides.

The ABL points are the four corners which seem to be lower.

So I wonder if it is some combination of the home position not being included in the ABL and the averaging of the error when the plane is fitted to the measured points. On the second G29, the current position has been adjusted by the fitted plane and then the points are re-measured from this adjusted value causing a cumulative error.

[brainscan]

Did you ever answer which z steps you have in firmware and eeprom? I've been getting confused with the two different values you've been using. I still don't understand why you have two z step values? Are you switching them when you switch between 3 point and grid? How can it be a bug in marlin if it's only affecting one or two people and for everyone else it's fine?

Sent from my iPhone

On 31 Dec 2014, at 13:04, imqqmi notifications@github.com wrote:

Thanks guys! I'm looking forward to @galexander1 assessment too.

I've made some adjustments to the z wire guide, added some rubber to the nut so it fits really snugly. Sure enough the Z probes are more consistent by a factor of about 3. Deviation without rubber min/max was 0.01 to 0.15mm (average of 3 probe sets). With rubber is min/max: 0 to 0.047mm, also 3 probe sets (consisting of the 9 readings per probe set so 27 readings). I've also slowed down the probe Z motion when it's taking a reading by a factor of 2.

I'm glad you've pointed out to me the Z axis sloppiness! Could it be that the Z axis turns, but the nut doesn't push the carriage up or down immediately while the software thinks it is moving. So moving up and down constantly like the ABLG forces it to do will give a netto error with each up/down combination of motion resulting in a reduced height. Could you confirm that this assessment is correct?

Here is a graph of what I'm talking about:

If the ABLG forces the last Z motion to be downwards just before going to the next layer (large Z motion) it could add up to the 7% that I'm seeing. For a 25mm object to be 23.25mm 25-23.25 = 1.75mm. With a layer height of 0.3 there are 83 layers for 25mm So each layer looses 1.75/83 = 0.021mm

The thing is this doesn't happen in 3P ABL because there's no Z motion between layer movements and with ABLG there is. It can also explain why with one object the height was correct in ABLG, because the last Z motion could've been upward so there was no 'Z nut slop'. It only happens when the last ABLG Z motion before layer movement was downwards. I think we've solved another mystery ;)

— Reply to this email directly or view it on GitHub.

[alexborro]

@wgm4321 if your glass is slightly concave or convex, you need to probe the center as well, so use a 3x3 matrix.

Cheers.

Alex.

2014-12-31 11:50 GMT-02:00 wgm4321 notifications@github.com:

I was doing some printing last night and having all sorts of problems getting the first layer right. I'm beginning to suspect that my glass is slightly higher in the center where the homing position resides.

The ABL points are the four corners which seem to be lower.

So I wonder if it is some combination of the home position not being included in the ABL and the averaging of the error when the plane is fitted to the measured points. On the second G29, the current position has been adjusted by the fitted plane and then the points are re-measured from this adjusted value causing a cumulative error.

— Reply to this email directly or view it on GitHub https://github.com/ErikZalm/Marlin/issues/1244#issuecomment-68442666.

"Não é o mais forte da espécie que sobrevive, nem o mais inteligente. É aquele que se adapta melhor as mudanças" ( Charles Darwin )

Alex Borro

[wgm4321]

@alexborro OK, I'll try that and see if the measurements creep on additional G29s.

I think I need to switch to an inductive probe. It's just so heavy. I wonder if I can strip the metallic shell to reduce it's weight. I don't know if the shell is critical to it's function.

[imqqmi]

@brainscan: The z-steps are the same in firmware and eeprom. Correct, for 3P ABL I use 4040.7 and 4325.7 for ABLG. I've confirmed that the FW Z_STEPS do absolutely nothing to the printed object heights.

When I do a find in files search in TextPad the only other reference to DEFAULT_AXIS_STEPS_PER_UNIT is in file configurationstore.cpp (aside from the configuration.h and in the examples folder which is not used). The define is only used when resetting to default (or when the eeprom is empty with a fresh arduino board I guess). After that the EEPROM is read and the define is ignored.

I will retest the heights as soon as I finish work and see if these values are still valid since I improved the Z axis nut slack.

[brainscan]

I'll have to see what happens with mine when I get home as I've never run G29 straight after G29. I'm interested to see what the output is but I'm wondering why this would ever happen? Do you get the same results running G28, G29, G28, G29 etc. I'd never done two G29's in a row as it's not something you would really want it to do and it states you must run G28 first so curious how this came up in the first place? I thought G28 had to be executed first in order to reset the correction matrix so running G29 straight after a G29 would give inconsistent results, wouldn't it?

Sent from my iPhone

On 31 Dec 2014, at 13:50, wgm4321 notifications@github.com wrote:

I was doing some printing last night and having all sorts of problems getting the first layer right. I'm beginning to suspect that my glass is slightly higher in the center where the homing position resides.

The ABL points are the four corners which seem to be lower.

So I wonder if it is some combination of the home position not being included in the ABL and the averaging of the error when the plane is fitted to the measured points. On the second G29, the current position has been adjusted by the fitted plane and then the points are re-measured from this adjusted value causing a cumulative error.

— Reply to this email directly or view it on GitHub.

[imqqmi]

@brainscan: you're correct, when doing G29 after the one before it will indicate that you need to do a G28 first. Since this is the case, isn't it more logical to do a G28 automatically when giving the G29 command as G28 is implied?

[brainscan]

What? Sorry I have ONE value that never changes for my z steps, it's 2560. It's the same whether I use no bed leveling or 3 point or grid. That value is fixed, it doesn't change. I have 16x micro stepping with M8 rod and 1.8° steppers, that gives me 2560 steps per mil. That doesn't change. Are you switching out your lead screws each time you try 3 point or grid? What setup gives 4040.7 steps per millimeter and 4325.7 steps and how is it on the same machine?!?!?

Sent from my iPhone

On 31 Dec 2014, at 14:22, imqqmi notifications@github.com wrote:

The z-steps are the same in firmware and eeprom. Correct, for 3P ABL I use 4040.7 and 4325.7 for ABLG. I've confirmed that the FW Z_STEPS do absolutely nothing to the printed object heights.

When I do a find in files search in TextPad the only other reference to DEFAULT_AXIS_STEPS_PER_UNIT is in file configurationstore.cpp (aside from the configuration.h and in the examples folder which is not used). The define is only used when resetting to default (or when the eeprom is empty with a fresh arduino board I guess). After that the EEPROM is read and the define is ignored.

I will retest the heights as soon as I finish work and see if these values are still valid since I improved the Z axis nut slack.

— Reply to this email directly or view it on GitHub.

[imqqmi]

@brainscan: Yeah, that's the mystery I'm facing ;) It's calculated to be 4000 but then the printed height isn't correct. I use plain cheap M5 rods. That was what's in the kit for the Prusa i3. Maybe I'll swap to TR8 trapezoidal rods.

[brainscan]

My capacitance probe is lighter than my old servo and endstop and easier to setup. Pretty sure the case makes up part of the circuit so altering it would change the characteristics of the probe. It might increase or decrease the sensitivity or could kill it altogether. I could be wrong about that though as its not something I've tried or looked into.

Sent from my iPhone

On 31 Dec 2014, at 14:21, wgm4321 notifications@github.com wrote:

@alexborro OK, I'll try that and see if the measurements creep on additional G29s.

I think I need to switch to an inductive probe. It's just so heavy. I wonder if I can strip the metallic shell to reduce it's weight. I don't know if the shell is critical to it's function.

— Reply to this email directly or view it on GitHub.

[wgm4321]

As far as G28 before G29, it is true that you must perform G28 first. However, you can successively issue G29s more than once after the G28.

If that is not a normal use case then one solution to the issue I see is just prevent G29s after the initial G28/G29 sequence.

[brainscan]

That probably would make sense although I'd hate it to cause a problem further down the line with something else. It would probably be more effort than its really worth as its not something that gets in the way or is inconvenient.

Sent from my iPhone

On 31 Dec 2014, at 14:26, imqqmi notifications@github.com wrote:

@brainscan: you're correct, when doing G29 after the one before it will indicate that you need to do a G28 first. Since this is the case, isn't it more logical to do a G28 automatically when giving the G29 command as G28 is implied?

— Reply to this email directly or view it on GitHub.

[brainscan]

If 4000 is what is calculated then that's what should be entered. I only use cheap threaded rods and have no problems with print heights. If you don't have a consistent z step value how is anyone going to hunt down where the problem is? What happens if you try a print with the number that's supposed to be there? Then try the same print one with 3 point one with grid and the same z step value for both. There's no point saying one is shorter than the other if you've been using different settings for each one. You need to try and minimize any changes between the two prints so the only thing that changes is whether it's 3 point leveling or grid. You wouldn't change the x steps from 80 to 100 and expect it to be the right size would you?

Sent from my iPhone

On 31 Dec 2014, at 14:36, imqqmi notifications@github.com wrote:

@brainscan: Yeah, that's the mystery I'm facing ;) It's calculated to be 4000 but then the printed height isn't correct. I use plain cheap M5 rods. That was what's in the kit for the Prusa i3. Maybe I'll swap to TR8 trapezoidal rods.

— Reply to this email directly or view it on GitHub.

[brainscan]

It doesn't really need to be prevented other than by the user, in the start code you wouldn't put G28, G29, G29, G29 ...... You would only ever put G28, G29 ..... Still not sure why this came up.

Sent from my iPhone

On 31 Dec 2014, at 14:39, wgm4321 notifications@github.com wrote:

As far as G28 before G29, it is true that you must perform G28 first. However, you can successively issue G29s more than once after the G28.

If that is not a normal use case then one solution to the issue I see is just prevent G29s after the initial G28/G29 sequence.

— Reply to this email directly or view it on GitHub.

[imqqmi]

@brainscan: Maybe you should reread the thread from the start as that's what I've been doing. I've compared the height results between 3P ABL and ABLG with the same Z_STEP height. Regardless of the actual Z_STEP number, one would expect the resulting print to be the same and it's not. There's no variation in height when I print 10x with ABLG or 10x with 3P ABL so the height between prints is consistent. Only switching between 3P ABL and ABLG gives a height change. For now I've 'fixed' it by changing the Z_STEP to be at least able to print something regardless of the underlying problem. I've found slack in the Z-Guide nut which I've now fixed. When time allows I'll retest the printed Z height and see if I can now use 4000 as Z_STEP. Hopefully this has been the root cause of the problem, but as nophead stated, it probably isn't.

[alexborro]

In the beginning of G28 and G29 there is the command: plan_bed_level_matrix.set_to_identity(); It reset all the ABL data, so no matter how many G29 commands you issue, the results are suppose to be the same.

Cheers.

Alex.

2014-12-31 12:55 GMT-02:00 brainscan notifications@github.com:

It doesn't really need to be prevented other than by the user, in the start code you wouldn't put G28, G29, G29, G29 ...... You would only ever put G28, G29 ..... Still not sure why this came up.

Sent from my iPhone

On 31 Dec 2014, at 14:39, wgm4321 notifications@github.com wrote:

As far as G28 before G29, it is true that you must perform G28 first. However, you can successively issue G29s more than once after the G28.

If that is not a normal use case then one solution to the issue I see is just prevent G29s after the initial G28/G29 sequence.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/ErikZalm/Marlin/issues/1244#issuecomment-68446141.

"Não é o mais forte da espécie que sobrevive, nem o mais inteligente. É aquele que se adapta melhor as mudanças" ( Charles Darwin )

Alex Borro

[brainscan]

That's exactly what I've been doing, and from the comments I was totally confused. I kept seeing you were using two values for z step but couldn't see how you'd got to that point. I understand you've altered them to be able to print something but I think from a diagnostic point of view when trouble shooting you need to stick to the true value. The way the comments are written it seemed like you were using two different z steps and then blaming marlin that they didn't match up. Makes more sense now.

Would it help if you tried someone else's copy of marlin that is known to work to see if it's something that's crept in or has always been there? I did it before with some people when we had trouble setting bed leveling a while ago and it helped point to the problem.

Sent from my iPhone

On 31 Dec 2014, at 15:14, imqqmi notifications@github.com wrote:

@brainscan: Maybe you should reread the thread from the start as that's what I've been doing. I've compared the height results between 3P ABL and ABLG with the same Z_STEP height. Regardless of the actual Z_STEP number, one would expect the resulting print to be the same and it's not. There's no variation in height when I print 10x with ABLG or 10x with 3P ABL so the height between prints is consistent. Only switching between 3P ABL and ABLG gives a height change. For now I've 'fixed' it by changing the Z_STEP to be at least able to print something regardless of the underlying problem. I've found slack in the Z-Guide nut which I've now fixed. When time allows I'll retest the printed Z height and see if I can now use 4000 as Z_STEP. Hopefully this has been the root cause of the problem, but as nophead stated, it probably isn't.

— Reply to this email directly or view it on GitHub.

[brainscan]

Nice thanks Alex, didn't know that. Lee

Sent from my iPhone

On 31 Dec 2014, at 15:44, alexborro notifications@github.com wrote:

In the beginning of G28 and G29 there is the command: plan_bed_level_matrix.set_to_identity(); It reset all the ABL data, so no matter how many G29 commands you issue, the results are suppose to be the same.

Cheers.

Alex.

2014-12-31 12:55 GMT-02:00 brainscan notifications@github.com:

It doesn't really need to be prevented other than by the user, in the start code you wouldn't put G28, G29, G29, G29 ...... You would only ever put G28, G29 ..... Still not sure why this came up.

Sent from my iPhone

On 31 Dec 2014, at 14:39, wgm4321 notifications@github.com wrote:

As far as G28 before G29, it is true that you must perform G28 first. However, you can successively issue G29s more than once after the G28.

If that is not a normal use case then one solution to the issue I see is just prevent G29s after the initial G28/G29 sequence.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/ErikZalm/Marlin/issues/1244#issuecomment-68446141.

"Não é o mais forte da espécie que sobrevive, nem o mais inteligente. É aquele que se adapta melhor as mudanças" ( Charles Darwin )

Alex Borro — Reply to this email directly or view it on GitHub.

[imqqmi]

Ok, preliminary results are in! I did a dry run that I've done before without actually extruding anything, in ABLG mode, an object that's supposed to be 25.05mm high. With Z_STEPS still at 4325.7 the print was too high. This is looking promising! So I set Z_STEPS to 4000 as it's supposed to and the head stopped around 25.0, well as exact as I could measure with an printed object from another test under it with a height of 24.25mm with a gauge of 0.8mm it exactly fit under the nozzle.

So I think it was the slack between the nut and the z carriage that was the culprit. With a bit of bicycle inner tube rubber it's a snug fit and the results seem to speak for themselves. I will do some more testing comparing 3P ABL and ABLG tomorrow after the headaches wear off ;)

Thanks a lot and best wishes everyone!

[brainscan]

That's pretty good news! Nice one for locating the culprit. Its definitely worth remembering incase other people have similar issues. I had a problem that took me weeks to find, it was so frustrating. Hopefully you can have some fun printing now.

Lee

Sent from my iPhone

On 31 Dec 2014, at 17:39, imqqmi notifications@github.com wrote:

Ok, preliminary results are in! I did a dry run that I've done before without actually extruding anything, in ABLG mode, an object that's supposed to be 25.05mm high. With Z_STEPS still at 4325.7 the print was too high. This is looking promising! So I set Z_STEPS to 4000 as it's supposed to and the head stopped around 25.0, well as exact as I could measure with an printed object from another test under it with a height of 24.25mm with a gauge of 0.8mm it exactly fit under the nozzle.

So I think it was the slack between the nut and the z carriage that was the culprit. With a bit of bicycle inner tube rubber it's a snug fit and the results seem to speak for themselves. I will do some more testing comparing 3P ABL and ABLG tomorrow after the headaches wear off ;)

Thanks a lot and best wishes everyone!

— Reply to this email directly or view it on GitHub.

[imqqmi]

Yes! I've done another dry run and the results are consistent! Thanks a lot guys for putting me on the right track! I've been at this for days! @brainscan: Agreed! A great start of the new year! Oh man, seems like everything that could go wrong with this printer went wrong. Every step in the right direction had to be won. But I'm loving the experience on the whole, learned a lot!

[imqqmi]

Still good news but my interpretation was wrong. I've swapped glass plates when I did my last test, I was going to print ABS on vinyl which has so far been the best adhesive that I've tried. The other plate was for hairspray and glue stick test.

I thought the z axis nuts looseness were the cause. while it did slightly improve layer height as I can now more precisely do the first layer (was always about half the height it should've been).

Apparently the way glass plate 1 with vinyl was shaped/bend/flexed made ABLG reduce the size of about 7%. At the moment I swapped the glass plate to #2 the height was really close to the target.

I couldn't get the glass plates flatter and both had a bend over the diagonal (flexing, or torsion). I've now used a 1.5mm aluminium plate that I've shaped and bend until the probing indicated less than 0.07 deviation. Glass plate couldn't get below 0.25. Measured Z height during ABLG was between 0.46 and 0.61.

Now it seems to work consistently after 4 ABS 20x20x25mm cubes with exactly the same height of 24.85mm. I'd say that's close enough for now, up from 23.30mm.

The gist of the story is that the bed needs to be as flat as a pancake. It may be at an angle as a whole but the surface can't be bend or have torsion/flex shape or it may cause some height issues.

I've also experimented with the number of clamps on the glass plate. 2 improved the flatness compared to 4 clamps. Of course the contact the the heatbed isn't as good so heat is not as even on the glass plate. That's also why I switched to aluminium, even if it doesn't have a great contact the heat transfer spreads the heat more evenly.

Here are the probings and M499 values (multiplied by 1000 so you can see the actual values). I took two G29 for each plate and number of clamps 2 or 4, there are 8 sets of values:

ABLG glass plate 2, 4 clamps

Bed x: 30.00 y: 50.00 z: -0.19 Bed x: 87.00 y: 50.00 z: -0.06 Bed x: 144.00 y: 50.00 z: 0.12 Bed x: 145.00 y: 100.00 z: 0.28 Bed x: 88.00 y: 100.00 z: 0.08 Bed x: 31.00 y: 100.00 z: -0.24 Bed x: 30.00 y: 150.00 z: -0.27 Bed x: 87.00 y: 150.00 z: -0.01 Bed x: 144.00 y: 150.00 z: 0.37 Eqn coefficients: a: 0.00 b: 0.00 d: -0.44 planeNormal x: -0.00 y: -0.00 z: 1.00 echo:endstops hit: Z:0.37 echo:ok 999.99,0.00,4.31,-0.00,1000.00,0.71,-4.31,-0.71,999.99.

Bed x: 30.00 y: 50.00 z: -0.20 Bed x: 87.00 y: 50.00 z: 0.01 Bed x: 144.00 y: 50.00 z: 0.11 Bed x: 145.00 y: 100.00 z: 0.26 Bed x: 88.00 y: 100.00 z: 0.05 Bed x: 31.00 y: 100.00 z: -0.22 Bed x: 30.00 y: 150.00 z: -0.29 Bed x: 87.00 y: 150.00 z: 0.11 Bed x: 144.00 y: 150.00 z: 0.37 Eqn coefficients: a: 0.00 b: 0.00 d: -0.44 planeNormal x: -0.00 y: -0.00 z: 1.00 echo:endstops hit: Z:0.37 echo:ok 999.99,0.00,4.27,-0.00,1000.00,0.89,-4.27,-0.89,999.99.

ABLG Glass plate 2, 2 clamps

Bed x: 30.00 y: 50.00 z: -0.29 Bed x: 87.00 y: 50.00 z: -0.01 Bed x: 144.00 y: 50.00 z: 0.13 Bed x: 145.00 y: 100.00 z: 0.31 Bed x: 88.00 y: 100.00 z: 0.10 Bed x: 31.00 y: 100.00 z: -0.28 Bed x: 30.00 y: 150.00 z: -0.38 Bed x: 87.00 y: 150.00 z: 0.07 Bed x: 144.00 y: 150.00 z: 0.38 Eqn coefficients: a: 0.01 b: 0.00 d: -0.52 planeNormal x: -0.01 y: -0.00 z: 1.00 echo:endstops hit: Z:0.38 echo:ok 999.99,0.00,5.15,-0.00,1000.00,0.78,-5.15,-0.78,999.99.

Bed x: 30.00 y: 50.00 z: -0.30 Bed x: 87.00 y: 50.00 z: -0.02 Bed x: 144.00 y: 50.00 z: 0.11 Bed x: 145.00 y: 100.00 z: 0.29 Bed x: 88.00 y: 100.00 z: 0.04 Bed x: 31.00 y: 100.00 z: -0.32 Bed x: 30.00 y: 150.00 z: -0.44 Bed x: 87.00 y: 150.00 z: 0.04 Bed x: 144.00 y: 150.00 z: 0.34 Eqn coefficients: a: 0.01 b: 0.00 d: -0.54 planeNormal x: -0.01 y: -0.00 z: 1.00 echo:endstops hit: Z:0.35 echo:ok 999.99,0.00,5.29,-0.00,1000.00,0.55,-5.29,-0.55,999.99.

ABLG Glass plate 1, 4 clamps

Bed x: 30.00 y: 50.00 z: -0.58 Bed x: 87.00 y: 50.00 z: -0.15 Bed x: 144.00 y: 50.00 z: 0.22 Bed x: 145.00 y: 100.00 z: 0.45 Bed x: 88.00 y: 100.00 z: -0.05 Bed x: 31.00 y: 100.00 z: -0.41 Bed x: 30.00 y: 150.00 z: -0.42 Bed x: 87.00 y: 150.00 z: 0.12 Bed x: 144.00 y: 150.00 z: 0.60 Eqn coefficients: a: 0.01 b: 0.00 d: -0.98 planeNormal x: -0.01 y: -0.00 z: 1.00 echo:endstops hit: Z:0.60 echo:ok 999.97,0.00,7.89,-0.02,1000.00,2.68,-7.89,-2.68,999.97.

Bed x: 30.00 y: 50.00 z: -0.60 Bed x: 87.00 y: 50.00 z: -0.14 Bed x: 144.00 y: 50.00 z: 0.21 Bed x: 145.00 y: 100.00 z: 0.47 Bed x: 88.00 y: 100.00 z: 0.02 Bed x: 31.00 y: 100.00 z: -0.39 Bed x: 30.00 y: 150.00 z: -0.39 Bed x: 87.00 y: 150.00 z: 0.17 Bed x: 144.00 y: 150.00 z: 0.62 Eqn coefficients: a: 0.01 b: 0.00 d: -1.00 planeNormal x: -0.01 y: -0.00 z: 1.00 echo:endstops hit: Z:0.62 echo:ok 999.97,0.00,7.86,-0.02,1000.00,3.09,-7.86,-3.09,999.96.

ABLG Glass plate 1, 2 clamps

Bed x: 30.00 y: 50.00 z: -0.25 Bed x: 87.00 y: 50.00 z: 0.02 Bed x: 144.00 y: 50.00 z: 0.13 Bed x: 145.00 y: 100.00 z: 0.34 Bed x: 88.00 y: 100.00 z: 0.12 Bed x: 31.00 y: 100.00 z: -0.21 Bed x: 30.00 y: 150.00 z: -0.30 Bed x: 87.00 y: 150.00 z: 0.15 Bed x: 144.00 y: 150.00 z: 0.48 Eqn coefficients: a: 0.01 b: 0.00 d: -0.53 planeNormal x: -0.01 y: -0.00 z: 1.00 echo:endstops hit: Z:0.48 echo:ok 999.99,0.00,5.01,-0.01,1000.00,1.42,-5.01,-1.42,999.99.

Bed x: 30.00 y: 50.00 z: -0.25 Bed x: 87.00 y: 50.00 z: -0.01 Bed x: 144.00 y: 50.00 z: 0.13 Bed x: 145.00 y: 100.00 z: 0.31 Bed x: 88.00 y: 100.00 z: 0.07 Bed x: 31.00 y: 100.00 z: -0.25 Bed x: 30.00 y: 150.00 z: -0.35 Bed x: 87.00 y: 150.00 z: 0.10 Bed x: 144.00 y: 150.00 z: 0.42 Eqn coefficients: a: 0.00 b: 0.00 d: -0.52 planeNormal x: -0.00 y: -0.00 z: 1.00 echo:endstops hit: Z:0.42 echo:ok 999.99,0.00,4.98,-0.01,1000.00,1.02,-4.98,-1.02,999.99.

[imqqmi]

I've found another weak point in my hardware: the tube connecting the Z motor to the rod. I've tried tightening it with zip ties but there was still too much play to my taste and replaced it with an aluminium coupler. These changes have the negative effect that the wobble of the rod translates to the head but I'll fix that another day. The grid probing is now even more accurate with a deviation of 0.01mm down from 0.03 to 0.05. The values I now get are much different, much farther apart.

I found out the tube was a weak link in the chain because I wanted to try full step instead of 1/16th step. The motor turned really slowly (seemed like it ignored the jumper change on the RAMPS board). But I did notice the tube slipping at that slow turning rate.

So another day of testing how this will affect my prints. I'll keep you posted.

[imqqmi]

Printing with 3P ABL or ABLG height of a 25mm object printed 24.5. And that there no difference between the two, which is good! I'm have suspicion that the z rods may not be exactly 0.8mm. I've found a source for trapezoidal rods, probably going to be 8mm. I'll have to do some mods to the prusa i3 but I think/hope this should fix the errors once and for all.

[boelle]

Is this one still a bug or has the issue been solved?

[imqqmi]

If no one else can reproduce it then it must be my printer hardware that's to blame. Still, there might be a bug that lowers the height if the print bed isn't very flat. That's something that should be fixed first in any case of course.

Anyway if anyone is willing to look into it, they can use the bed level probe values I've posted earlier and plug them into ABLG and see what the output is when printing a single walled test cube.

The steps I've taken to resolve my hardware was:

1. Fix the play/backlash in the nut in the x motor part that's on the Z axis (may introduce wobble if the rod isn't straight, stainless steel/ACME/trapezoidal rods recommended)
2. Get rid of the PTFE tube that connects the Z motor to the Z rod. Mine slipped, and when fixed with zip ties torsion on the tube gave backlas/play. Replace with aluminium coupler. These #1 and #2 fixes increased consistency and accuracy of the probing ten fold.
3. Use the ABLG probe readings in pronterface to get an idea how unlevel the bed is and try to level it. use only two clamps to clamp on the glass or metal plate as four will bend it if the backing isn't flat (by backing I mean heatbed or any other plate behind the printbed).

My setup doesn't experience the problem anymore in any case.

[wgm4321]

I don't believe the behavior I have seen is a bug or even a vaild use case (multiple G29s)

[nicolas-rambaud]

I’m glad you could find a proper solution to this ;)

De : imqqmi [mailto:notifications@github.com] Envoyé : mercredi 31 décembre 2014 19:13 À : ErikZalm/Marlin Cc : Nicolas Rambaud Objet : Re: [Marlin] Auto bed leveling grid on/off Z height difference (#1244)

Yes! I've done another dry run and the results are consistent! Thanks a lot guys for putting me on the right track! I've been at this for days! @brainscan https://github.com/brainscan: Agreed! A great start of the new year! Oh man, seems like everything that could go wrong with this printer went wrong. Every step in the right direction had to be won. But I'm loving the experience on the whole, learned a lot!

— Reply to this email directly or view it on GitHub https://github.com/ErikZalm/Marlin/issues/1244#issuecomment-68459099.[image: Image supprimée par l'expéditeur.]

[imqqmi]

Thanks @nicolas-rambaud! I've bought stainless steel M5 rods which look much better than the zinc alloys. Also a lot straighter so I have good hope it will eliminate the wobble as well. I couldn't get hold of trapezoidal rods of 5 or 8mm, only 10mm, which may be a bit too heavy for the stepper motors, and more difficult to find couplers and adjusting the parts. The M5 stainless steel rods are a drop in replacement and should be easy to do.

I'll report back when I've installed them and if the height deviation (still using Z_STEP of 4052) has been solved.

Cheers!

[wgm4321]

Can this be closed? I believe that both of us that reported behaviors as a bug now agree that we aren't seeing a bug.

[imqqmi]

@wgm4321 agreed, I will close it.

As promised I'd report back when I've replaced the Z rods. I've compared the rods and can see a slight offset in the thread. The cheap ones threads travel a shorter distance per turn compared to the stainless steel one.

The height is better. With Z_STEPS at 4000 the height is 24.65. It's pretty close to the 24.85mm it should've been. I can probably compensate it with Z offset.

I've scanned the rods. The cheap rod is a factor 0.9985375 too small per turn while the stainless steel is 1.001975 off of 1. So in theory I should put in a smaller number in the Z_STEPS. 1/1.001975 * 4000 = 3995.2.

I'm now at 4012 Z_STEPS printing on target at 24.85mm (asked for, and printed). Here's the scan if you're interested, the dots represent 10 turns in the thread for easy counting and measuring, scanned at 1200 dpi. To convert from pixels to mm use pixels/dpi*2.54, upper rod is zinc, lower one is stainless steel:

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.