Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auto bed leveling grid on/off Z height difference #1244

Closed
imqqmi opened this issue Dec 27, 2014 · 86 comments
Closed

Auto bed leveling grid on/off Z height difference #1244

imqqmi opened this issue Dec 27, 2014 · 86 comments

Comments

@imqqmi
Copy link

imqqmi commented Dec 27, 2014

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.

@imqqmi
Copy link
Author

imqqmi commented Dec 27, 2014

I'm checking if this has something to do with firmware hardcoded Z STEPS or EEPROM Z STEPS. Hardcoded was at 4000, EEPROM = 4040.7.

@boelle
Copy link
Contributor

boelle commented Dec 27, 2014

please let us know as soon you can

@imqqmi
Copy link
Author

imqqmi commented Dec 27, 2014

It's not related to Z STEPS. So something must be going on in calculating the auto bed leveling grid routine. I've commented out
apply_rotation_xyz(plan_bed_level_matrix, x, y, z);
in planner.ccp on line 995 but this doesn't change anything.

I'll try and isolate the code where this is happening.

@nophead
Copy link
Contributor

nophead commented Dec 27, 2014

Have you set your probe Z offset correctly? Bed levelling should change the
Z height to what it finds with the probe but it can only do that if you
specify the probe offset from the nozzle correctly.

On 27 December 2014 at 16:30, imqqmi notifications@github.com wrote:

It's not related to Z STEPS. So something must be going on in calculating
the auto bed leveling grid routine. I've commented out
apply_rotation_xyz(plan_bed_level_matrix, x, y, z);
in planner.ccp on line 995 but this doesn't change anything.

I'll try and isolate the code where this is happening.

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

@imqqmi
Copy link
Author

imqqmi commented Dec 27, 2014

I've calibrated the offset, the z offset is 2.70mm, which is about right. If it was off, the nozzle would either run into the bed or be too far off the bed to get the filament on the bed, right?

So a printed object height that's more that 1mm off is not likely to be related to offset distance. Please correct me if I'm wrong in my assumption.

@galexander1
Copy link
Contributor

imqqmi: I think you're correct in your assumption. I would expect much
less than 0.5mm difference from G29. Base layer adhesion is sensitive to
changes of around 0.2mm. I'm very curious to see what you find out!

@imqqmi
Copy link
Author

imqqmi commented Dec 27, 2014

Galexander1: Thanks for confirming. I've redone the calibration of the offset of the probe but I've got the same results. I must be missing something obvious. I've tried setting the z-offset to 0 and use G92 Z2.3 in the gcode and see if the offset has anything to do with it. No change, still 2-3mm off the height target. I'll try circumventing the z probe code by setting each probe to 2.3 and see if that changes anything.

Here's the output of the G29 command:
G29 results:
Bed x: 30.00 y: 30.00 z: 2.12
Bed x: 87.00 y: 30.00 z: 2.38
Bed x: 144.00 y: 30.00 z: 2.45
Bed x: 145.00 y: 90.00 z: 2.42
Bed x: 88.00 y: 90.00 z: 2.35
Bed x: 31.00 y: 90.00 z: 2.13
Bed x: 30.00 y: 150.00 z: 1.92
Bed x: 87.00 y: 150.00 z: 2.19
Bed x: 144.00 y: 150.00 z: 2.41
Eqn coefficients: a: 0.00 b: -0.00 d: 2.09
planeNormal x: -0.00 y: 0.00 z: 1.00
echo:endstops hit: Z:2.41

@imqqmi
Copy link
Author

imqqmi commented Dec 28, 2014

I've tried moving the printhead using gcode by alternating between x movement and z movement at the same speeds the actual printing does. The distance traveled is then correct in the z axis. But when actually printing it isn't.

I've taken out all extrusion gcode from a print job and it still has the error. It would seem that the Z axis is getting off the more it moves. Seeing as the auto bed leveling does many small movements during the x and y movements the error increases (and microsteps aren't helping either). I'll test a more complex 'air' print without extruding and see if the error gets bigger.

@imqqmi
Copy link
Author

imqqmi commented Dec 28, 2014

Just a thought: would it be helpful to add a noise function to the rounding to diffuse the error while rounding the x, y, z moition? This is a common way to increase resolution when multi sampling using an ADC.

@nophead
Copy link
Contributor

nophead commented Dec 28, 2014

Surely rounding errors should not be cumulative with absolute gcode?

On 28 December 2014 at 10:50, imqqmi notifications@github.com wrote:

Just a thought: would it be helpful to add a noise function to the
rounding to diffuse the error while rounding the x, y, z moition? This is a
common way to increase resolution when multi sampling using an ADC.

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

@imqqmi
Copy link
Author

imqqmi commented Dec 28, 2014

It shouldn't but I can imagine if the gcode has a very repetitive pattern, like printing a test cube the microstep errors may build up after many moves. I've tested it but there's no change, the cube still is too low.

I've tested a more complex object and the finished head position in the Z axis is now correct. I've sped up the process up to 300%, so that's another factor to rule out. It took 30 min in stead of an hour.

Now trying to rotate the cube 45 over the z axis and see if that helps.

@imqqmi
Copy link
Author

imqqmi commented Dec 28, 2014

Summing up the things that I've tried:

  • Test cube at 45 degrees Z axis
  • Placement on the heatbed, other locations
  • 4 point probing instead of 9 point
  • Adding a noise function of -0.5 to +0.5 to the z axis
  • Lowering Z acceleration

All the above didn't correct the z height. Changing to a larger object covering more of the printbed (I talked about more complex before, but maybe the size also matters) did seem to correct the problem. Although I've printed the fishbone + small gear and the height was off by the same relative amount as the 20x25mm testcubes I've printed. The factor is about 1.07.

Possible cause to the problem could be print bed curvature. The qr-solver could scale a small object that is on a vertex or intersection of a measurement that may scale the object somewhat in the z axis. My matrix and vector calculation skills are not that good though ;)
My bed doesn't curve that much but still it could be enough. I've put the measured points in an earlier post into Lightwave 3D and the most pronounced bed problem is that the left is lower that the right. Otherwise it's near flat.
See:
http://www.jmbfoto.nl/media/BedLeveling.jpg

Quick and dirty fix:
I've now changed the code in planner.cpp around lines 545 and 1002 and added code when ABLG is active the factor of about 1.07 is applied (I've added a #define to the configuration.h for easy adjustment). This way, should I want to revert back to manual bed leveling I don't have to change the code.

It's not pretty and not really a solution but short of running hypothetical bed measurements through the qr_solver I don't know how to track down the problem. Maybe I could take the qr_solve code and put it in a windows c++ compiler and run some tests later. Debugging through arduino dev environment is too slow for this kind of stuff.

Thanks for the help so far!

@nophead
Copy link
Contributor

nophead commented Dec 28, 2014

The ABLG code should produce a pure rotation matrix with no scaling. Have you tried 3 point levelling, which avoids the qr_solve?

@imqqmi
Copy link
Author

imqqmi commented Dec 28, 2014

Ok, I'll try 3 point leveling.

How does the rotation work? Does it calculate the average angle of the bed or per area? Is the object rotated as a whole or is the angle adjusted per area? My bed has a slight /=\ shape, front and back fractionally lower than the middle. What happens to the top of the object if it sits between two areas with a different angle? Will it be bent?

I could stick something of 1mm in the middle of the bed and do ABLG and see if that changes the height of the object more than expected.

@nophead
Copy link
Contributor

nophead commented Dec 28, 2014

With three point levelling it fits a plane through those points and rotates the object to be perpendicular to that plane. The grid levelling just samples more points and fits the best plane through those.

Your bed still needs to be flat and your axes perpendicular to each other. All the levelling does is allow the bed to be inclined relative to the axes. It doesn't compensate for a bent bed as that will always make a bent object.

I think the grid levelling causes great confusion as people assume it compensates for an uneven bed. All it does is find the best compromise.

@imqqmi
Copy link
Author

imqqmi commented Dec 28, 2014

3 point ABL works properly!

Ok, thanks for the explanation!

The reason I didn't try 3 point ABL is that I've read somewhere that it was obsolete, it was going to be replaced by grid leveling.

@boelle
Copy link
Contributor

boelle commented Dec 28, 2014

i think you can see grid as X number point ABL :-D

@nophead
Copy link
Contributor

nophead commented Dec 28, 2014

Yes but it only takes three points to define a plane. The grid scheme uses a lot of code and doesn't really achieve anything, and possibly has a bug. Your print surface needs to be flat. If it is flat then the grid should give exactly the same plane as three points gives.

My vote would be to remove it because it gives people false hope that they don't need a flat bed.

@boelle
Copy link
Contributor

boelle commented Dec 28, 2014

i agree to that... i just made a dummies compare on them...

3 is plenty

@imqqmi
Copy link
Author

imqqmi commented Dec 28, 2014

I guess I need a thicker pane of glass to fix the curvature. The heatbed is curving the 3mm glass. Not that it's too bad though but if I need something big that reach the corners I'll be in trouble.

I agree with nophead to remove the code unless the bug is fixed. It's a complex solution to a simple problem though ;)

Compensating for bed curvature would enhance bed adhesion, maybe this could be done for just the first layer, so that the rest of the object is according to spec, and only as a non default option.

@nophead
Copy link
Contributor

nophead commented Dec 28, 2014

Depending on the topology of the machine, sagging bars on the X or Y axes can make the glass appear to be curved when it is actually flat.

@boelle
Copy link
Contributor

boelle commented Dec 28, 2014

compensating for bed curvature is one thing you should not do, the print will be curved at least... print a box and it will be curved on one side.

it could also be that your bed corner post's are to close together so they bend the heat bed a bit??

@alexborro
Copy link
Contributor

We have been working on grid leveling for months and it is working fine.

I have dozen machines running this code and printing perfect without need
to level the bed.

I run 3x3 grid because it compensates small glass deviations due heating or
not perfect manufacturing. It renders a medium plane that makes the bed
adhesion great even with small deviations like 0.2mm.

Feel free to remove the 3 single points probing... but the grid will stay.

Cheers.

Alex.
Em 28/12/2014 16:01, "Bo Herrmannsen" notifications@github.com escreveu:

compensating for bed curvature is one thing you should not do, the print
will be curved at least... print a box and it will be curved on one side.

it could also be that your bed corner post's are to close together so they
bend the heat bed a bit??


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

@nophead
Copy link
Contributor

nophead commented Dec 28, 2014

0.2mm isn't a small deviation, it is huge. Even when printing 0.4mm layers I want my bed flat to within 0.05mm and preferably better for good results. I don't see how a bed with 0.2mm deviation from flat can be compensated for with a flat plane. At best it would still have +/-0.1mm.

@boelle
Copy link
Contributor

boelle commented Dec 28, 2014

cant we just agree that a curved bed will give curved prints

only fix: get a flat bed 😁

Den søndag den 28. december 2014 skrev Chris notifications@github.com:

0.2mm isn't a small deviation, it is huge. Even when printing 0.4mm layers
I want my bed flat to within 0.05mm and preferably better for good results.
I don't see how a bed with 0.2mm deviation from flat can be compensated for
with a flat plane. At best it would still have +/-0.1mm.


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

@alexborro
Copy link
Contributor

Some guys prefer/have better results with 3 single probing, others with
grid probing. That's the reason both modes are available for more than one
year.

Let the user pick which one he prefer.
By the way, both modes are well documented.

Cheers.

Alex.
Em 28/12/2014 17:46, "Bo Herrmannsen" notifications@github.com escreveu:

cant we just agree that a curved bed will give curved prints

only fix: get a flat bed 😁

Den søndag den 28. december 2014 skrev Chris notifications@github.com:

0.2mm isn't a small deviation, it is huge. Even when printing 0.4mm
layers
I want my bed flat to within 0.05mm and preferably better for good
results.
I don't see how a bed with 0.2mm deviation from flat can be compensated
for
with a flat plane. At best it would still have +/-0.1mm.


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


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

@boelle
Copy link
Contributor

boelle commented Dec 28, 2014

and i guess it later on can be made modules that the user picks?

Den søndag den 28. december 2014 skrev alexborro notifications@github.com:

Some guys prefer/have better results with 3 single probing, others with
grid probing. That's the reason both modes are available for more than one
year.

Let the user pick which one he prefer.
By the way, both modes are well documented.

Cheers.

Alex.
Em 28/12/2014 17:46, "Bo Herrmannsen" <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> escreveu:

cant we just agree that a curved bed will give curved prints

only fix: get a flat bed 😁

Den søndag den 28. december 2014 skrev Chris <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');>:

0.2mm isn't a small deviation, it is huge. Even when printing 0.4mm
layers
I want my bed flat to within 0.05mm and preferably better for good
results.
I don't see how a bed with 0.2mm deviation from flat can be
compensated
for
with a flat plane. At best it would still have +/-0.1mm.


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


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


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

@scotty1024
Copy link

I doubt there is a bug in the grid code but rather a needed upgrade in the Z axis positioning on the printer.

Are you using ACME threaded rods? The grid leveling is even more precise causing much smaller Z movements that will be far more challenging for a simple threaded rod to follow accurately.

Best solution I've seen to a curved bed with ABL is to use CURA's raft (so you can actually peel it off). The curve makes a messy essentially curved raft and you get a flat object so long as the raft is thicker than the curve.

I've been very impressed with prints I get using Printrbot's MIC6 aluminum beds and 1mm sheet "Kapton". The aluminum spreads the heat much more evenly than glass (improving adhesion). The aluminum is thick enough that the heated bed PCB is warping instead of the bed. And the MIC6 flatness is more than good enough for 3 point ABL (which is faster).

Plus I don't have to worry about pulling up part of the glass or having the bed shatter after repeated thermal cycling. Corning needs to make Gorilla Glass 3D print beds. :-)

On Dec 28, 2014, at 9:51 AM, imqqmi notifications@github.com wrote:

I guess I need a thicker pane of glass to fix the curvature. The heatbed is curving the 3mm glass. Not that it's too bad though but if I need something big that reach the corners I'll be in trouble.

I agree with nophead to remove the code unless the bug is fixed. It's a complex solution to a simple problem though ;)

Compensating for bed curvature would enhance bed adhesion, maybe this could be done for just the first layer, so that the rest of the object is according to spec, and only as a non default option.


Reply to this email directly or view it on GitHub.

@imqqmi
Copy link
Author

imqqmi commented Dec 28, 2014

@nophead: To the naked eye the bed looks as flat as a pancake :) I use a ruler that is known to have a straight edge and there's a very small amount of curvature visible with the small edge on the bed.

@boelle: Compensating for bed curvature could be useful if the user doesn't have a better bed yet. It could be useful in some cases depending on the need for the printed object. It would be great to be able to choose from the LCD menu what bed leveling is set. I've drilled out the corner posts so it should fit without warping.

@alexborro: Maybe I'm jumping the gun a bit. I'm sure it works very well, though I am puzzled by the difference between 3 point leveling and grid leveling. 3 point is the same as no auto bed leveling, it seemed to me that grid was off a bit. So what you're saying is that you have both working without adjusting Z-STEPS? Maybe both give consistent but different results, calibrating the Z_STEPS on either gives good results but are not interchangeable.
Interesting, you say that 3x3 compensates for small deviations, does this mean that each area has it's own angle? This is different from what nophead said: 'The grid levelling just samples more points and fits the best plane through those.'.
Could you point me to the documentation please? I've been looking to find how ABLG works but couldn't find any documentation about it (except the science paper like document on qr_solve that is beyond my skills to comprehend, a general overview how it is applied in ABL would be great).

@scotty1024: No, I'm using cheap rods :) But I'll put ACME rods on the shopping list. Still this doesn't explain the difference between the two ABL modes though.
The raft option is also interesting, so what you say is that cura will make a raft of specified thickness before printing the actual object? This imposes some post processing but in some cases could be preferable. But essentially you still end up with a curved side.
I've considered getting an aluminum plate 3mm, heat transfer is much better than glass, weight should be about the same. I've also looked into resistance wire for a higher wattage output and faster heating.
I use vinyl sheets for good adhesion. It self-sticks to the glass at 60 degrees C. For PLA this has worked really well and the glass is still in tact after hours of printing (plain cheap frame glass). Gorilla glass would be great :) I've read somewhere you could get an ipad glass (repair kit) which basically is gorilla glass and cut it up to size. It's rather thin though.

For now I'm satisfied with 3 point ABL and I'll do some testing with ABLG to see how consistent it works with Z_STEPS adjustment. If it turns out it compensates for the small curvature deviations then I might settle for that.

@nophead
Copy link
Contributor

nophead commented Dec 28, 2014

@imqqmi
It doesn't compensate for curvature. The grid levelling returns a simple rotation matrix just the same as the 3 point method and the code after that uses it is exactly the same way. The only difference is that it is a least squares fit of the best plane, whereas 3 points gives one unambiguous plane.

If the Z height of the object changes with grid levelling it must have a bug that makes the Z entry in the matrix too small. It should be very very close to 1 for any reasonable angle of tilt and together with the contributions from X and Y have a magnitude of exactly 1.

@scotty1024,
Good luck getting a piece of 3mm aluminium tooling plate as flat as a 3mm sheet of float glass.

@brainscan
Copy link

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
Copy link
Author

imqqmi commented Dec 31, 2014

@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
Copy link
Contributor

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
Copy link

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
Copy link

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
Copy link
Author

imqqmi commented Dec 31, 2014

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
Copy link

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
Copy link
Author

imqqmi commented Dec 31, 2014

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
Copy link
Author

imqqmi commented Jan 1, 2015

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
Copy link
Author

imqqmi commented Jan 2, 2015

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
Copy link
Author

imqqmi commented Jan 2, 2015

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
Copy link
Contributor

boelle commented Jan 2, 2015

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

@imqqmi
Copy link
Author

imqqmi commented Jan 2, 2015

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 Move distance shouldn't include E when XYZ are moving. #1 and Hi #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
Copy link
Contributor

wgm4321 commented Jan 3, 2015

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

@nicolas-rambaud
Copy link
Contributor

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
Copy link
Author

imqqmi commented Jan 6, 2015

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!

@boelle boelle added this to the Bug Fixing Round 3 milestone Jan 6, 2015
@wgm4321
Copy link
Contributor

wgm4321 commented Jan 12, 2015

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
Copy link
Author

imqqmi commented Jan 12, 2015

@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:
Zinc VS stainless steel rods

@github-actions
Copy link

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.

@github-actions github-actions bot locked and limited conversation to collaborators Apr 20, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants