Iterative Bed Leveling: 1st run always off

droftarts

@DonStauffer regarding always having an offset, the probe points are relative to the homed position. If your homing position is in the middle of your bed, and your bed has a slight bow in it, then the probe points will be both be positive (or negative). The bed levelling tries to level the plane between the probe points, and resets the height at the bed origin. So a subsequent homing shifts that plane again, and then the probe points are higher or lower the next time round.

At least, that’s my understanding!

Ian

oliof

@DonStauffer said in Iterative Bed Leveling: 1st run always off:

If I run G32 again right away, again the first 3 points are off by about 0.025 mm. That seems wrong. If the end of the last leveling showed all 3 points were where they should be, how did the bed move down a quarter mm? I know it didn't, but that seems to be what it's saying.

As Andy pointed out, that's only 1/40th of a millimeter, not 1/4th. lets assume you have a Z axis with 80mm/step at 16x microstepping. In that case, a single step would be 12.5microns, or 0.0125mm. That means the deviation of 0.025mm between those three steppers is a just 2 microsteps or double the thickness of a thick strand of hair.

You may get better repeat results with rehoming after leveling the bed as Andy said, and reducing your probe dive speed (and increasing acceleration, which also increases decelerations IIUC) for more accurate stoppage at sensing the bed.

DonStauffer

@gloomyandy I thought my edit took care of that. My brain slipped when I called it a quarter mm. It's 0.025 mm.

DonStauffer

@oliof It's not that it 's a huge amount. I'm trying to understand the process and why, when I iteratively get the level really close, to where successive iterations are refining things much closer than that, running G32 again seems anything but a "continuation" of that process. Another aspect is that where iterative leveling tends to do a sort of "seesaw" of shrinking magnitude, running a new G32 seems to show that initially all 3 screws read near the same non-zero amount, as if they all have been offset by the same amount. It's possible I'm imagining it, but I don't think so. A fair amount of the time, if nothing much has changed, this results in only 2 or 3 iterations to get back where it was - not a lot of mucking around, just adjusting all 3 by that approximate amount, where a "real situation" where there is a reason that the level isn't close does the whole seesaw thing and takes longer. It's as if a leveling run leaves it level, but starting another has the whole thing interpreted as offset a fixed amount.

Not the most important thing in the world, which is why I've let it be that way for a long time, but more recently I've been working on bed.g for another reason and that made me reconsider this.

gloomyandy

@DonStauffer See the final paragraph in my previous answer. Are you resetting z=0 after you running G32? I suspect that what you are seeing is an offset from your homing point and the plane through your G32 points. Especially if the error is the same for all three points. You could try making your Z=0 setting point be one of the 3 points you probe for G32 and see if that changes things.

DonStauffer

@gloomyandy I may have brought up too many peripheral issues, some of which are not important.

So distilled, here's my question: My bed.g has a loop, so G32 probes 3 points iteratively, until the error stats are "good enough". I've attached a spreadsheet from the downloaded console log from six consecutive G32 runs. The lead screw adjustment grand totals say it all. I'm skeptical that the lead screw were actually adjusted this much, I've been working on LED display during bed leveling, so I've been running dozens of levelings with nothing in between, no printing, and not even heating. Only sometimes cycling the power and homing. But these 6 were back to back.

Bed Leveling.xlsx

The way I read this, it keeps adjusting and adjusting, cumulatively. By now my bed should be against the ceiling (or would it be the floor?)

"Are you using the probe to set Z=0 on your printer?"
I was assuming homing did that. There's no Z microswitch on my machine. I use a BLTouch. Should I be changing the Z param on my G31 line in config.g? I usually set that by homing, then G1 X150 Y150 Z0.5, then moving up or down with G1 until a 0.5 feeler gauge slides under the clean nozzle with minimal drag. I note the difference between the Z coordinate reported on the display vs. 0.5, then change the G31 line Z value by the difference, in the appropriate direction. I repeat that, then do the whole thing again with the bed hot and the nozzle warm. Do I need to do that more carefully? If I do it inaccurately, could that be the cause each of of repeated G32 runs seeming to start at an offset?

"If so are you resetting that Z=0 point after performing G32?"
Not sure. I know some people have a final probe in bed.g. Someone once told me to put this after the loop so I did, but I honestly don't know what it does or why the X and Y parameters are there since they don't do anything:
G30 X150 Y150 Z-99999
So I recently added G1 X150 Y150 F5000 before this.

What is the purpose of that final probe, and what parameters would it normally have?

"Is the point you probe to set Z=0 the same as any of the points that you use to perform the G31 action?"
No, this is in bed.g, so it's to even up the lead screws for bed leveling.

DonStauffer

@droftarts But these are the adjustment figures after each loop of bed leveling. I put a spreadsheet in another reply that shows the cumulative adjustments growing with each G32. The grand total of adjustments over 6 runs of G32:

-0.046 -0.098 -0.02

There was no G28 or anything else in between those 6 runs. The bed was probably leveled 4 dozen times before that with nothing happening in between - an odd situation because I was working on some LED progress displays.

This isn't that the bed was off that much from the beginning; the first G32 run had adjustments totaling 0.004, -0.008, & -0.002, and the largest single adjustment was 0.037. The major contributor to the totals is often the first time through the loop, but it's the cumulative totals that seem very weird. It seems like the first loop of each G32 run is most of what is driving a constantly increasing adjustment grand total. There are exceptions but looking at the data instead of just my impressions, there are of course outliers, but the net effect seems to be that each G32 run adjusts all 3 lead screws by an average of about 0.015, and it's cumulative. The -0.02 cumulative total on the 3rd lead screw seems to suggest the 3rd lead screw is acting differently. If so, that is an interesting oddity I can't explain.

That seems impossible. And wouldn't the first loop of bed.g make any homing in between irrelevant? See why I'm confused?

DonStauffer

@oliof Reconsidering dive speed and acceleration sounds like something I should do. Just as a starting place, what values do you find to be reasonably accurate for probing? I have a BLTouch. Even a guess would give me a starting place.

oliof

@DonStauffer You could always do an M48 run (M48 is not natively part of RRF but several macros float around on the forum) with different values until you find what works best for you. With a BLTouch I personally wouldn't go faster than 10mm/sec dive speed; possibly as low as 6mm/sec.

gloomyandy

@DonStauffer I think you should post your config.g bed.g and homez.g files

You might also want to try running some tests to see how repeatable the results are from your z probe. That test can also be used to help you decide what acceleration and dive speed.

The purpose of that final probe is to reset your Z=0 (though I'm not sure what that G30 X150 Y150 Z-99999 will actually be doing, I suspect it may just be storing the value in p0, but I may be wrong). The normal way to do this would either be to run G28 Z or to position the probe and run just a plain G30. You need to do this because the adjustments made to level the bed will mean that Z=0 is no longer valid.