Mesh Bed Leveling – Add lift between probes, comments, cleanup

[thinkyhead]

Mesh bed leveling has a few redundancies and some minor deficits in operation. In my own experience the behavior is such that the nozzle tends to drag on the bed. So this PR takes advantage of the MIN_Z_HEIGHT_FOR_HOMING value to add a raise between probes. Other cleanup also…

• Make mbl.active into a bool so it may be used (in future) in a menu edit item
• Add helper functions to the MBL object for doing zigzag points
• Use _mbl_goto_xy functions to consolidate MBL code in both G29 and LCD menu
• Raise by MIN_Z_HEIGHT_FOR_HOMING between points in MBL G29 and LCD-based leveling
• Remove + home_offset[axis] where it doesn't apply (i.e., MESH_HOME_SEARCH_Z is arbitrary)
• Expand comments on Manual Bed Leveling options

Since Marlin_main.cpp and ultralcd.cpp each have their own convenience functions for moving to current_position, there is still some duplication of effort in the probing functions. This PR points the way to merge these movement functions and consolidate more of the MBL code in mesh_bed_leveling.cpp.

[thinkyhead]

@epatel This works a little better for me with the lift between probes (based on the homing lift). Otherwise the nozzle was dragging on the bed sometimes. Overall, with the extra menu capabilities, I now find MBL much more pleasant to use.

[epatel]

@thinkyhead That was what MESH_HOME_SEARCH_Z was for basically, so I never had that problem.

Let me explain. The rational and design I did was for having the Z-endstop slightly above the whole bed and the MESH_HOME_SEARCH_Z is the "search" distance below that can be traveled below the Z-endstop (without having to disable and muck with the software endstops). During homing there could be a risk of dragging the hotend over the bed if the Z-endstop is not above the whole bed. Yeah, thing is that the homing order should maybe be changed, to do Z first, never got around to change that.

Think this is the latest doc I wrote, as it includes both G29 S3 and G29 S4. https://github.com/epatel/Marlin/blob/75f9fb50c4002f6d4ba0345f5594cbac1fab1fa6/Documentation/MeshBedLeveling.md

I see that you have added my initial PR as doc here (which gets strange as I wrote it in first person language but one can't see who is the author)
https://github.com/MarlinFirmware/Marlin/wiki/Manual-Mesh-Bed-Leveling
...also it does not mention S3 and S4 which was added later.

[thinkyhead]

@epatel This PR considers a more typical setup, so we will need to expand the documentation to accommodate the more typical Z endstop setup.

If MESH_HOME_SEARCH_Z was assuming that the nozzle is 4mm above the bed after homing and if MESH_HOME_SEARCH_Z is meant to double as a lift between probes, then these assumptions were dropped in this PR to allow for normal Z endstops. With this PR, MESH_HOME_SEARCH_Z only indicates the amount of downward motion allowed when adjusting the nozzle at each point.

It's important to extend MBL this way. A Z min endstop 4mm above the bed is a highly unusual setup, to begin with. On most machines the Z min endstop is the lowest point where the Z axis can move! And on most machines, users have that endstop positioned so it comes very close to zero – before they add in bed-leveling.

If you assume that users have an unusual Z min endstop setup, 4mm above the bed and not blocking the Z axis from moving down, it makes MBL behave badly on a machine like mine with a mechanical Z min endstop set close to zero. To wit: the nozzle drags across the bed between probe points.

All this PR does is to make MBL more useful on machines with typical Z endstops by adding a lift between points. I chose to use the MIN_Z_HEIGHT_FOR_HOMING rather than adding a new setting or using Z_RAISE_BETWEEN_PROBES, since that setting is associated with ABL. For users with no MIN_Z_HEIGHT_FOR_HOMING there will be no change in behavior – the nozzle will keep dragging on the bed between points.

this is the latest doc I wrote, as it includes both G29 S3 and G29 S4

Do you want to update the documentation in our new repository, or should we leave it up to someone else? It should be updated to mention that MBL is now workable on machines with no special endstop setup required.

which gets strange as I wrote it in first person language

I started to edit that document in the wiki to make it more formal, but haven't published it yet. If you would like to re-write the MBL instructions based on your latest documentation, that would be great.

[epatel]

If MESH_HOME_SEARCH_Z was assuming that the nozzle is 4mm above the bed after homing and if MESH_HOME_SEARCH_Z is meant to double as a lift between probes, then these assumptions were dropped in this PR to allow for normal Z endstops. With this PR, MESH_HOME_SEARCH_Z only indicates the amount of downward motion allowed when adjusting the nozzle at each point.

No, I did not write 4 mm above. I wrote slightly above. 4mm is only the allowed search distance. A big difference. This actually means less than 4 mm, preferably maybe only 1 mm. As long as the nozzle is above the whole bed (Z-endstop) all should be fine I think. No need to raise more than that.

Again, having the Z-endstop slightly above the bed is a safe precaution for doing homing.

The reasoning for a specific MESH setup should be a conscious decision. (1) My bed is warped so I need Mesh bed levelling (2) I set up my printer for Mesh bed levelling as described in the docs (which once existed)

[thinkyhead]

Z-endstop slightly above the whole bed

@epatel Well in practice the existing MBL code can cause some bad dragging on the bed (in my case because one time the Z carriage on the right side of my i3 was 2mm lower than the left). So some additional lift is needed between points to obviate this possibility.

And on my machine, as with so many, Z=0 is the lowest point that the nozzle can move, so an endstop even slightly above the bed is bad.

[epatel]

@thinkyhead When I write above the whole bed I mean the whole bed

[thinkyhead]

A Z endstop even slightly above the bed is just not doable or preferable in many cases. For my part, I have sometimes preferred the Z endstop to be slightly lower than the bed, for the extra adjustment freedom with M206.

[epatel]

I think it is. Often the endstop can be moved and the bed is usually on screws that can be turned to lower the bed.

[thinkyhead]

But the Z endstop is too often the lowest point that Z can move. So moving it above the bed and then having users go lower –pushing the Z endstop hard downward, sometimes dislodging it– is not good. Slightly flimsy RepStrap and RepRap machines with zitptied Z endstops must be considered.

[epatel]

Well, my reasoning is that I rather push on the endstop than push on the nozzle. It's either one.

And this is when homing the nozzle is in danger.

And in my ears you argue to rather push the nozzle than the endstop.

[thinkyhead]

@epatel Only normal Z endstop style homing is necessary for this feature, the important part of which is to collect relative height points along the bed and make a tilt matrix. For your average RepRap machines, the Z endstop is set right around where the nozzle touches the bed, or about 0.1mm above the bed for the old-timers.

What can I say? My initial testing and experiences with Manual Bed Leveling led me to add this lift between moves… It was necessary for my setup, where I generally don't want to keep leveling compensation enabled all the time, but I do want to be able to test it and use it if the whim strikes me.

• The first time I tried MBL, my bed was pretty level to start with and my Z endstop was set at a good height. But the default grid boundaries at that time were 10mm from the edges – too close to my bed clips. So I got crashes into the clips between some probe points. I changed the outer margin to 25mm so probing would avoid the bed clips.
• Second time I was able to get started. But the LCD was flashing like crazy. So I had to take a break to fix the menu code so you can call back into handlers without clearing the screen. That took a little while.
• Third time with MBL it was working better. But after each Z adjustment the nozzle would move back down to the bed for the next move. I thought I must have done something wrong. "Surely the nozzle should be lifting up between points. After all, what if I want to show off and print on a bed tilted at 15°?"
• At some point I had a separate issue where my Z axis ends ended up at different heights, so on my next attempt to use MBL I was using a "very" tilted bed, so it became a problem that the nozzle was so close to the bed between probe points.
• So before the next test with MBL, first I went to my configuration and added a MIN_Z_HEIGHT_FOR_HOMING (because it was long overdue anyway). Then I went back to the MBL code and added the lift between points. With these added lifts I found that it had a more pleasant feel, with less worry about the nozzle being close to the bed during fast moves, which as mentioned can be troublesome if the bed is very tilted or if the Z endstop ends up lower so the nozzle starts out against the bed.

[epatel]

Let's agree that dragging the nozzle over the bed is bad, especially if one maybe use blue tape or other surface material that could loosen and build up a wall.

So, maybe a picture will explain this better (not scale)

If one have the Z-endstop at "B" (the "normal" case) there is a big risk that homing from the "A" area can cause a severe drag of the nozzle into the bed. This is why I am arguing for having the Z-endstop above the whole bed and changing the homing order to do home Z first (which is not done yet). My suggested setup is to have the Z-endstop above the bed (then homing can be made in a safe maner). We can not take for granted that the bed is flat as that is probably the reason for selecting to use MBL in the first place.

An alternative setup could be to have the Z-endstop at Z-max, which I have seen some requesting. Have been thinking about that. But for the moment I am waiting for what @Roxy-3DPrintBoard is putting together, so personally I'd wait for her additions before changing anything with MBL.

Also, endstops are really cheap and for MBL I recommend opto endstops (often with free shipping from China) http://www.ebay.com/itm/Opto-Endstop-Switch-Kit-for-CNC-3D-Printer-RepRap-Makerbot-Prusa-Mendel-RAMPS-/221977263509 I imagine mechanical endstops with a flexible arm could also work within reason (most common setup maybe?) I have some, not in use and I got the feeling that maybe a max flex of 4mm could be accepted.

Compared to the price of my hotend https://b3innovations.com/product/pico-hot-end-test/?v=f003c44deab6 (here it would end at $140 for shipping + VAT) I think it's a very cheap insurance.

I am actually surprised that you have tested MBL at all, considering how negative you been to it since day one.

[epatel]

@Roxy-3DPrintBoard @AnHardt @alexborro What do you think?

[jbrazio]

Why is this even a discussion point ? MBL should respect MIN_Z_HEIGHT_BETWEEN_PROBING (I'm on mobile, don't remember the exact directive name) we already use for auto bed leveling, it's unacceptable to have the nozzle dragging around. We can set this at a default value of 4 and warn than it may not be enough depending how bad the bed is.

[epatel]

it's unacceptable to have the nozzle dragging around

Exactly! And that is the real rational to have the Z-endstop above the whole bed, which then makes it unnecessary to add lift above that.

[epatel]

Ok, I have been looking more into this. I now see that MIN_Z_HEIGHT_FOR_HOMING does a Z move up prior any other move during homing, this is good, or? Personally I do not like to move any axes during homing (unknown position) in the opposite direction of their homing. I guess this could cause unnecessary strain on the Z-lead screws and bend them in a worst case scenario...but I agree that that risk is very small. Lets hope it never happen (personally I have printed very close to max Z, for this http://www.thingiverse.com/thing:758544).

When I added MBL, over a year ago. I did not mix any of the ABL stuff, for many reasons. I still only use my own fork at the moment that contain a personal auto method to MBL.
https://github.com/epatel/MarlinDev/tree/epatel/RigidBot_Big+RAMPS_1_4+BulldogXL
http://www.thingiverse.com/thing:1120142

Also this changes the behaviour for anyone already using MBL or reading the already available instructions (if they can find them)

[jbrazio]

With #undef MIN_Z_HEIGHT_FOR_HOMING if for some reason the robot stops with nozzle touching the bed it will create a situation were the nozzle will drag across the bed; I do understand that the opposite could happen, robot stopping with nozzle at Z-max, but the probability of that occurring seems to be less than near the bed, so overall a bit of MIN_Z_HEIGHT_FOR_HOMING (1mm or 2mm) is a good thing.

I believe MBL should respect the following three directives:

  #define Z_RAISE_BEFORE_PROBING 15
  #define Z_RAISE_BETWEEN_PROBINGS 5
  #define Z_RAISE_AFTER_PROBING 15

MBL is an experimental feature, if we break it's current usage in order to improve, simplify or align it's behavior with the other existing methods I believe it will [in the long run] provide better user experience with Marlin, and now with the documentation project is really important to have a page dedicated to MBL, @epatel do you believe in the end you can help with that ?

-offtopic-
Food for thought for devs: IMO the error we had so far is not marking these type of features as EXPERIMENTAL_MBL_* until they are mature enough, I don't mind shipping RC or even GA with experimental features inside as long as they are disabled by default, clearly identified and with all the warnings near it's activation flag.

[epatel]

@jbrazio I think MBL is a special case/setup just like ABL or other feature and it can have its own setup requirements. Just the fact that it should handle twisted or curved beds puts it in its own category. So I don't buy the arguments that it has to follow i.e. the ABL setup of stuff. That is just convenience for those using ABL prior (and that should not be a requirement).

Experimental? I guess that is your opinion. But MBL has been around for over a year. I have been using it since I implemented it as it was necessary for my BigBot to work. I am seeing online more and more trying it, making a conscious decision to use it, and actually get it to work and then really appreciate it. i.e this guy https://www.youtube.com/watch?v=FPO3CbrVMi4 I think it is pretty good and helps making part of the process of setting up a printer easier and cheaper (not requiring a totally flat bed, and making it easier to build larger printers).

Documentation. When I implemented MBL there was a part of the repo that was for documentation and I put the MBL instructions there. When I changed something for MBL, like added G29 S3 I also added that in the docs. This is the right method to go, the one that changes something also should edit the docs. But then someone removed the docs, all of them, and copied only a part of it to another place I got really sad. I tried several times to register as was the mentioned way to access that place. Never got granted. I saw someone else copied in an old version there, making it wrong docs. More sadness. So I welcome a better doc system, though I think the system of just having a docs folder in the repo was sufficient (also very good in the sense the doc content would follow what is checked out for a specific branch/commit/version). If you are asking me to document changes other people are doing, I'd say no, that I won't do. I document the parts I create and change. I think doing documentation is boring, but necessary, so if you like to change stuff, you should also document it yourself! Do not count on others doing that (unless you pay them for it!).

[jbrazio]

Yes don't take my answer so literally.. ABL and MBL have in common the probe functionality thus those three directives makes sense to apply to both, my point is only for this three directives, of course MBL is a beast at its own right, I'm not asking to share code with other stuff.

I was asking your help to document MBL as you are a key people in this area of Marlin.

[epatel]

This is what I documented up to par with what I had added to MBL (last update 18 April 2015)

https://github.com/epatel/Marlin/blob/75f9fb50c4002f6d4ba0345f5594cbac1fab1fa6/Documentation/MeshBedLeveling.md

And this is the link I share when anyone asks about the documentation. Why? because of the reasons I mentioned earlier. I have seen some notices about a new documentation system. But for now I am waiting to see what will happen with that. Then when/if it gets explained somewhere I could see myself add that text (again). But, I will not document any changes made by other people, that is their own responsibility, i.e. these new things Scott added/changed here. He has to document them himself I think. For instance he called "MESH_HOME_SEARCH_Z is arbitrary", when it was definitely not an arbitrary implementation, which I have tried to explain here.

For the record. My initial PR for MBL is dated, 18 March 2015 #1619 So for me MBL is old and was reluctantly added and never brought to the light. Maybe added because of a few supporters as @alexborro and @Roxy-3DPrintBoard

[jbrazio]

I am a supporter of MBL, it makes perfect sense to be incorporated and in fact I could see a future where only ABLx4 (3 points only produces more error margin) and MBL are the norm.. humm can I even dream of seeing them merged ? (why should ABL probe the same points over and over again ?)

I am currently in charge of the documentation, I've been told about the bitter taste the previous guy left, so I tried to build a system that could survive without me. The new documentation system is stored inside its own repository owned by MarlinFirmware, I guarantee this time no data will be loss. Everyone can contribute, just fork the repo and add your .md file.

[thinkyhead]

Currently all the RAISE_BETWEEN_PROBING and RAISE_BEFORE_PROBING settings are sub-options of AUTO_BED_LEVELING_FEATURE. Meanwhile MBL has always been more "light weight" which is why I didn't opt to make these items belong to both features. But, it's not a bad idea since we have them.

[thinkyhead]

Anyway, I totally understand how MBL is designed to work. I'm applying flexibility to add a lift between probes because in my own case it was needed so I can avoid bed clips or dragging due to mechanical errors, and so I can get cleaner moves. This is especially better for someone like me, who is testing and debugging and hacking around, so my mis-configurations might easily bring the nozzle even lower.

I like MBL and have been working to improve it —especially the flow of Manual Bed Leveling— because I myself don't have any probes and I prefer to keep my machine probe-free. Also MBL it is a very in-the-spirit-of-RepRap kind of feature. Everyone should be able to level their bed without servos or probes.

@jbrazio has been doing a lot of work to clean up the LCD section in the configs, and I think we will soon do the same for probes and leveling. It's simple enough to apply the z-raise settings to MBL in the same way as it applies to ABL.

[epatel]

avoid bed clips

That is what MESH_MIN_X and MESH_MIN_Y is for basically. The MESH algorithm should work fine outside the grid boundaries (using the slope of the nearest tile, of course within reason). The 10mm there is basically my clip setup (XY endstops for nozzle above a part of the bed, not in the corner, + add a little, 10, for just a little of the clip that go into the "print" area).

[thinkyhead]

Ok, with the most recent patch, MBL is now just as it was, except there's an extra lift for those of us with MIN_Z_FOR_HOMING set. This is the illustrative and automated fix for this specific combination of options. We can easily extend the ABL raise options to MBL anytime. They will simply supplant the places where MIN_Z_FOR_HOMING is currently applied. I'm just waiting for the configs to get a little more cleanup before making a PR around this concept.