[Bug] Ender 3V2 z-offset tuning not working

[cosmoderp]

Bug Description

z-offset does not change live when using the tuning menu. I even cranked it all the way down to -6.72 without a bed crash.

My Configurations

@CRCinAU for configurations since its he keeps it private

Steps to Reproduce

1. start test print
2. go to tune menu
3. adjust z offset while printing
4. press button to commit
5. observe behavior

Expected behavior: when you adjust the z-offset while printing the z-offset should change.

Actual behavior: it does not respond to any changes.
https://www.youtube.com/watch?v=6C7-YI-uQ9s

[ellensp]

Cannot assist if you cannot attach config files.

[cosmoderp]

I mean it was the ender 3 v2 using DWIN. setting z-offset works and you can save it but the live tuning adjustments dont.

Dunno if thinkyhead still has this printer and might be able to say its just me alone having this issue anyway.

[boelle]

Configurations, please
Please ZIP up your Configuration.h and Configuration_adv.h files (as
requested in the Issue template) and drop them into your next reply.
We'll check them over and see if anything is amiss.

The issue template ask for those (if you even read the template) and they are easy to attach wo why not do it so that others have an chance of helping you

[fleek]

Not sure if this is a bug in Conditionals_LCD.H

#if ANY(HAS_Z_SERVO_PROBE, FIX_MOUNTED_PROBE, NOZZLE_AS_PROBE, TOUCH_MI_PROBE, Z_PROBE_ALLEN_KEY, Z_PROBE_SLED, SOLENOID_PROBE, SENSORLESS_PROBING, RACK_AND_PINION_PROBE) #define HAS_BED_PROBE 1 #endif

BLTOUCH is not specified.

[CRCinAU]

@fleek - I think you're on the right path here - the DWIN menu structure has:

inline void Prepare_Item_Offset(const uint8_t row) {
  if (HMI_flag.language_flag) {
    #if HAS_BED_PROBE
      DWIN_Frame_AreaCopy(1, 174, 164, 271 - 48, 479 - 302, LBLX, MBASE(row));
      show_plus_or_minus(font8x16, Background_black, 2, 2, 202, MBASE(row), probe.offset.z * 100);
    #else
      DWIN_Frame_AreaCopy(1, 43, 89, 271 - 173, 479 - 378, LBLX, MBASE(row));
    #endif
  }
  else {
    #if HAS_BED_PROBE
      DWIN_Frame_AreaCopy(1, 93, 179, 271 - 130, 479 - 290, LBLX, MBASE(row)); // "Z-Offset"
      show_plus_or_minus(font8x16, Background_black, 2, 2, 202, MBASE(row), probe.offset.z * 100);
    #else
      DWIN_Frame_AreaCopy(1, 1, 76, 271 - 165, 479 - 393, LBLX, MBASE(row)); // "..."
    #endif
  }
  Draw_Menu_Line(row, ICON_SetHome);
}

Therefore, if HAS_BED_PROBE is not defined, this won't get built into the screen.

Pointing to your suggestion here seems sane:
https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/Marlin/src/inc/Conditionals_LCD.h#L621

[CRCinAU]

Here is where the actual Offset gets applied:
https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/Marlin/src/lcd/dwin/dwin.cpp#L1090

Specifically, this part:

else if (encoder_diffState == ENCODER_DIFF_ENTER) {
      EncoderRate.encoderRateEnabled = 0;
      zprobe_zoffset                 = HMI_ValueStruct.offset_value / 100;
      #if HAS_BED_PROBE
        if (WITHIN(zprobe_zoffset - last_zoffset, Z_PROBE_OFFSET_RANGE_MIN, Z_PROBE_OFFSET_RANGE_MAX))
          probe.offset.z = zprobe_zoffset;
        settings.save();
      #elif ENABLED(BABYSTEPPING)
        babystep.add_mm(Z_AXIS, (zprobe_zoffset - last_zoffset));
      #else
        UNUSED(zprobe_zoffset - last_zoffset);
      #endif

      if (HMI_ValueStruct.show_mode == -4) {
        checkkey = Prepare;
        show_plus_or_minus(font8x16, Background_black, 2, 2, 202, MBASE(4 + MROWS - index_prepare), TERN(HAS_LEVELING, probe.offset.z * 100, HMI_ValueStruct.offset_value));
      }
      else {
        checkkey = Tune;
        show_plus_or_minus(font8x16, Background_black, 2, 2, 202, MBASE(5 + MROWS - index_tune), TERN(HAS_LEVELING, probe.offset.z * 100, HMI_ValueStruct.offset_value));
      }
      DWIN_UpdateLCD();
      return;
    }

I'm a bit confused by this logic... I can only assume that the HAS_BED_PROBE case is used for setting an offset with a probe attached, but it will fall back to using BABYSTEPPING if we don't have a probe configured in...

[cosmoderp]

config files.zip

as requested

[fleek]

@cosmoderp can you pull from my repo fleek/Marlin:bugfix-2.0.x and test if the fix works for you. If it works I will push the fix to the main repo.

[sjasonsmith]

I mean it was the ender 3 v2 using DWIN and I was nice enough to provide a video

Nothing in the title or description indicated this was an Ender 3 V2 or that it was DWIN. Videos are useful, but it's not reasonable to expect people to go watch videos when quickly screening issues to see if they can help.

It looks like there are configs attached now and someone is already trying to help, so hopefully something can be figured out.

[cosmoderp]

@fleek just tested it ... sorry had gone to work. Does not seem to have fixed it for me. I cranked it down all the way to -10 while printing a test print. and it should be around 4ish mm when bed crash. if there are changes to the main config file though and I was meant to simply make all the needed changes myself be advise. I am still pretty new to this and still used my original config files. thanks for your help.

[fleek]

@cosmoderp I am not sure about the units, but I think when you dial in 10, it will only move like 10/100 or 0.1mm, so you might want to dial in more to test.

[cosmoderp]

well what I did was max is out....the limit is z-offset -10mm. Baby stepping via commands works so I know it does that. I also just found that there was an option that lets you change the z-offset with the babysteps that I might turn on. Also to verify movement I both watched the motor and light laid my finger on the spindle to detect even the slightest movement.

[CRCinAU]

Yeah - the units here are in mm - the marlin limitation is +/- 10mm by default, and adjustable in 0.01mm increments.

[fleek]

@cosmoderp Can you please add to the title '[Bug] Ender 3V2' so that it can be identified specifically, because I think this problem is specific to Ender 3V2 because of the DWIN DGUS controller. I am trying to resolve this together with #18800, so it will take some time. The DWIN DGUS controller is still an unknown to me as well, as to the tools required and how the marlin firmware interacts with it.