Auto Mesh Bed Leveling - Roadmap

[psavva]

Dear Devs,

I would like to ask if Mesh Bed Leveling could be enhanced to be Automated, as you have auto bed leveling.

A lot of the features of Auto Bed Leveling make sense when also applied to mesh bed leveling.
Features such as:
X/Y/Z_PROBE_OFFSET_FROM_EXTRUDER
XY_TRAVEL_SPEED
Z_RAISE_BEFORE_PROBING
Z_RAISE_AFTER_PROBING

Even if at first you enhance Marlin for Manual Mesh Bed Leveling (as it is now), to implement these configuration items, it would certainly make sense to avoid scrapes over the bed (this happened to me yesterday), and allow you set limits, and check if you probe is within your bed area.

It would be interesting if I could also contribute to these ideas in the future as a programmer.
I however do not have any experience in programming for Arduino...

[Roxy-3D]

I would like to ask if Mesh Bed Leveling could be enhanced to be Automated, as you have auto bed leveling.

Yes. And that is in process. In addition to 'Automation', a more powerful mesh editor is under construction. And the improvements won't stop there. The Mesh will be 'High Resolution' meaning it can go as large as 15 x 15 and you will be able to store multiple mesh's in the EEPROM because some people print on multiple pieces of glass. And if that isn't good enough for you... There will be 3-Point and Grid based leveling of the Mesh.

[thinkyhead]

@Roxy-3DPrintBoard I'm looking forward to integrating this new stuff. How soon will it be ready? It would be nice to get 1.1.0 out and have this in it – but maybe June 1st is too soon?

[psavva]

@Roxy-3DPrintBoard that's great news.

Please let me know if ever I can help by contributing to coding, or testing...

I have a printer with 300x300mm build surface, limited only by the build plate for now.
Full travel is about 380mm x 380mm. Future upgrades for the build plate is on my todo list.

[GreatGrizzly]

@Roxy-3DPrintBoard
I have been following your work closely as Automatic Mesh bed leveling has been on my wishlist for a while. As I am reading the comments on here, I have noticed that we are making this way more complex than it needs to be. Let's start simple: Reuse the manual mesh leveling code to level through the use of a inductive sensor, something that is common in modern 3d printers and programmatically low hanging fruit.

So instead of the manual process:

1. Start mesh leveling
2. Move to new point on bed
3. wait for human to adjust z height
4. wait for human to save point
5. Move to new point
6. repeat until all points are measured

We can change it to:

1. Start mesh leveling
2. Move to new point on bed
3. automatically 'home' z height
4. automatically save point
5. Move to new point
6. repeat until all points are measured

In the future, we can make this more complex, but for now the KISS method should be used.

I am available to test out code on my modified Printrbot.

[epatel]

@GreatGrizzly If you like KISS you might like this :) http://www.thingiverse.com/thing:1120142

[GreatGrizzly]

While simple, having to remove and replace the printhead kind of defeats the purpose of automatic mesh bed leveling. ;-)

I envision a future where I can buy my dad a 3d printer, and all he has to do is push print when I send him a file. None of this "is the print head two copy paper thicknesses high" nonsense.

Thanks to you, @epatel and your mesh code, and @Roxy-3DPrintBoard 's work, that might come sooner rather than later.

[epatel]

@GreatGrizzly No, I don't need to remove the printhead, it just attaches onto the nozzle, so nozzle can't be hot :) Yeah, I would have loved to iterate on MBL a year ago. But the turn around time for stuff is so long that one just loses interest.

Well...I have played (in my mind) with a method to use a laser. I like crazy ideas.

[adamfilip]

many people (including myself) do not use inductive sensors.. I currently use a BLTouch sensor that works off the Servo Pins. But I agree. get the Core functionality working then add features once solid.

[GreatGrizzly]

@adamfilip I never said that everyone did, just that inductive sensor would be the easiest to get working. BTW I checked out the BLTouch sensor, very nice, I need to check that out!

[psavva]

I did notice a bug.
If you set your X MIN POS to say -90, then do the mesh level. If you go < X =0 you Z will dip far beyond the zero point and crash

[Roxy-3D]

Let's start simple: Reuse the manual mesh leveling code to level through the use of a inductive sensor, something that is common in modern 3d printers and programmatically low hanging fruit.

many people (including myself) do not use inductive sensors.. I currently use a BLTouch sensor that works off the Servo Pins. But I agree. get the Core functionality working then add features once solid.

Almost all of the code from @epatel is intact. The system is built on his technology. And really... I do understand the idea of small incremental changes. But have any of you people actually debugged problems in the Auto Bed Leveling systems and/or Z-Probe stuff? You get nested in 37 levels of #ifdef's. This is one of those times where it is easier to eat the whole elephant in one sitting.

So instead of the manual process:
We can change it to:

Yup! And there are other features in the Mesh editor that you are going to really like and that make it easy to use.

I'm looking forward to integrating this new stuff. How soon will it be ready? It would be nice to get 1.1.0 out and have this in it – but maybe June 1st is too soon?

You won't have to integrate it. I'm trying to keep up and track your changes to RC-6. But the code changes are way to invasive and extensive to be included in the Release Candidates. Instead, I'm thinking we take the Golden Release with the Unified Bed Leveling System and use that as the start of a Development Branch.

[GreatGrizzly]

@Roxy-3DPrintBoard

Since this is proving to be much larger then it appears on the surface, would it be prudent to move it to its own branch? I know a lot of people who would be interested in this, and most threads that come up when googled refer to older threads about this. Maybe after 1.1.0 is out, this can be the primary focus for 1.1.1. A benefit of this is we could attract the attention of other people and get you some help with getting this off the ground.

[epatel]

@psavva Huh, could you tell more? From a test or interpreting code? Which commit did you use, your Configuration.h file.

Update: Hmmm, think I see what you mean. Yes, that could be a thing to look into. I didn't think people did configure their printers like that (I imagine the safest thing is to configure the build plate in the positive quadrant). I imagine the math in mbl is fairly safe for this, just the border macros are off (missing pieces)

[Roxy-3D]

Maybe after RC is out, this can be the primary focus for next RC. A benefit of this is we could attract the attention of other people and get you some help with getting this off the ground.

Marlin has never had a 'Stable Branch'. That is what we are trying to accomplish right now. And we are close. Besides a 'Stable Branch' we want to have at least one 'Development Branch' where new features and code get shaken out and improved. If you want stability, you use the stable branch. If you want the new features and can live with a little bit of pain, you use the Development Branch. When a Development Branch gets very stable and robust it gets promoted to a 'Stable Branch'. (or something close to this thinking....) And once it is a 'Stable Branch' it doesn't get new features. It mostly just gets bug fixes.

[thinkyhead]

I did notice a bug. If you set your X MIN POS to say -90, then do the mesh level. If you go < X =0 you Z will dip far beyond the zero point and crash…

Sounds like something I should check into. I updated the grid-line / grid-cel index functions to use simple division. It's possible these formulae don't like negative values.

EDIT: So far the formulae appear to produce the correct indices for given coordinates.

[thinkyhead]

Marlin has never had a 'Stable Branch'.

The meaning of the word "stable" may be confusing to some. It doesn't mean the code is free from bugs or that it won't crash. The term "stable" only means that a particular "version" of Marlin is not gaining new features or seeing changes in its configuration. All tagged versions of Marlin are "stable" in that sense. The 1.0.x branch is currently the latest "stable" branch, and when the 1.1.x branch is created and it becomes the latest version, then it will be the latest "stable" branch.

See https://bitdepth.thomasrutter.com/2010/04/02/stable-vs-stable-what-stable-means-in-software/

[psavva]

I'll do the config again tonight with the latest RCBugfix and simulate.

I myself am a programmer, but have no idea where to stay to define Marlin myself 🤔

I'm post the config file when I do so.
Any other debug levels I can include that produce log files?

With regards to my X and Y MIN, is it wrong to have it in the negatives?
Ie: my bed corner is considered the zero position.

[epatel]

I believe it is the fact that MESH_MIN_X/Y is direct numbers and not a derived from MIN_X/Y_POS. Sry about that. That would cause a longer extrapolation from the closest mesh areas. But it is not as easy as just to add it there, all their uses should also be looked over. And any change should be tested before merged into the repo.

I will do that this weekend.

[epatel]

@psavva about

With regards to my X and Y MIN, is it wrong to have it in the negatives?

Not wrong per say, but I can imagine many math formulas making assumptions about the X/Y values and having everything in the positive quadrant can sometime make life easier.

I will look into fixing it for MBL, I can't make sure that the rest will work though, sry.

[jstefanop]

Any update on this?

[thinkyhead]

@jstefanop There is a unified bed leveling feature in development, but it's not going to get into 1.1.0. IT will have to wait for 1.1.1, but we will start doing testing on it almost immediately after the 1.1.0 release.

[jbrazio]

Closing due to inactivity.
The status for Unified Bed leveling as of today is: It will be part of Marlin v1.1.1.

[soswow]

@jbrazio what issue is it tracked with? Is there Unified Bed Leveling issue/ticket?

[jbrazio]

#4237 (comment)

[github-actions]

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.