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.

[imqqmi]

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]

please let us know as soon you can

[imqqmi]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[imqqmi]

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]

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]

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]

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

[nophead]

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]

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

3 is plenty

[imqqmi]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

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

[alexborro]

@imqqmi, as Nophead said, it doesn't compensate for curvature, it fits the best plane, minimizing all errors, not eliminating them.

And about Z_STEP.. it is a deterministic variable, not an empirical one... You should NOT calibrate it; instead, just calculate the steps/mm - you may use a calculator like this: http://prusaprinters.org/calculator/.

If you try to "calibrate" any axis steps/mm (X, Y or Z), you will be just working around a bug and introducing a new one. DO NOT DO THAT!.

For example, for a Z axis with a 1.8º stepper, 1/16th microstep driver and a M5 0.8mm pitch threaded rod, you MUST set Z steps/mm at 4000. Period! If you are having wrong print heights, your problem is anywhere else, NOT in the Z Steps/mm.

Cheers.

Alex.

[boelle]

@alexborro i have followed this one for a while and i figured that @imqqmi have a bent bed....

but do i get it wrong that he thinks that auto level should make up for that too?

and this makes me think that this is not an issue with marlin but rather that the bed is not flat?

[nophead]

But if the object comes out the correct height with three points but is 7% shorter with grid levelling it implies there is a bug in the grid levelling. What other explanation is there?

On 29 December 2014 at 11:42, Bo Herrmannsen notifications@github.com wrote:

@alexborro https://github.com/alexborro i have followed this one for a while and i figured that @imqqmi https://github.com/imqqmi have a bent bed....

but do i get it wrong that he thinks that auto level should make up for that too?

and this makes me think that this is not an issue with marlin but rather that the bed is not flat?

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

[alexborro]

The BAL can just workaround SMALL non-flatness.. I mean, it fits the best PLANE possible minimizing the errors.

You can print the first layer with a 0.05mm error, but not a 0.2mm error.

If you bed has the lowest point at 0.02mm and the highest at 0.08mm, you can fit a line at 0.05mm.. The highest deviation will be 0.03mm.

Cheers.

Alex. Em 29/12/2014 09:42, "Bo Herrmannsen" notifications@github.com escreveu:

@alexborro https://github.com/alexborro i have followed this one for a while and i figured that @imqqmi https://github.com/imqqmi have a bent bed....

but do i get it wrong that he thinks that auto level should make up for that too?

and this makes me think that this is not an issue with marlin but rather that the bed is not flat?

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

[bkubicek]

grid leveling as I implemented it first in the bed level branch compensates for curved beds. And, that is a good thing, its not to very difficult to avoid if one does not go the glass-bed path. Glass is flat, but is a terrible heat conductor, hence from a thermal point of view a horrible choice. Glass should be very very thin, e.g. 0.4 mm, and then its also flexible, leading to the same problems. Further explenation of this POV is here: http://wiki.ultimaker.com/Heated_Bed

The existance of my inital implementation is probably why people think that grid leveling compensates for that. But, seemingly it does not. The ideal method, as proposed by Joris van Tubergen IIRC, is to compensate bed inaccuracies by stronger and weaker extrusion in combination with local height changes, but this process is gradually stopped within the first few layers (e.g. max deviation*2). By that, the prints bottom will be not flat, but the print after a given height not perform z-changes after a given height...

It should be in the code, IMHO....

Bernhard

On Mon, Dec 29, 2014 at 12:42 PM, Bo Herrmannsen notifications@github.com wrote:

@alexborro https://github.com/alexborro i have followed this one for a while and i figured that @imqqmi https://github.com/imqqmi have a bent bed....

but do i get it wrong that he thinks that auto level should make up for that too?

and this makes me think that this is not an issue with marlin but rather that the bed is not flat?

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

[boelle]

just a small side Q..... i use an mirror from ikea.... does the metal backing help anything ?

[bkubicek]

no, that has zero thermal impact, not even for radiative dissipation. Also, any solid metal under the glass does not change the problem I described. If you want to continue, lets discuss on skype (bkubiat) or OTL mail (lastname at gmx.at) sorry for any thread hijacking...

Bernhard

On Mon, Dec 29, 2014 at 12:56 PM, Bo Herrmannsen notifications@github.com wrote:

just a small side Q..... i use an mirror from ikea.... does the metal backing help anything ?

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

[boelle]

me sorry too.... :-) just wanted a quick word if it made a difference

[brainscan]

Finally I understand why mine compensates for my curved aluminium bed, thought I was going mad. I thought that was what it was meant to do so I've been getting really confused why people have been saying it doesn't compensate for curvature. Thanks Bernhard.

Sent from my iPhone

On 29 Dec 2014, at 11:54, Bernhard Kubicek notifications@github.com wrote:

grid leveling as I implemented it first in the bed level branch compensates for curved beds. And, that is a good thing, its not to very difficult to avoid if one does not go the glass-bed path. Glass is flat, but is a terrible heat conductor, hence from a thermal point of view a horrible choice. Glass should be very very thin, e.g. 0.4 mm, and then its also flexible, leading to the same problems. Further explenation of this POV is here: http://wiki.ultimaker.com/Heated_Bed

The existance of my inital implementation is probably why people think that grid leveling compensates for that. But, seemingly it does not. The ideal method, as proposed by Joris van Tubergen IIRC, is to compensate bed inaccuracies by stronger and weaker extrusion in combination with local height changes, but this process is gradually stopped within the first few layers (e.g. max deviation*2). By that, the prints bottom will be not flat, but the print after a given height not perform z-changes after a given height...

It should be in the code, IMHO....

Bernhard

On Mon, Dec 29, 2014 at 12:42 PM, Bo Herrmannsen notifications@github.com wrote:

@alexborro https://github.com/alexborro i have followed this one for a while and i figured that @imqqmi https://github.com/imqqmi have a bent bed....

but do i get it wrong that he thinks that auto level should make up for that too?

and this makes me think that this is not an issue with marlin but rather that the bed is not flat?

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

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

[nicolas-rambaud]

Have you checked that on your Z axis the nutz are still in proper shape?

After a while it happens that either the nut or the thread itself might get too old and you might have some slippery at the lower part of our threaded rod.

It happened to me once and I had some Z height issues also.

After changing both the Nutz and the threaded rod it all went back to normal!

De : imqqmi [mailto:notifications@github.com] Envoyé : dimanche 28 décembre 2014 11:49 À : ErikZalm/Marlin Objet : Re: [Marlin] Auto bed leveling grid on/off Z height difference (#1244)

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.

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

[imqqmi]

@Alexborro: Ok, clear. No curvature compensation, check! About the Z_STEPS,X and Y are at 80 and are spot on. The Z is 4040.7 for 3P ABL and 4325.7 for ABLG for correct height. The configuration you described matches my prusa i3 exactly. I've calibrated the motor currents according to the reprap wiki, the motor is 1.8 with 1/16 microstep. So where should I look to correct the problem if I might ask? Do I need to replace the 5mm rod for a ACME one? For now I'll leave the Z_STEPS on these values until I can resolve the problem in hardware.

@Boelle: I do have a slightly concave bed as it turns out, and when heated it may warp a bit differently. Seeing that the bed leveling is done after heating the bed, it shouldn'd be too much of a problem. The measurements are within + or - 0.1mm when the angle is compensated. Not perfect but certainly not too bad either. I am now fully aware how the bed leveling works so no expectation for compensating curvature :)

@bkubicek: So, there's limited curvature compensation after all? Or is the current version lacking this feature? It wasn't clear from your comment. No hijacking at all, I'm also interested what you think about printbeds so by all means continue the discussion here, we might learn something :)

@nicolas-rambaud: thanks for commenting. The printer is now about 1 month old and I've printed about 1kg of PLA with it so far. Not to dismiss the possibility that the nuts are bad, but wouldn't it be more inconsistent than it is now in all prints? When I do some height calibration prints they come out all consistently correct or in the case of ABLG incorrectly heigh. If it gives consistent heights, wouldn't it mean that the hardware is at least solid, but not wobbly or inaccurate caused by loose nuts? Anyway I've already got some ACME rods on the shopping list and will see if that makes a difference. Hopefully this will fix all the issues. I'll need a source though, don't know where to find these.

I've switched back to ABLG and use 4325.7 z_steps for now. It has been consistent in height so far. I've also changed the way the probing works as the servo arm with microswitch bumps into the bed each time it's retracted. I now first move it up 2mm before retracting. Weirdly the Z offset now needs to be 4mm instead of 2.3mm. But I can live with that :)

[nicolas-rambaud]

Hello, about the mechanical aspect, when the nuts or the rods starts to get old, you will have all kind of behavior.

Some time you can repeat the behavior, and some times not. You can quickly become crasy and wonder about the firmware whereas it’s the hardware that needs some maintenance.

Indeed in your case after only printing 1KG of plastic I think you can expect the mechanical part to still be OK.

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

@Alexborro https://github.com/Alexborro: Ok, clear. No curvature compensation, check! About the Z_STEPS,X and Y are at 80 and are spot on. The Z is 4040.7 for 3P ABL and 4325.7 for ABLG for correct height. The configuration you described matches my prusa i3 exactly. I've calibrated the motor currents according to the reprap wiki, the motor is 1.8 with 1/16 microstep. So where should I look to correct the problem if I might ask? Do I need to replace the 5mm rod for a ACME one? For now I'll leave the Z_STEPS on these values until I can resolve the problem in hardware.

@Boelle https://github.com/Boelle: I do have a slightly concave bed as it turns out, and when heated it may warp a bit differently. Seeing that the bed leveling is done after heating the bed, it shouldn'd be too much of a problem. The measurements are within + or - 0.1mm when the angle is compensated. Not perfect but certainly not too bad either. I am now fully aware how the bed leveling works so no expectation for compensating curvature :)

@bkubicek https://github.com/bkubicek: So, there's limited curvature compensation after all? Or is the current version lacking this feature? It wasn't clear from your comment. No hijacking at all, I'm also interested what you think about printbeds so by all means continue the discussion here, we might learn something :)

@nicolas-rambaud https://github.com/nicolas-rambaud: thanks for commenting. The printer is now about 1 month old and I've printed about 1kg of PLA with it so far. Not to dismiss the possibility that the nuts are bad, but wouldn't it be more inconsistent than it is now in all prints? When I do some height calibration prints they come out all consistently correct or in the case of ABLG incorrectly heigh. If it gives consistent heights, wouldn't it mean that the hardware is at least solid, but not wobbly or inaccurate caused by loose nuts? Anyway I've already got some ACME rods on the shopping list and will see if that makes a difference. Hopefully this will fix all the issues. I'll need a source though, don't know where to find these.

I've switched back to ABLG and use 4325.7 z_steps for now. It has been consistent in height so far. I've also changed the way the probing works as the servo arm with microswitch bumps into the bed each time it's retracted. I now first move it up 2mm before retracting. Weirdly the Z offset now needs to be 4mm instead of 2.3mm. But I can live with that :)

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

[galexander1]

Just a note inspired by Nicolas Rambaud's hardware musings...

Specifically, maybe what is happening is that it is crashing the head into the bed, but due to a mechanical slippage somewhere it is happening with such little force that it looks like the head is just gliding along the surface of the bed. Then for the next few layers, the head glides over the previous layer even as the robot is trying to put it lower. I could imagine something like that eating up 3mm.

You can probably tell a lot by looking at the layers of the printed object, probably somewhere there is a set of layers that is all bunched up, or others that are spread out too much. It would be kind of surprising to me (but not impossible) if all of the layers are just slightly thinner in the print that comes out 3mm smaller...

[nophead]

@imqqmi, stated it gives the correct height with no ABAL or 3 point ABAL but repeatedly the wrong height with grid ABAL. If that is the case it rules out all mechanical and calibration issues and points to a bug in the grid code. I don't see how you can interpret those facts in any other way.

After the probing has finished the rest of the build is identical. The only thing different is the contents of the rotation matrix will be slightly different if the bed is curved but should be identical if it is flat.

[brainscan]

Are you still changing your Z_STEP value? It seems from your comments that you still change it depending on which type of bed levelling you're using? Didn't Alex say it should be fixed to 4000 in firmware and EEPROM?

Sent from my iPhone

On 30 Dec 2014, at 17:22, imqqmi notifications@github.com wrote:

@Alexborro: Ok, clear. No curvature compensation, check! About the Z_STEPS,X and Y are at 80 and are spot on. The Z is 4040.7 for 3P ABL and 4325.7 for ABLG for correct height. The configuration you described matches my prusa i3 exactly. I've calibrated the motor currents according to the reprap wiki, the motor is 1.8 with 1/16 microstep. So where should I look to correct the problem if I might ask? Do I need to replace the 5mm rod for a ACME one? For now I'll leave the Z_STEPS on these values until I can resolve the problem in hardware.

@Boelle: I do have a slightly concave bed as it turns out, and when heated it may warp a bit differently. Seeing that the bed leveling is done after heating the bed, it shouldn'd be too much of a problem. The measurements are within + or - 0.1mm when the angle is compensated. Not perfect but certainly not too bad either. I am now fully aware how the bed leveling works so no expectation for compensating curvature :)

@bkubicek: So, there's limited curvature compensation after all? Or is the current version lacking this feature? It wasn't clear from your comment. No hijacking at all, I'm also interested what you think about printbeds so by all means continue the discussion here, we might learn something :)

@nicolas-rambaud: thanks for commenting. The printer is now about 1 month old and I've printed about 1kg of PLA with it so far. Not to dismiss the possibility that the nuts are bad, but wouldn't it be more inconsistent than it is now in all prints? When I do some height calibration prints they come out all consistently correct or in the case of ABLG incorrectly heigh. If it gives consistent heights, wouldn't it mean that the hardware is at least solid, but not wobbly or inaccurate caused by loose nuts? Anyway I've already got some ACME rods on the shopping list and will see if that makes a difference. Hopefully this will fix all the issues. I'll need a source though, don't know where to find these.

I've switched back to ABLG and use 4325.7 z_steps for now. It has been consistent in height so far. I've also changed the way the probing works as the servo arm with microswitch bumps into the bed each time it's retracted. I now first move it up 2mm before retracting. Weirdly the Z offset now needs to be 4mm instead of 2.3mm. But I can live with that :)

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

[galexander1]

@nophead I'm still not ruling out a mechanical fail, but that's a good point, I did not notice when he said 3 point ABL works. Definitely points the suspicion at grid ABL!

@imqqmi Can you give us the bed level matrix you get after performing a grid ABL G29? I haven't tried this, but I think if you add this code to Marlin_main.cpp right before the "case 999: // M999: Restart ...", then M499 will dump the bed level matrix:

case 499:
  SERIAL_ECHO_START;
  SERIAL_ECHOPGM("ok ");
  SERIAL_ECHO(plan_bed_level_matrix.matrix[0]);
  SERIAL_ECHOPGM(",");
  SERIAL_ECHO(plan_bed_level_matrix.matrix[1]);
  SERIAL_ECHOPGM(",");
  SERIAL_ECHO(plan_bed_level_matrix.matrix[2]);
  SERIAL_ECHOPGM(",");
  SERIAL_ECHO(plan_bed_level_matrix.matrix[3]);
  SERIAL_ECHOPGM(",");
  SERIAL_ECHO(plan_bed_level_matrix.matrix[4]);
  SERIAL_ECHOPGM(",");
  SERIAL_ECHO(plan_bed_level_matrix.matrix[5]);
  SERIAL_ECHOPGM(",");
  SERIAL_ECHO(plan_bed_level_matrix.matrix[6]);
  SERIAL_ECHOPGM(",");
  SERIAL_ECHO(plan_bed_level_matrix.matrix[7]);
  SERIAL_ECHOPGM(",");
  SERIAL_ECHO(plan_bed_level_matrix.matrix[8]);
  SERIAL_ECHOLNPGM(".");
  break;

And that should settle it once and for all if grid ABL produces a bad matrix. I am not sure I'm reading it right, but I think in particular that last element, matrix[8], should be 1.0 or pretty darn close!

[imqqmi]

@galexander1: I will run the bed leveling first thing in the morning on the original source code, to eliminate the chance that my changes affect this part of the code.

[wgm4321]

Hello All, I don't know if it is relevant to this discussion but I too have an issue with the ABL and was going to open a defect but thought I'd throw my observations in here.

Now I do have my own hacked probe and even code that adds a separate pin for the probe so I didn't need to hack into any cables in my Ultimaker Orig. So there is some room for imprecision when I invoke ABL

Anyway, I've observed that if I home the printer with G28 and then successively run G29 more than once, the Z values aren't within the sloppiness of my probe set up. In general, the second G29 tends to get values that are around 0.2mm different.

I peeked at the G29 case and see that it is trying to recover the untranslated Z value but I'm not sure it does. I haven't looked into the math yet.

Here are three successive G28, G29, G29 sequences. You can see my probe isn't very accurate but you can also see that the second G29 outputs smaller Z values and I don't believe these are due to the physical probe inaccuracy:

(note first G28 was issued via Pronterface's home axes so it isn't shown below:

G29 < Bed x: 15.00 y: 20.00 z: 9.19 < Bed x: 170.00 y: 20.00 z: 9.29 < Bed x: 170.00 y: 180.00 z: 9.26 < Bed x: 15.00 y: 180.00 z: 9.27 < Eqn coefficients: a: 0.00 b: 0.00 d: 9.21 < planeNormal x: -0.00 y: -0.00 z: 1.00 < echo:endstops hit: Z PROBE:9.27 G29 < Bed x: 15.00 y: 20.00 z: 8.93 < Bed x: 170.00 y: 20.00 z: 8.92 < Bed x: 170.00 y: 180.00 z: 8.93 < Bed x: 15.00 y: 180.00 z: 8.98 < Eqn coefficients: a: -0.00 b: 0.00 d: 8.94 < planeNormal x: 0.00 y: -0.00 z: 1.00 < echo:endstops hit: Z PROBE:8.99 G28 G29 < Bed x: 15.00 y: 20.00 z: 9.10 < Bed x: 170.00 y: 20.00 z: 9.11 < Bed x: 170.00 y: 180.00 z: 9.05 < Bed x: 15.00 y: 180.00 z: 9.11 < Eqn coefficients: a: -0.00 b: -0.00 d: 9.13 < planeNormal x: 0.00 y: 0.00 z: 1.00 < echo:endstops hit: Z PROBE:9.11 G29 < Bed x: 15.00 y: 20.00 z: 8.87 < Bed x: 170.00 y: 20.00 z: 8.82 < Bed x: 170.00 y: 180.00 z: 8.81 < Bed x: 15.00 y: 180.00 z: 8.85 < Eqn coefficients: a: -0.00 b: -0.00 d: 8.88 < planeNormal x: 0.00 y: 0.00 z: 1.00 < echo:endstops hit: Z PROBE:8.85 G28 G29 < Bed x: 15.00 y: 20.00 z: 9.06 < Bed x: 170.00 y: 20.00 z: 9.11 < Bed x: 170.00 y: 180.00 z: 9.09 < Bed x: 15.00 y: 180.00 z: 9.12 < Eqn coefficients: a: 0.00 b: 0.00 d: 9.07 < planeNormal x: -0.00 y: -0.00 z: 1.00 < echo:endstops hit: Z PROBE:9.13 G29 < Bed x: 15.00 y: 20.00 z: 8.90 < Bed x: 170.00 y: 20.00 z: 8.93 < Bed x: 170.00 y: 180.00 z: 8.90 < Bed x: 15.00 y: 180.00 z: 8.93 < Eqn coefficients: a: 0.00 b: -0.00 d: 8.92 < planeNormal x: 0.00 y: 0.00 z: 1.00 < echo:endstops hit: Z PROBE:8.93

Hopefully, it gives someone with more knowledge of the ABL with some clues.

It almost seems like the first probe which doesn't appear to be done under translation should be taken as the physical Z instead of trying to recover the untranslated Z from the planner. But I say this without understanding what: plan_bed_level_matrix.set_to_identity(); vector_3 uncorrected_position = plan_get_position(); returns when a previous translation has been set....

[imqqmi]

Ok, here are the results, I've done it twice, one with the original M499 code and one with the values multiplied by 1000 to see the values as they are very small and rounded off.

// marlin original SENDING:G29 Bed x: 30.00 y: 50.00 z: 1.97 Bed x: 87.00 y: 50.00 z: 2.15 Bed x: 144.00 y: 50.00 z: 2.19 Bed x: 145.00 y: 100.00 z: 2.43 Bed x: 88.00 y: 100.00 z: 2.39 Bed x: 31.00 y: 100.00 z: 2.14 Bed x: 30.00 y: 150.00 z: 2.14 Bed x: 87.00 y: 150.00 z: 2.44 Bed x: 144.00 y: 150.00 z: 2.63 Eqn coefficients: a: 0.00 b: 0.00 d: 1.72 planeNormal x: -0.00 y: -0.00 z: 1.00 echo:endstops hit: Z:2.63 M499 SENDING:M499 echo:ok 1.00, 0.00, 0.00, -0.00, 1.00, 0.00, -0.00, -0.00, 1.00.

// Marlin original, multiplied by 1000 SENDING:G29 Bed x: 30.00 y: 50.00 z: 1.94 Bed x: 87.00 y: 50.00 z: 2.04 Bed x: 144.00 y: 50.00 z: 2.15 Bed x: 145.00 y: 100.00 z: 2.37 Bed x: 88.00 y: 100.00 z: 2.33 Bed x: 31.00 y: 100.00 z: 2.07 Bed x: 30.00 y: 150.00 z: 2.10 Bed x: 87.00 y: 150.00 z: 2.52 Bed x: 144.00 y: 150.00 z: 2.77 Eqn coefficients: a: 0.00 b: 0.00 d: 1.54 planeNormal x: -0.00 y: -0.00 z: 1.00 echo:endstops hit: Z:2.77 M499 SENDING:M499 echo:ok 999.99, 0.00, 3.45, -0.01, 999.99, 4.19, -3.45, -4.19, 999.99.

So matrix[8] indeed is pretty close to 1.

Like @wgm4321 there is the usual spread in repeated probing results, though not as large as his.

I've read somewhere the the sum of the vector should be exactly 1. -3.35 + -4.19 + 999.99 = 992.45. 1000 - 992.45 = 7.55. Pretty close to the deviation that I've seen in my prints, only a factor 10 off. 7.55 / 1000 = 0.00755. But my calculations may be off and my understanding of matrices is limited.

[boelle]

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