Mesh Bed Leveling Support

[w1ebr]

I am not sure where to ask the question, but, is any form of multi-point bed leveling coming in the near future? Thank you!

[Westra]

First of all,

Great work! heard about it and had to install it, one evening later it is up and running and printing better and quieter then before. Hopefully my TMC2100 will arrive soon, very curious about the sound performance. So far its the best upgrade I have done (and yes i had it for only a few days now, but i will continue to print with it).

coming back to bed levelling, I build my printer with a difficult/non-adjustable bed, because the z probe and auto level did a wonderful job. I too am very interested in bed levelling, I'm not a programmer (just some very basic Arduino stuff) but I can test stuff on my printer (H-bot with an inductive z probe). Again thanks for this great project.

[KevinOConnor]

There's a lot of interest in auto bed leveling, so I'm sure it will happen. I don't have any kind of time frame for it though.

[w1ebr]

Hi Kevin, I thought about this a bit and I am wondering if you see the problem to be solved the same way I do.

The simple case of a flat bed that is not level in either the x and/or y directions could be compensated for by post-processing the slicer's gcode to include a z coordinate and then passing the modified gcode to your software. Handling bed warping or a "bump map" would require more sophisticated post-processing capable of segmenting the single gcode linear extrusion into several smaller extrusions with individual z axis destinations. Is this what your code would have to do if it handled bed leveling? Does this imply that bed leveling processing could be a step that occurs between the slicer and your code and might be a good way to keep any implementation from messing up your code?

Gene

[hg42]

I think the general case of a bump map like leveling could indeed be handled on the gcode layer. But this would have to handle all the gcode pecularities like switching absolute/relative positioning, offsets for any axis, etc.

The bed leveling must be tied to the real bed position, usually defined by some hardware = end stops.

Between the virtual coordinate system of the gcode and the steppers are several layers. The leveling implementation could be inserted as a new layer above any layer that uses the real coordinate system. As you already said, a longer single straight move would have to be split into several segments to create a curved move instead.

Note, the leveling must be in the same coordinate system where the bump map was measured either directly or transformed from the real measurements. Which might complicate the whole thing.

Then there is still the question, why everyone wants this to be solved by software and hence accept the "bump mapped" bottom surface on every print instead of using a proper flat heated bed... (which already assumes the bump map is faded out by height, otherwise the whole print would even show the bump map). My perception is, that manufacturers push bed leveling, because they can sell cheaper hardware when everybody accepts that. There are methods to prevent or adjust sagging (I never would accept a "bump map"). Better or thicker materials or a better construction create some costs and adjustments take some time, both not wanted by the manufacturer. Instead the burden is given to the user, who buys bed level sensors etc. to find a so called solution that still leads to bad prints (in my opinion).

Or in simpler words: Why do you want to print a cup/vase/whatever that wiggles instead of standing flat on a table?

[jakep82]

In the US you can get a 6 pack of 12" x 12" (305mmx305mm) mirror tiles for $10. I've seen a lot of concern about only using borosilicate glass, but I've cycled one of these tiles from 20C to 80C and back dozens of times with no issues. They're dead flat, and I get perfect first layers across the entire surface. I actually stopped using my BLTouch and went back to a simple endstop switch because the probing wasn't necessary.

[w1ebr]

"Bed leveling" does more than handle a bed which is not flat, it also handles flexion in the x and/or y gantries. My 280 mm x axis deflects about 50 microns at the center. For a >= 0.2 mm layer height, it doesn't matter much. At ~0.1 mm layer height, it can make a difference in adhesion to the bed. For <=0.05 mm layer height, it is critical. Bed leveling also compensates for this.

[hg42]

makes more sense with that layer height... may be I would use a thicker first layer or a raft.

I just noticed that segmenting is also needed for sagging. So a "bump map" is the same according to segmenting. Obviously, it needs more work with the calculation, array of points etc.

[Westra]

It's true, bed leveling is not a solve-it-all solution. Good printer design and materials are necessary for high quality prints. My printed is a milled flat aluminium plate coated with PEI, however i'm still interested in compensating the slight tilt in the system. I only used 3 point leveling, because i build the z axis without adjustment which resulted in a stiffer construction.

Regarding the wiggling print, I believe Prusa has a pretty solution, they compensate the leveling of the bed in the first few layers. After that the print is level.

[hg42]

@Westra you probably do not want to move Z all the time while printing...

I also have a PEI coated (diffused) aluminum plate (8mm). Mine is 3-point adjustable though. Currently I use springs and screws that are exactly vertical (to prevent shifting of the bed while printing) but I am thinking of leveling screws without springs.

I could also use three lead screws to do a physical leveling instead of constantly moving the Z axis. Given that most boards only support 4-6 stepper drivers, Klipper is the perfect companion for such a project (one of the reasons I use it). It's easily extendable with cheap electronics and you may even have some old boards laying around.

[Westra]

@hg42 I haven not had any problems with my z axis moving. Using three lead lead screws is something i would like to do too, but never did due to the many stepper drivers involved. Klipper does sound like a very good solution for the many stepper drivers. (just like for multi material (2+) printing).

If Klipper is aiming to support this, It would be nice to build the next printer (there is always the next :) ) that way.

[tgiphil]

+1

[w1ebr]

My print bed is borosilcate float glass and is very flat. There are still good reasons for bed leveling, IMHO.

• Flex in the x and y gantries. My 300 mm x axis sags by about 50 microns in the middle.
• Thermal expansion. Aluminum and plastic both like to expand. I have used a Flex3drive bed on top of the glass and the plastic bed does expand.
• Before the Flex3drive bed, which I can't always use, I had a PEI sheet and the adhesive began to slowly out-gas, causing micro bumps in the bed.
• Overall leveling - my bed does not use springs to fine tune the height in each corner.
• Accuracy and automation - I can do a quick matrix bed level and be sure that my prints will stick. I have dual z-axis motors that are stepped simultaneously, but when the printer is off, the ends of the bed could get moved and be "out of sync"

I start with as level a bed as I can get from side to side (x-axis) when I first turn on the printer by adjusting the z-axis screws (if necessary). I then use bed leveling after the bed has been heated up to approx. the temperature it will be when it is printing.

[stoto]

I am signing up for this as well! I would love to see Mesh bed leveling come alive. Even if you have to provide the mesh in a config file by yourself and there is no automatic probing at start.

I am watching Klipper for a while now, waiting for bed leveling to appear before I switch over from Marlin.

I have a 300x300 Bed with CoreXY mechanics and while my bed is perfectly flat there is some sagging in the middle of the X gantry (2x 8mm hardened steel rods).

[OneDayFlie]

Looking forward to that option :p

[BETLOG]

The recent interest in 32bit boards, and the currently limited selection, is generating a lot of side mentions of klipper. It's my experience that everyone who loves the idea of klipper also immediately notices that there is no z-probing, and that this often puts that person back into assess and wait mode for 32bit boards. The addition of z-probing would immediately attract those of us in a 32bit holding pattern to implement klipper. Just saying.

[OneDayFlie]

BETLOG is right.. Almost forgetting THANKS! for the wonderfull work you allready did KevinOConner! :) But are you alone working on this project? I hope you have or will getting some help. This show must go on!! ;)

[sbts]

@KevinOConnor Depending on the amount of deviation on the bed it may be possible to compensate by changing flowrate@fixed speed, speed@fixed flow, or a combination of both. That would work nicely for small deviations without needing to "remap" the Z height or modify the gcode.

In-particular simply speeding up, or slowing down movement or extruder steps (with compensating drop or add of extruder steps) should have the desired result in many if not all cases with deviation <~2/3 layer height

The only downside to this I can come up with is it would take some careful testing to get even first layer "Squish" so apparent line width when viewed from the bottom remained the same.

The upside, it should only be relevant on the first layer. Beyond that, you should have a "flat" surface (relative to the extruder's path in Z) to print on

Dealing with the effects of Sag in X or Y above the 1st layer isn't something that can currently be compensated for anyway as there is no current method of testing and mapping that. In the event a means of mapping that was devised this same method could be used to compensate to some extent. Although I really don't know that it would be a good idea, except on "top" surface layers perhaps.

@KevinOConnor by the way, while I take no responsibility for any possibility that the above concept may/maynot breach a patent, in the event it doesn't I'll claim this as prior art against any future patents that may be issued. The above statement not withstanding, I offer the concept to klipper for unencumbered use. :-))

[KevinOConnor]

I've added basic support for "bed tilt compensation" to the work-probe-20170609 branch. If all works well, this code should make it possible to handle printers that don't have bed leveling screws and instead use a Z probe to determine the bed tilt. See the bed_tilt section of docs/example-extras.cfg for information on how to use it.

git fetch ; git checkout origin/work-probe-20170609 ; sudo service klipper restart

I'm looking for feedback on this support.

[sgraber]

I have to agree with @BETLOG as well: I've got a delta that has z-probe capabilities and I don't want to switch that one over to Klipper until it's implemented. Manually leveling a delta is an exercise in frustration. :/

[KevinOConnor]

On Mon, Jan 22, 2018 at 08:07:34AM -0800, Shane Graber wrote:

I have to agree with @BETLOG as well: I've got a delta that has z-probe capabilities and I don't want to switch that one over to Klipper until it's implemented. Manually leveling a delta is an exercise in frustration. :/

The delta calibration code is pretty close to completion on the work-probe-20170609 branch. For the details, see the description of the [delta_calibrate] section of config/example-delta.cfg on that branch.

-Kevin

[w1ebr]

Kevin, thanks for working so quickly on this!

[stoto]

Meanwhile I was looking into scipy's 2d interpolation feature. @KevinOConnor do you think it would be okey to use it for proper mesh bed leveling? It would allow to have like 15x15 measured points and 2D interpolate a Z height at any position on the bed. An interpolation could be done just before every toolhead movement. I don't know currently how heavy is the computation part of the interpolation, but If it turns out to be too heavy the interpolation can be done one time only right after the bed measurement for every mm of the bed. That would mean interpolating a 300x300 matrix from a 15x15 measurement if the bed is 300x300mm. This way selecting the proper z compensation value would be very simple, just rounding the X and Y coordinate to whole numbers and using those as indexes from the interpolated matrix.

[ohaase-dev]

Hi Kevin,

I also tested the bed-tilt feature of the probe branch. didn't print yet but calibration seems to work.

2 things I observed:

• The Calibration does a G28 homing first, which I think makes the calibration more realiable and assures to habe the correct z=0 as base. But: the calibration uses the fixed G28 method, if you use homing override (which I use for bl-touch probe to home Z in the center) it doesn't work. For now I just removed the G28 on calibration and do it manually. Would it be a good way to trigger G28 with gcode.process_command or via gcode_handlers.get?

• I don't get the speed handling. At the moment it's a bit unreliable because to fast. I have a homing speed for each axis, for probing and for bed_tilt claibration. Have to dig deeper on which speed is used at which part of the calibration process. Because I want faster moves to the xy positions and very slow probing speed. Maybe a double-touch feature as in the normal homing would be a good idea?

Regards Olaf

[KevinOConnor]

On Thu, Jan 25, 2018 at 11:43:17AM +0000, mediumo wrote:

2 things I observed:

• The Calibration does a G28 homing first, which I think makes the calibration more realiable and assures to habe the correct z=0 as base. But: the calibration uses the fixed G28 method, if you use homing override (which I use for bl-touch probe to home Z in the center) it doesn't work.

Thanks - good catch. I've updated the work-probe-20170609 branch to fix that. (It also updates homing_override to allow moves prior to homing via set_position_x config options.)

cd ~/klipper ; git fetch ; git checkout origin/work-probe-20170609 ; sudo service klipper restart

• I don't get the speed handling. At the moment it's a bit unreliable because to fast. I have a homing speed for each axis, for probing and for bed_tilt claibration. Have to dig deeper on which speed is used at which part of the calibration process. Because I want faster moves to the xy positions and very slow probing speed. Maybe a double-touch feature as in the normal homing would be a good idea?

When using the probe:z_virtual_endstop mechanism, then endstop_x.speed controls the homing speed and bed_tilt.speed/probe.speed have no impact. When running a bed tilt calculation, the probe.speed controls the descent speed, and bed_tilt.speed controls the xy move speed.

-Kevin

[KevinOConnor]

On Tue, Jan 23, 2018 at 10:02:09PM -0800, Peter Stojcsics wrote:

Meanwhile I was looking into scipy's 2d interpolation feature. @KevinOConnor do you think it would be okey to use it for proper mesh bed leveling? It would allow to have like 15x15 measured points and 2D interpolate a Z height at any position on the bed.

You could try. I suspect that simple linear interpolation is sufficient though.

-Kevin

[ohaase-dev]

Now I got it with the speeds.

Everything worked with the bed_tilt until I added the x_adjus and y_adjust to to config :-). As soon as they are added, the homing_override seems to have no effect anymore. I take a look into the code, but I'm not quite familiar with everything yet, maybe you habe an idea.

Regards

[KevinOConnor]

On Thu, Jan 25, 2018 at 08:26:09PM +0000, mediumo wrote:

Everything worked with the bed_tilt until I added the x_adjus and y_adjust to to config :-). As soons as they are added, the homing_override seems to have no effect anymore. I take a look into the code, but I'm not quite familiar with everything yet, maybe you habe an idea.

If anything undesirable happens like the above, issue an M112, and post the log here as described at:

https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

-Kevin

[ohaase-dev]

sure,

find the log attached. As soon as x_adjust and y_adjust <> 0, the custom g-code from home-override is not executed.

Olaf klippy.log

Edit: As far as I see it, the gcode is executed but the movement commands are blocked:

Must home axis first: -30.000 -8.000 20.000 [0.000] Must home axis first: 110.000 110.000 -0.580 [0.000]

[KevinOConnor]

On Thu, Jan 25, 2018 at 09:09:48PM +0000, mediumo wrote:

sure,

find the log attached. As soon as x_adjust and y_adjust <> 0, the custom g-code from home-override is not executed.

Okay, thanks - there was a bug in the code. Can you retest with the latest code:

cd ~/klipper ; git fetch ; git checkout origin/work-probe-20170609 ; sudo service klipper restart

Also, if your probe triggers at a Z of zero, then you'll likely need to allow the probe to go below zero - update your config with: stepper_z.position_min=-1 and probe.z_position=-1

-Kevin

[stoto]

@KevinOConnor the BLTouch has an extending arm which deploys when it's probing. That way the Z0 point for the probe means the nozzle is still a few mm above the bed. When the probing is finished the arm is retracting going above the nozzle height. That's why we need to be able to set the probe-nozzle offset in X-Y-Z.

[ohaase-dev]

@KevinOConnor: Thanks, I will try it later. Yesterday I did a quick implementation of 2 commands for allowing and forbidding unsafe movements, which had pretty much the same effect. I will provide a pull if you like. I implemented it analog to dragonnns bltouch branch. But I think it would be best to do the bypass in the actual kinamtics class (check_movement) instead of doing it in the toolhead class and bypass the check_movement method completly, what do you think?

@stoto: You are completely right. I think In the moment it wouldn't make a huge difference (if the probe is not to far away from the nozzle) since just the tilt of the bed is calculated. As soon as you think about something like mesh-leveling it should be considered. Z-offset can easily be applied with M206 and the config described by Kevin

@KevinOConnor: I think in the long term a mesh leveling would make sense, since you can deal with uneven beds (likely if you have a standard mk2/3 like bed without glas) or sag in the axis (likely at standard 8mm rods and long axis). I'm just getting into that topic, seems like there are several approaches like splitting the moves. With the processing power of the pi it could be interesting to add a spline for the z-correction to each movement which you can get from an interpolated heightmap of the bed etc.. Or to get an elevation-profile from the heightmap for the xy-path like navigation/GIS tools provide them .... I just don't know how how easy it would beto calculate the required step-corrections/timings for that.

Olaf

[KevinOConnor]

FYI, the work-probe-20170609 branch has been merged into master.

[tgiphil]

Awesome work!

[w1ebr]

Kevin, thank you for your work on this! I have one big job to get done, after which I intend to really dig into this great approach! Again, thanks!

[KevinOConnor]

FYI, basic bed leveling should now be supported (via the bed_tilt_calibrate command). I don't have any immediate plans to work on mesh bed leveling. Hopefully someone else will provide an implementation.

[psy0rz]

Cool ill try this with my CR-10. Still hope someone will implement mesh leveling.

The cr10 due to its size and design has multiple possible leveling problems, even if the bed itself would he flat. Z axis can sag in the middle or tilt and the bed can tilt as well. You could compensate manually, but it changes all the time.

[Alexdad76]

Hello! I can not complete BED_TILT_CALIBRATE. After 1-2 points this is constantly interrupted by a error: "Failed to home probe: Timeout during endstop homing Failed to home probe: Timeout during endstop homing " I use an optical sensor as a endstop and a probe. 2018-02-13_18-55_klippy.log 2018-02-13_18-40_klippy.log

[KevinOConnor]

On Tue, Feb 13, 2018 at 08:57:34AM -0800, Alexdad76 wrote:

Hello! I can not complete BED_TILT_CALIBRATE. After 1-2 points this is constantly interrupted by a error: "Failed to home probe: Timeout during endstop homing Failed to home probe: Timeout during endstop homing " I use an optical sensor as a endstop and a probe.

In order to home the z axis with the probe, you need to know the distance between the nozzle and the bed when the probe triggers. This distance needs to be programmed in both the stepper_z position_endstop and the probe's probe_z_offset.

If unsure of that distance, start with something safe - for example 2.345mm. Set both stepper_z position_endstop and probe probe_z_offset to 2.345mm. Then run the BED_TILT_CALIBRATE command. At completion of that command, it should tell you the actual z offset (if it's different from 2.345mm). You'd then update the config with the recommended x_adjust/y_adjust parameters AND update the config with the new position_endstop / probe_z_offset.

Separately, it's not clear if you are looking to do a "blind" Z lift at the start of your homing procedure. If you are, use something like this:

[homing_override] set_position_z: 5 gcode: G90 G1 Z7 F600 ; Blindly lift the Z 2mm at start G28 X0 Y0 G1 X100 Y100 F3600 G28 Z0

-Kevin

[Alexdad76]

Many thanks for the prompt reply! I'll try as soon as I get home tonight.

@KevinOConnor Separately, it's not clear if you are looking to do a "blind" Z lift at the start of your homing procedure. If you are, use something like this:

Before homing procedure, I first move the table down 5-10 mm, so as not to touch the glass holding clips. I try to repeat the "safe homing" as in Marlin. Maybe there is a more elegant way, but I still do not have enough experience.

[Alexdad76]

@KevinOConnor, everything worked perfectly!

One more question: My Z-axis is driven by a belt. As I understand all the axes move at the same speed:

The speed (in mm / s) of non-probing moves during the calibration. The default is 50.

For the Z-axis, a strong jerk occurs after the probing when the table is lowered. Is it possible to separately adjust the speed of X-Y and Z for non-probing moves?

[iggut]

Any developments in this? Sadly I would have to rebuild my printer with new C-beams to use Klipper. Mine are slightly bowed and either need mesh bed leveling or to be replaced and printer rebuilt :(

[psy0rz]

I just received my prusa i3 mk3. :) ill use the stock firmware for now.

[3eggert]

Are there any news? I tried to implement it by my self but failed )-:

[AxMod3DPrint]

@3eggert - see pull request #535 - needs to be looked at by Kevin, but hopefully should be implemented soon.

[jwcrawley]

Awesome :-D

I did have a few questions:

1. Will there be a way to manually measure a mesh via jogging per measured point
2. Can we save a mesh level, and use the saved?

[Artefact2]

At first glance it seems to require a probe, which is too bad. Being able to probe mesh points manually would be nice.

(Edit: @jakep82 Thanks for the suggestion. That means a lot, coming from someone with zero public contributions on his profile.)

[jakep82]

@Artefact2 I'm sure a pull request to add this feature would be welcomed to help improve this free, open source software.

[Arksine]

So while it isn't documented, In theory manual_probing should be available in bed_mesh as it uses the same functionality to probe that bed_tilt uses. I havent' tested it, and honestly it didn't occur to me that people would want to manually probe a minimum of 9 points. After its merged if someone wants to test manual probing I can update the documentation to include it assuming it works okay. The only thing that could be tricky is if you don't home toward the bed or have a delta printer. I would likely need to update bed_mesh.py for manual probing in those instances.

Bed Mesh won't initially support dumping a mesh to a file, but it would be trivial to add. I would just need guidance from Kevin on the best location to write the file to.

[Artefact2]

Bed Mesh won't initially support dumping a mesh to a file, but it would be trivial to add. I would just need guidance from Kevin on the best location to write the file to.

It could work similarly to PID_CALIBRATE: it outputs mesh data via serial (maybe after the last point has been probed), and you can add it to your printer.cfg file.

Edit: trying the manual method currently, I'll probably work on implementing a command to load a json-encoded mesh. Then it's just a matter of putting it in the start g-code of the slicer.

[Artefact2]

See #555.