Marlin: Please change the default state of RESTORE_LEVELING_AFTER_G28

[jarrodasmith]

May we please have RESTORE_LEVELING_AFTER_G28 enabled by default?

Expected behavior: [What you expect to happen]

If I go to the trouble of setting up Mesh leveling, saving the values to EEPROM, and enabling UBL with M420 S1, A subsequent G28 should not, by default, disable it. This is confusing, and in my view defies logic as Marlin currently stands. At the very least there should be a clear note about this behavior in the docs for G28 and M420. I didn't find clear documentation of this, to me, odd behavior.

Actual behavior: [What actually happens]

After setting up and enabling MANUAL_MESH_LEVELING, an inadvertent G28 (commonly applied at the top of many default slicer prologue scripts and gcode found at thingiverse, etc), your hard work is undone. It can be quite confusing, and seems go against the "principle of least surprise" since at first glance those two functions do not seem to be related. In any case this seems not to be a well documented behavior.

This issue was tangentially discussed at some length earlier in the year, here:
https://github.com/MarlinFirmware/Marlin/issues/10726

so I'm aware of some of the history. But history aside, from the pure standpoint of usability...having RESTORE_LEVELING_AFTER_G28 disabled by default does not seem to be the least surprising way to go, to me.

[thinkyhead]

It is a non-standard behavior, because G28 is specified to do a "reset" of sorts, including turning leveling off. Because UBL was built without this consideration a compromise was made, that if you fail to uncomment the option at all then you will get an error about the way that UBL was behaving, insisting that you set it to true or false explicitly. Some prefer the option, and some do not. I'm one of those who prefers the historic behavior of G28 to be preserved.

G28 does not discard the collected mesh data, so if leveling is desired, it can be guaranteed by having M420 S1 after any G28 when RESTORE_LEVELING_AFTER_G28 is off.

[Roxy-3D]

Because UBL was built without this consideration a compromise was made, that if you fail to uncomment the option at all then you will get an error about the way that UBL was behaving, insisting that you set it to true or false explicitly. Some prefer the option, and some do not. I'm one of those who prefers the historic behavior of G28 to be preserved.

The truth is UBL was built with the assumption that if the bed was compromised (slanted, warped, etc.)... It was safest to keep the bed leveling enabled when ever possible. UBL does turn the bed leveling off during homing or any kind of probing. But if the user turned on bed leveling... He probably wants the option to keep it active.

[forkoz]

I also leave it disabled. M240 S1 is in my gcode. Imo, its trivial to enable or disable it. Maybe compile should halt if the user hasn't set the preference and have no default.

[Roxy-3D]

Right now... People can set the 'preferred' way they want it to behave. It IS part of the machines configuration. For historic reasons, it makes sense to have the default of the option the way it is. If at some point in the future we have most people running with it enabled... It can be changed easily.

Even though I support having bed leveling active across all homing and probing functions... I do believe the default should be 'Off'.

[jarrodasmith]

I see both ways of looking at it. It's just that you folks are naturally coming at it from the developer point of view with all the history behind why it behaves the way it does. But from the standpoint of a normal every day user, this is not expected behavior.

At the end of the day it doesn't really matter what it's set to by default, as long as it is spelled out clearly in the M420 and G28 sections of the docs. Currently it is not, and ultimately that is the most confusing thing about the behavior - the only way for a new user to discover it is to read the code or find one of the handful of discussions about it here, on Reddit, etc.

And things are much worse for people who happen to get the firmware repackaged from a third party who may have rearranged config.h, effectively removing the option for all practical purposes. Or as pre-compiled .hex images. Ultimately good documentation is the only real way to address the potential for confusion.

[Roxy-3D]

It's just that you folks are naturally coming at it from the developer point of view with all the history behind why it behaves the way it does.

Ah.... Remember.... The first deviation was how UBL handled homing and it left the Bed Leveling Activation state in the same state it was at the start of the G28. Thinky is right that the traditional result of a G28 was to reset all of the machine state and home the machine. I think we need to evolve.

But we both agree until the vast majority of the user base expects bed leveling activation to be preserved across a G28, it is safest to default that to 'Off'.

We are trying hard not to cause unexpected problems. We have to move slowly on this kind of stuff.

[jarrodasmith]

I also leave it disabled. M240 S1 is in my gcode. Imo, its trivial to enable or disable it. Maybe compile should halt if the user hasn't set the preference and have no default.

And it is indeed trivial to enable or disable. But you have to know that it's being disabled (by G28) before it becomes trivial to understand why your UBL setup stopped working. It's also as simple as putting M420 S1 after your slicer's G28, but that requires the understanding that G28 disables it. A lot of people don't. A lot of people get their Marlin firmware packaged in a way that makes it difficult to discover.

[Roxy-3D]

But you have to know that it's being disabled (by G28) before it becomes trivial to understand why your UBL setup stopped working. It's also as simple as putting M420 S1 after your slicer's G28, but that requires the understanding that G28 disables it.

G28 has ALWAYS disabled bed leveling. That is well documented. UBL allowed G28 to disable bed leveling so it could do its work accurately, but restored the bed leveling activation state upon exit from G28.

Listen.... I'm with you.... But the GCode Nazi's do have a point. You don't want to drastically shift what an important GCode (like G28!!!!) does without careful consideration AND CONSENSUS. The whole community should weigh in on it.

[jarrodasmith]

But we both agree until the vast majority of the user base expects bed leveling activation to be preserved across a G28, it is safest to default that to 'Off'.

We are trying hard not to cause unexpected problems. We have to move slowly on this kind of stuff.

After reading your replies and thinking more, my view has evolved. I think the best way to handle it is to add a note to the G28 and M420 sections of the docs that clearly state what the interaction is, and how to tune it to the users' liking. I know this would have saved me a lot of frustration. And in my attempt at "troubleshooting" what is ultimately a feature not a bug, I found several other posts by people who also fell into this trap. I think that would be the most helpful way to clue in the wave of people who are just now discovering UBL functionality, and buying the latest crop of Chinesium that has this stuff flipped on out of the box (also not effectively documented, I suspect).

[jarrodasmith]

G28 has ALWAYS disabled bed leveling. That is well documented.

I'm not being smart, I promise. Please point me to the place in the docs that says this. I looked, pretty hard, and never found it. Should it not be right here?

http://marlinfw.org/docs/gcode/G028.html
http://marlinfw.org/docs/gcode/M420.html
http://marlinfw.org/docs/gcode/G029-mbl.html

I don't see it, sorry.

[Roxy-3D]

After reading your replies and thinking more, my view has evolved. I think the best way to handle it is to add a note to the G28 and M420 sections of the docs that clearly state what the interaction is, and how to tune it to the users' liking. I know this would have saved me a lot of frustration. And in my attempt at "troubleshooting" what is ultimately a feature not a bug, I found several other posts by people who also fell into this trap. I think that would be the most helpful way to clue in the wave of people who are just now discovering UBL functionality, and buying the latest crop of Chinesium that has this stuff flipped on out of the box, and also not properly documented.

And in fact.... Just for perspective so you see how complicated this subject is... I have never used M420. I always thought people would remember something like G29 A for activation easier. Thinky believes differently. And he (very rightfully) made M420 also handle bed leveling activation for UBL.

When it is clear that the majority of the Marlin users want bed leveling activation preserved across a G28, I will personally merge the Pull Request. I'm with you.... But things like G1 or G28 or Laser commands (L3 & L4 !!!!) . ... Or things like a high temperature nozzle with a SSR powered heat bed..... You know what???? I'm OK with saying we want to move slow...

I hear you! I'm trying to get to where you see things!

[jarrodasmith]

that if you fail to uncomment the option at all then you will get an error about the way that UBL was behaving, insisting that you set it to true or false explicitly.

In SanityCheck.h? It looks like that bit of code only runs if you are using auto bed leveling, not manual mesh leveling. I am using manual mesh leveling and was not notified about that when building the firmware.

[Roxy-3D]

G28 has ALWAYS disabled bed leveling. That is well documented.

I'm not being smart, I promise. Please point me to the place in the docs that says this. I looked, pretty hard, and never found it. Should it not be right here?

I don't think this is in the documentation. It is documented in the source code. It is a historical fact that I (and Thinky) am very aware of.

The original 3-point bed leveling disabled when a G28 was performed. Next, the grid based did the same thing. Then the original mesh based system did the same. UBL deviated from that behavior. Bi-Linear disabled bed leveling if G28 was invoked.

With that history out of the way... Thinky gave UBL an option so it could conform to what the other bed leveling systems were doing. And the default for that option is (rightfully) to disable bed leveling after a G28.

[swilkens]

Different suggestion; fix this in documentation? I also didn't find this out until I found mention of it on forums or social media.

If we update the leveling system documentation and gcode documentation with a notice of this, effect, perhaps in strong font type, it might be fine? The situation remains the same and the large amount of information available on-line remains relevant as well.

G28 zeroes the Cartesian system, a mesh is a modification to the gcode instruction applied in relation to the zeroed Cartesian system - these are essentially very different actions. It makes sense to me that G28 remains "pure" and that a flag is required to enable this modification of the gcode to compensate for bed leveling.

Perhaps just a documentation "bug" ?

[jarrodasmith]

Different suggestion; fix this in documentation? I also didn't find this out until I found mention of it on forums or social media.

If you read through the whole thread you'll see this is what I landed on as well. Thinking back, if the G29 (Manual Bed Leveling) and M420 pages had this bit of info in a note, I wouldn't have thought twice about the issue. I'd have seen it before I ever started playing with these features and would have known how to setup my scripts properly WRT G28.

[Roxy-3D]

If one of you prepares an update to the documentation... It will get merged.

[jarrodasmith]

Didn't know that was an option. I see the "improve this page" link now, I'll take a stab at it.

[Roxy-3D]

Didn't know that was an option.

Marlin literally has hundreds (if not thousands) of contributors. If you don't like something, or want to see an improvement to handle something better... If you develop it in a clean fashion, it will probably get merged.

[boelle]

@jarrodasmith is this "issue" still relevant?

[jarrodasmith]

I submitted some docs and they were merged, so I'm happy.

[boelle]

then maybe give the close button below a hit or 2 :-)

[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.