Request : local autolevel possiblity

[spilz87]

hello, I don't know if it's the good place for this, tell me if I have to move it somewhere else.

my idea is : the autolevel calculs a new plan, but on a pre-defined location selected on configuration.h. but the size of object we want to print isn't always the same. so a good idea will be to be able to customise the autoleveb on a specific area. is it possible to add it?

and to go further, this fonction can be directly used by slicers or a fonction on marlin can check the max rectangle on fist layer to determine it

sorry if it's already existe or if it's not clear, my English is not good.

Let me know if it's a good idea and if it's possible

regards

[james94jeans2]

hey,

I am wondering what the use would be? I mean Z_Fade makes sense because you can disable the leveling after a specific height. But why would you want to apply leveling only in a specific region?

Regards

[spilz87]

my bed and specially my glasses I use are not plate, so I need more a mesh than an autolevel, but it's not well implemented in 1.1.0 , it will be on the next one. So I use autolevel to compensate it.

how do you disable the leveling after specific height ? on Marlin or through gcode ?

regards

[james94jeans2]

Quote from config: "Gradually reduce leveling correction until a set height is reached, // at which point movement will be level to the machine's XY plane. // The height can be set with M420 Z" It's currently not saved in EEPROM so you have to use the M420 Z code after every startup or add it to your pre gcode. It's for MBL.

[spilz87]

I learn Something thanks :)

[james94jeans2]

Also: the z_fade_height you specify with m420 must be higher than the Z_HOME_SEARCH height which is specified in the config. Otherwise you may hit your bed.

[MagoKimbra]

With ABL you can make the square with R L F B parameters.

*  F  Set the Front limit of the probing grid
*  B  Set the Back limit of the probing grid
*  L  Set the Left limit of the probing grid
*  R  Set the Right limit of the probing grid

Example G29 F90 B110 L90 R110 For square 90,90 - 110,110

[spilz87]

It looks like it's exactly what I'm looking for :) What is ABL ? How do you select the.number of point ?

[spilz87]

Ok ABL -> auto bed leveling ^^

[thinkyhead]

Also: the z_fade_height you specify with m420 must be higher than the Z_HOME_SEARCH height which is specified in the config. Otherwise you may hit your bed.

@james94jeans2 How are the z_fade_height and Z_HOME_SEARCH height interacting? We'd ideally like to make them completely independent of one another.

[james94jeans2]

When the z_fade_height is lower than Z_HOME_SEARCH we run into a problem when homing (G28). The homing code sets the current Z position to Z_HOME_SEARCH, which would normally be manipulated by the MBL to be 0 again, however if MBL doesn't apply because it's above its z_fade_height, then the Z position remains at Z_HOME_SEARCH.

This firstly means we are at Z_HOME_SEARCH after performing the homing and not as exspected at 0. Secondly when we now lower the Z value manually (by command or menu) we obviously will hit the bed at some point, but surprisingly (maybe at z_fade_height) Z moves in the opposite direction.

e.g.: If you were to command Z0 the nozzle goes down into the bed and up again. And if you move up again you will go down first into the bed and then again up.

I am not sure where this behaviour comes from, but if nobody knows I will have a dig into that.

A first idea for fixing would be to get rid of the current[ZAXIS] = Z_HOME_SEARCH and do something else when MBL is enabled, however I don't have a full solution yet, have to understand the homing in detail first.

Also on a sidenote: When homing with MBL enabled it will not home to the mesh leveled position. Only after doing a move to Z0 the leveling gets applied, allthough the LCD shows Z0 after homing. (this is just an esthetic thing) I fixed this for my setup by adding a LOOP_XYZ only setting Z0 as destination an then applying the prepare move right at the end of the MBL if-statemet in the G28. However this is probably not safe for all configurations.

I also just had the idea of replacing the just mentioned LOOP_XYZ with "destination = current", as the Z position is already 0.

Sorry for the long reply, but I hope it helps to improve Marlin.

[thinkyhead]

which would normally be manipulated by the MBL to be 0 again

That's bad behavior. Are you sure you're not actually referring to the MBL z_offset — a separate setting (G29 Znn)?

The Z_HOME_SEARCH setting has long been a pain in Marlin's ass. It should only be used to determine the margin for adjusting Z during MBL, and there should be no occasion when it's used to set the current Z position outside of that procedure. At the end of MBL the current Z position should correspond to its physical position, just as with all other forms of leveling. I'm not sure why current[ZAXIS] = Z_HOME_SEARCH would ever apply at the end of —after— MBL.

[james94jeans2]

I am sure.

I don't understand that behaviour either.

it's in line 3635 of Marlin_main.cpp: current_position[Z_AXIS] = MESH_HOME_SEARCH_Z

[thinkyhead]

Well, the thing is that MBL's leveling procedure is non-modal. When you first start MBL's G29 it puts Marlin into an "unusable" state until you finish MBL. During that time the Z position is given a larger value so that movement below the bed is possible. The final G28 at the end of the MBL procedure is supposed to rectify the Z position. I'm not sure why it doesn't just do a normal G28 and then enable MBL. I'm looking more closely at MBL in tandem with other leveling procedures today, and hopefully this will make more sense of it all.

[epatel]

The Z_HOME_SEARCH setting has long been a pain in Marlin's ass

Well, I think the Z_SEARCH in MBL has been covered many many times already. Like here https://github.com/MarlinFirmware/Marlin/pull/3488#issuecomment-210760195

If I remember correctly (it was a long time since I made MBL) and you haven't ruined it completely yet (as you have tried https://github.com/MarlinFirmware/Marlin/issues/3811 https://github.com/MarlinFirmware/Marlin/pull/3907), the probing is made from a coordinate system where Z_SEARCH is active/applied. So that is the values that goes into the mesh samples. Then in the end when it is time to enable MBL (after a G28), the step is set/use the Z_SEARCH and compensate with the samples. i.e. Say Z_SEARCH is 4.0mm and a sample in a point is 1.5mm this would mean that the nozzle traveled down 2.5mm, so enabling in that point would mean to HOME, set to 4.0, enable MBL, now it should read 2.5mm which is the coordinate "after" enabling (now 2.5mm above bed). Then an extra move can be enabled for where the "resting" position should be, on-bed or at end-stop (see MESH_G28_REST_ORIGIN)

[spilz87]

Just to let you know, I find a solution for me to this request :

• Using G29 L.. R.. F.. B.. That I learn with your help, Thanks for that
• I wrote a post processing cura plugin that check the min and max X and Y position of the first layer and add the right G29 L.. ... to the start gcode.

I can share this plugin, but I don't think it's the right place. If someone need it, just let me know where I can load it for every one.

Regards

[thinkyhead]

a coordinate system where Z_SEARCH is active/applied

Now that we can disable software endstops, during the MBL procedure we can just disable software endstops and allow movement below the bed. When MBL is done, we can just re-enable the software endstops if they had been on previously. No need to mess with faking the Z position.

[lrpirlet]

@spilz87 Have a look in https://github.com/MarlinFirmware/Marlin/tree/RC/buildroot/share/scripts, the g29_auto.py does something similar...

I guess your procedure written as a plugin for Cura, could find its way in this directory, if you submit it as a PR... and if this PR is accepted...

[github-actions[bot]]

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.