Marlin: Display current/total babystepping offset when babystepping

[thehans]

Description

When adjusting babystepping, the menu starts with a value of zero. If I adjust some, then go back into babystepping to adjust once more, the offset is reset to zero. Its not clear if the firmware has actually reset the offset or if its being added to the previous offset. I think it would be most useful if the previous babystepping offset was kept when re-entering the menu, so the cumulative adjustment is fully clear.

Marlin 1.1.9 on RAMPS, with "Reprap discount smart controller"

Steps to Reproduce

1. Adjust babystepping (say by 0.100mm) and exit babystepping screen
2. Enter babystepping again (i'm using the "double click to babystep" feature, if that matters). And look at the value displayed

Expected behavior: [What you expect to happen]
Babystepping screen shows the current total babystepping offset applied.

Actual behavior: [What actually happens]
Babystepping starts at 0.000 every time, regardless of previous adjustments.

Additional Information

Configuration.zip

[thinkyhead]

Could be useful. But under what circumstances should the Z babystepping offset be cleared back to zero?

[thehans]

Upon machine reset I suppose (RAM clear).

I mainly picture this as a tool to adjust first layer height. In that sense if you found a good height why not keep it there, adjusting incrementally? Also would be nice if that babystep offset could be optionally saved to eeprom, and would be applied to the home offset automatically in the future.

[DrywFiltiarn]

I have to agree with @thehans on having an option to save the babystepping set and also on not clearing it as you leave the babystepping menu. Resetting back to zero makes sense in case the machine would be reset. As it is currently after doing an adjustment, then going back to homescreen and then doing another adjustment, you have no clue of what exactly the applied Z offset is.

In terms of saving the babystepping result to eeprom and restoring on machine restart would make sense as well. I have been struggling with the "bed z" option in the settings, and I can only conclude that no matter what value I set it to be it a positive or negative value it doesn't do anything at all. Whereas babystepping actually results in what I would expect the "bed z" configuration should do as well.

[Roxy-3D]

One answer might be to display both numbers. There is plenty of room on the Baby Step screen to do that. It could be made to display something like:

Baby Step Movement:
   This session:    0.000
   Since power up:  2.321

Unless there is very real value to saving a value in the EEPROM, that should be avoided. The EEPROM has a limited Erase/Write cycle count. We don't want to wear out the user's EEPROM.

[thehans]

@Roxy-3D sounds like a good solution to me.

[DrywFiltiarn]

@Roxy-3D fair enough indeed and I like proposed solution as to retaining the babystep value. Perhaps it is a good idea to look into the "Bed Z" config and actual use as well, as that would basically do the same as storing the babysteps I think, except it doesn't seem to work.

[thinkyhead]

With SRAM always at a premium, it is preferred that all new features that use SRAM be implemented as optional features, and not be required/enabled for all setups.

[Roxy-3D]

@Roxy-3D fair enough indeed and I like proposed solution as to retaining the babystep value. Perhaps it is a good idea to look into the "Bed Z" config and actual use as well, as that would basically do the same as storing the babysteps I think, except it doesn't seem to work.

I'm ready to start this... It will be a Configuration_adv.h option in the BabyStepping section of the configuration file. I'm not sure yet, but enabling it might force the text size to be reduced so that both lines can be displayed.

With SRAM always at a premium, it is preferred that all new features that use SRAM be implemented as optional features, and not be required/enabled for all setups.

Of course! Doing this will cost 4 bytes of RAM to hold the extra float variable.

[Roxy-3D]

@thehans @DrywFiltiarn

You can try the code at: https://github.com/MarlinFirmware/Marlin/pull/13580 and see if it does everything you want and need.

[grawi-sikorsky]

I think that storing babystepping in eeprom isn't very bad idea. I made such "improvement" with no worries long time ago by easy calculation:
Let's say, on one machine user starts 10 prints/day, and make 2 adjustments per print.
Math: Saving babysteping position even 20 times a day * 365 days = 7300 cycles/year.
Even 10 years of such practice shouldn't wear out eeprom badly.. In 3d printing industry just 3 years is almost like thousand light years, so we shouldn't care about eeprom so much ;)
Regards!

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