[BUG] Live Z offset adding on top of existing offset

[liamtoran]

Bug Description

Hi, I have an ender3 v2 and I'm on the bugfix-2.0.x branch, last updated 18/10/2020. I'm having an issue with changing Z offsets during a print. Sometimes changing the Z offset during a print adds the new absolute value on top of the offset that was saved in the settings before a print.

What is strange is that this doesn't always happen. I can not pinpoint when it will and when it wont.

This did not happen to me before using BLTouch so it might be related.

My Configurations

Configurations.zip

Steps to Reproduce

1. Set Z offset set at -2.00 before the print. (the value itself doesn't seem to matter)
2. Start the print
3. Change the offset to -2.01 (the value itself doesn't seem to matter) during a print and do this with the in-print menu.

Expected behavior: [What you expect to happen]
4. Z travels -0.01 from the current -2.00
Actual behavior: [What actually happens, not always ]
4. Nozzle catastrophically hits the bed. My Z traveled -2.01 on top of the original -2.00 position instead of moving -0.01 relatively

[valkokir]

Just chiming in that I have the same issue. Same printer. I've tried multiple different firmware versions. I can reproduce 95% of the time but sometimes it works as expected. I have had this issue happen whether the BLTouch is wired entirely though the dedicated port on the 4.2.2 board or the z-axis home switch port. I doubt this is terribly helpful but I didn't see anyone else speak up that they are seeing the same. Subscribed and happy to upload info as required also. Thank you!

[sjasonsmith]

Some questions about your steps above:

1. Are you starting the print through the LCD, or printing over serial?

2. On step 3, when you enter the display does it show -2.00 before you change anything? In other words, are you changing it from -2.00 to -2.01, or from -0.00 to -2.01?

[valkokir]

1. Printing over LCD, I;ve never run the serial interface.
2. display shows -2.00, trying to adjust to -2.01 or -1.99 it immediately dives.

[valkokir]

I just spent a bit of time recreating this but wanted to do so without risking crashing my nozzle.
I typically print with a -2.08 offset.

Note the below is all done from the LCD on my Ender 3 V2 with BL-touch running Smith3D firmware installed Oct 15, 2020

1. I started by going in and setting my Z-offset to 0.00, Store settings. Shut off the printer and turned back on for good measure. Started a print, adjusted on the fly to -1.0, -1.5, -2.08 and no issues.

2. Next, I set the Z-offset to -1.00, Store settings, shut off the printer and turn back on. Started a print, adjust on the fly from -1.00 to -1.02 press the encoder wheel and the Z immediately dove to a height right at bed height, no way to measure it but best guess is it was at -2.02mm.

I did take a video and put it on youtube. video link

I hope this helps.
Thanks for your time.

[liamtoran]

Thanks Valkokir, I can also confirm I only print over LCD and that the display shows the previous number (-2.0). I can also add that the -2.00 in my example set from the start is taken into account by the printer. (At the end of step 4 the real offset is most likely -4.01 (no way to measure it for sure) instead of -2.01).
Valkokir's video's shows it exactly.
For a less dangerous testing maybe setting +4.99 in the settings and going to +5.00 in the live offset menu would also show the bug

[tanvach]

Also can confirm this issue with with vanilla 2020-11-01 2.0.x bugfix, Ender v2 with BL touch. I have BABYSTEP_ZPROBE_OFFSET on.

This is my first time contributing to Marlin so may not know the process yet, but here're some things I've found.

Seems like in dwin.cpp here, the new offset is subtracted from old last_zoffset. I suspect last_zoffset remains 0 when this bug happens.

Looking at blame, seems like there was a refactor, which changed the check for large offset change to different logic, which I believe might not be correct. This doesn't solve the root problem, but may have helped stop catastrophic nozzle crash.

Tagging @thinkyhead who's the author of #19384

[jernejp21]

I have used debugger to check some weird stuff. If you go to "Prepare" menu and click on Z-offset (don't rotate the knob) and click again, value will reset to 0. I have added a bit of code to enable the correct variable after printer is turned on.
@valkokir I wasn't able to reproduce your problem (saw the video). Can you input my fix and test it to see if it's ok now?

In dwin.cpp file search for void Draw_Status_Area(const bool with_update) function. Go a bit down and add a line. Recompile and report if it's working. Thank you.

#if HAS_ZOFFSET_ITEM
    DWIN_ICON_Show(ICON, ICON_Zoffset, 158, 428);
    dwin_zoffset = BABY_Z_VAR; //add this line
    DWIN_Draw_Signed_Float(DWIN_FONT_STAT, Color_Bg_Black, 2, 2, 178, 429, BABY_Z_VAR * 100);
  #endif

[valkokir]

I'm happy to report that this seems to have fixed the issue. Hopefully some others can test as well and see if they find the same. I will try and mess with it some more to see if I can get it to act up but it's not an adjustment I make too often.
Thank you for looking into this so quickly!

[liamtoran]

I merged the commit from thinkyhead referenced above this comment and looks good so far! It was a sporadic bug so I will probably close the issue in a few days if it continues working.

[liamtoran]

Has been working flawlessly, thank you!!

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