Request for Comment: UBL Z-Offset

[Roxy-3D]

There are some issues with the Z-Offset in the UBL System. Certainly, I can find them and get that fixed. But I'm actually considering going down a different path. What I'm thinking of doing is removing the Z-Offset from the UBL System.

The reason is this: It isn't needed and it adds extra floating point operations to every segment of movement. The Delta's really need every bit of CPU cycles they can get.

What I'm thinking of doing is instead of having a Z-Offset, I'm thinking of just moving the entire Mesh up or down. When you think about it, that is exactly what each Mesh Point is. Each Mesh Point is an individual Z-Offset to the extruder at a particular location on the bed.

I'm thinking the Z-Baby-Stepping would still be present and work. But instead of shifting the Z-Offset variable, it would be shifting the entire Mesh up or down. And The G29 Z commands would still be available. But instead of setting the Z-Offset variable, the G29 Z commands would shift the entire Mesh up or down.

And of course, if you like the behavior of your printer with the Mesh adjusted up or down, you save the current Mesh. The next time you power up your printer, it will 'remember' how you wanted the Mesh positioned, and will just use it.

Before I do anything... I would like to discuss this with people that use the Z-Offset. (I don't actually use it. I just set my Z_PROBE_OFFSET_FROM_EXTRUDER very accurately, and edit the Mesh to be perfect when doing a G26. That works fine for me.)

[adamfilip]

To be honest I assumed this is what Z offset already did.. so it makes sense to me.
I also feel that with babystepping that if its used, its automatically saved so thats its correct the next time.

Also I would prefer if the babystepping was the default control when printing. by default its the Speed percentage for some reason. but Ive never needed to use it.. but im always digging through the menu for the Z babystepping..

so if the machine is printing and you turn the rotarty dial it starts adjusting babystepping Z, if you press the rotary encoder it goes into the menu system.

I know you added a ability to set a switch to trigger babystepping.. i havent been able to get that working.. no matter what pin I set..

[epatel]

I think there once was two different z_offset, one in ABL (zprobe_zoffset) and one in MBL (mbl.z_offset).

I added z_offset to MBL because I wanted to be able to fine-tune the samples. Because the probing might give a good shape of the bed, but not a good/perfect print distance. It got saved in the EEPROM together with the mesh samples so when turning the printer on everything was there. I added it to the Tune menu so it could be changed while printing. Currently I think it gets set when one press the encoder and exit the "tuning". As this value is part of MBL calculations it gets used pre-planner and thus maybe noticeable 10-12 lines later. I have been thinking of making it "active" while "tuning", should be fairly easy I think.

Sure baby-stepping is basically the same thing. But back when I was adding MBL I wanted to box/separate MBL so it was easy to add and remove. I am not using baby-stepping and this "semi direct" z_offset tuning has worked fine for me (using a standard Mega+RAMPS board on a RigidBot).

I trust you to take ownership of UBL and take the decisions you feel necessary. :)

[Roxy-3D]

I also feel that with babystepping that if its used, its automatically saved so thats its correct the next time.

This certainly can be done. The one thing I have a concern about is the EEPROM has a limited number of Erase and Write cycles associated with it. If the user changes the 'offset' of the Mesh, it is easy enough to save that in the EEPROM so it is available for the next print. I just don't want to wear out the person's controller board. The simplest solution is we tell the user that if they like the current offset of the Mesh, then save it. But the next simplest solution (that doesn't wear out the EEPROM) is to wait for a print to complete normally, and only save the Mesh at that point.

I don't know what the 'right' thing to do is... But what ever we decide is 'right' shouldn't be too hard to do.

I think there once was two different z_offset, one in ABL and one in MBL.
I added z_offset to MBL because I wanted to be able to fine-tune the samples. Because the probing might give a good shape of the bed, but not a good/perfect print distance. It got saved in the EEPROM together with the mesh samples so when turning the printer on everything was there.

@epatel Thanks for the history! From my perspective, the reason the z_offset is there is just because I tried to preserve as much of the low level layers of Mesh Bed Leveling as I could. I always had my z_offset at 0.0 (which is part of the explanation why I didn't see any of the bugs I introduced into it).

[Roxy-3D]

Also I would prefer if the babystepping was the default control when printing. by default its the Speed percentage for some reason. but Ive never needed to use it.. but im always digging through the menu for the Z babystepping..

A agree! I think the best answer is we make the default configurable so the user can choose what action happens without drilling down through the menus. That frustration is why I added the QUICK_ACCESS_TO_Z_BABYSTEPPING.

so if the machine is printing and you turn the rotary dial it starts adjusting babystepping Z, if you press the rotary encoder it goes into the menu system.

Let me think about how to do that. It maybe the 'cleanest' way to get there is with a 'Press and Hold' of the Encoder Wheel.

I know you added a ability to set a switch to trigger babystepping.. i havent been able to get that working.. no matter what pin I set..

Have you turned on the Z-Baby-Stepping in Configuration_adv.h ? Without that enabled, it won't work.

[kmbecker13]

But the next simplest solution (that doesn't wear out the EEPROM) is to wait for a print to complete normally, and only save the Mesh at that point.

That sounds super nice, i dont think the user needs to ability to save to EEPROM during a print - and doing so at the end of the print should solve all needs?

Eliminating the z-offset altogether seems reasonable as long as we have a method of easily raising and lowering the mesh. Your idea from the other thread seems pretty good - i really like having a test pattern (similar to the G26) to get the height dialed in, a la Prusa

I disagree about making z-babystepping the default for the dial. I honestly hate that the dial does anything without a menu selection first, i've bumped it by accident before and changed things - which i don't like, but this is just my preference. The current system with a switch/button works well, but i think adding a menu option like Prusa has would be a nice feature (so users don't lose their kill pin or have to wire something else).

[adamfilip]

Saving at end of print sounds good
and then having Z babystepping in the root menu works too :) im easy

I also like the Z print test pattern idea..

[Roxy-3D]

I know you added a ability to set a switch to trigger babystepping.. i havent been able to get that working.. no matter what pin I set..

Have you turned on the Z-Baby-Stepping in Configuration_adv.h ? Without that enabled, it won't work.

@adamfilip Can you get to Z-Baby-Stepping via the LCD Panel Menu? If the Quick Access to Z-Babystepping isn't working for you, I want to get that fixed.

[adamfilip]

yes i can get to it under the tune menu at the bottom.

[Roxy-3D]

@adamfilip When you get your printer back together, you should be able to just enable this option:

#define QUICK_ACCESS_TO_Z_BABY_STEPPING_VIA_KILL_PIN    // CAUTION:  if you enable this option, the Kill Pin will no longer shut 
                                                        // down the printer when pressed.  It will enable Z-Babystepping.

You no longer have to specify a pin. It just takes over the Kill Pin. I'm working on the 'Press and Hold' version next.

[adamfilip]

Nice, going to be at least a week before i can try it..

[Roxy-3D]

Not a problem! I was just alerting you that it was available to test and use!

[lrpirlet]

@Roxy-3D
What a good idea to get rid of that Z-Offset, specially if it does simplify the code (non existant code cannot go wrong :-) ).

I may be wrong, but I perceive that using Z-Offset is more like hidding a lack of adjustment than a real production help. So I, personaly, make sure to never need it.

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