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

[lwaynej]

I think I am seeing a similar issue. My printer uses the SKR 1.4 and I use a BLTouch for the Z endstop (I am not using bed leveling at this point, it is turned off in the printer settings.) I suspect this is a configuration issue.

I was using 2.0.5.3 as a base. My code is now based on 2.0.6 (84b96d3d4) and the Z probe offset no longer appears to work. My probe offset is about -2.22. Now matter what I see the offset to in the menu the distance between the nozzle and the bed are about -2.23 after auto home and moving Z to 0. I have diff'd Configuration.h and Configuration_Adv.h between the working and none working builds and the only differences occur in things that changed between the two releases.

Here are my observations:

1. Z homing was not working at all until I uncommented "USE_PROBE_FOR_Z_HOMING"

2. (After enabling) Z Homing with the BlTouch only does the fast probe. Previously it did a fast probe to figure out where it was at and then a slow probe for accuracy (I don't see an obvious way to change this.) Maybe this change was intended ...

3. The Z probe offset is being ignored. The zero position for the Z axis is always the same (I turn off soft end stops and adjust the gap using 0.1 mm feeler gauge.) I have configured #define NOZZLE_TO_PROBE_OFFSET { 0, -41, -2.22}. After homing and using "Move Axis" to set my Z to 0 I am still 2.22 mm above where I want it to be. Using the configuration menu I have set the offset to -4.44 and I am still 2.22 mm above where I want the axis to be.

I have (I hope) attached my Configation.h and Configuration_Adv.h.

MarlinConfig-2.0.6.tar.gz

[cosmoderp]

I figured out why this was not working on my ender 3 v2 todays perhaps you have a new bug. It turned out that creality made a mistake when designing the menu. It was a simple mistake in programming the menu. I have mine working now the way its supposed to be. lwaynej perhaps you should start a new bug report by the looks of your issue. Make sure you that you reset the eeprom, save it, then powercycle first. Just in case.

[cosmoderp]

This turned out to be a simple menu programming error of the menu. I have been working on a menu and hope to push out a fix soon.

[SlackHacky]

@cosmoderp would love the menu fix info

[brianjackson1]

@cosmoderp Has this been added to the nightly builds yet?

[cosmoderp]

I did a pull request today.....sorry it took so long I had to learn how to use git

[brianjackson1]

Many thanks for all your work on this. Hopefully it will be added to the next nightly build.

[ivanwong1989]

Question. To have this fix, i just need to download and compile bugfix branch and flash the printer? Do i need to flash the LCD as well? i think with DWIN_SET?

[brianjackson1]

Having looked at #19384 I believe the fix is actually in the Marlin Dwin file which at the moment is just a work in progress. Looks like we have to wait a while longer for this to be released.

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