-
-
Notifications
You must be signed in to change notification settings - Fork 19.3k
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
Comments
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. |
please let us know as soon you can |
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 I'll try and isolate the code where this is happening. |
Have you set your probe Z offset correctly? Bed levelling should change the On 27 December 2014 at 16:30, imqqmi notifications@github.com wrote:
|
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. |
imqqmi: I think you're correct in your assumption. I would expect much |
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: |
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. |
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. |
Surely rounding errors should not be cumulative with absolute gcode? On 28 December 2014 at 10:50, imqqmi notifications@github.com wrote:
|
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. |
Summing up the things that I've tried:
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 ;) Quick and dirty fix: 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! |
The ABLG code should produce a pure rotation matrix with no scaling. Have you tried 3 point levelling, which avoids the qr_solve? |
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. |
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. |
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. |
i think you can see grid as X number point ABL :-D |
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. |
i agree to that... i just made a dummies compare on them... 3 is plenty |
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. |
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. |
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?? |
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 I run 3x3 grid because it compensates small glass deviations due heating or Feel free to remove the 3 single points probing... but the grid will stay. Cheers. Alex.
|
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. |
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:
|
Some guys prefer/have better results with 3 single probing, others with Let the user pick which one he prefer. Cheers. Alex.
|
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:
|
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. :-)
|
@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. @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. 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. |
@imqqmi 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, |
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
|
@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. |
In the beginning of G28 and G29 there is the Cheers. Alex. 2014-12-31 12:55 GMT-02:00 brainscan notifications@github.com:
"Não é o mais forte da espécie que sobrevive, nem o mais inteligente. É Alex Borro |
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
|
Nice thanks Alex, didn't know that. Sent from my iPhone
|
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! |
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
|
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! |
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: 30.00 y: 50.00 z: -0.20 ABLG Glass plate 2, 2 clamps Bed x: 30.00 y: 50.00 z: -0.29 Bed x: 30.00 y: 50.00 z: -0.30 ABLG Glass plate 1, 4 clamps Bed x: 30.00 y: 50.00 z: -0.58 Bed x: 30.00 y: 50.00 z: -0.60 ABLG Glass plate 1, 2 clamps Bed x: 30.00 y: 50.00 z: -0.25 Bed x: 30.00 y: 50.00 z: -0.25 |
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. |
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. |
Is this one still a bug or has the issue been solved? |
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:
My setup doesn't experience the problem anymore in any case. |
I don't believe the behavior I have seen is a bug or even a vaild use case (multiple G29s) |
I’m glad you could find a proper solution to this ;) De : imqqmi [mailto:notifications@github.com] Yes! I've done another dry run and the results are consistent! Thanks a lot — |
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! |
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. |
@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). |
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. |
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.
The text was updated successfully, but these errors were encountered: