Manual Mesh bed leveling cause E2 to have a Z offset after tool change

[abbrowna]

Describe the bug I have enabled manual mesh bed leveling in the source and generated a mesh using a piece of paper and Gcode commands. (The mesh works great if only printing with E1). E2 is also physically adjusted so that the Z offset with respect to E1 is 0. With mesh bed leveling enabled using M420 S1, the blue strip shown in screenshot 1 below is printed by E2 way too close to the bed. While the orange strip printed by E1 is good with level compensation happening.

The Gcode generated by prusaslicer for the above scenario, the exact mesh I am using and my modified configuration files are in the attached zip. mesh_Z offset files.zip

To Reproduce

1. Enable mesh bed leveling in firmware. (see my configuration files)
2. Apply a mesh. ( Mine is in the file mesh.gcode)
3. Attempt to print the file Dual Y strips.gcode

I may have narrowed down the problem to the point of toolchange with the following steps to reproduce.

1. Enable mesh bed leveling in firmware. (see my config files)
2. Apply a mesh. (Mine is still in the file mesh.gcode)
3. Run the following tool change Gcode:

   G28
   G1 Y150
   M420 S1
   G1 Z0
   M111 S247
   T1
   M114
   T0
   M114
   T1
   M114

   Notice how the Z position changes during and after tool change. This change is not present if you do not enable the mesh with M420 S1

Expected behavior I expected the second strip done by E2 to be more or less as tidy as the one done by E1. I expected that after toolchange, the parked Z position of the new tool remains Zero.

Firmware and slicer

• Firmware: Marlin 2.0.7.2 for Luxuri 0.8.0
• Slicer: Prusaslicer 2.3.2

Additional context Current eeprom values are as follows:

echo:; Home offset:
echo:  M206 X0.00 Y0.00 Z1.75
echo:; Hotend offsets:
echo:  M218 T1 X353.38 Y-1.64 Z0.000
echo:; Mesh Bed Leveling:
echo:  M420 S0 Z10.00
echo:  G29 S3 I0 J0 Z0.00000
echo:  G29 S3 I1 J0 Z-0.10000
echo:  G29 S3 I2 J0 Z-0.16000
echo:  G29 S3 I3 J0 Z-0.08000
echo:  G29 S3 I4 J0 Z0.08000
echo:  G29 S3 I0 J1 Z0.02000
echo:  G29 S3 I1 J1 Z-0.06000
echo:  G29 S3 I2 J1 Z-0.12000
echo:  G29 S3 I3 J1 Z-0.04000
echo:  G29 S3 I4 J1 Z0.14000
echo:  G29 S3 I0 J2 Z0.00000
echo:  G29 S3 I1 J2 Z-0.10000
echo:  G29 S3 I2 J2 Z-0.18000
echo:  G29 S3 I3 J2 Z-0.06000
echo:  G29 S3 I4 J2 Z0.12000
echo:  G29 S3 I0 J3 Z0.04000
echo:  G29 S3 I1 J3 Z-0.08000
echo:  G29 S3 I2 J3 Z-0.16000
echo:  G29 S3 I3 J3 Z-0.06000
echo:  G29 S3 I4 J3 Z0.14000
echo:  G29 S3 I0 J4 Z0.00000
echo:  G29 S3 I1 J4 Z-0.14000
echo:  G29 S3 I2 J4 Z-0.22000
echo:  G29 S3 I3 J4 Z-0.12000
echo:  G29 S3 I4 J4 Z0.08000
echo:  G29 S4 Z0.00000

echo:; Tool-changing:
echo: Z2.00

[abbrowna]

Update: I seem to have found a temporary fix. I commented out line 903 "TEMPORARY_BED_LEVELING_STATE(false); " in tool-change.cpp to prevent it from disabling leveling during toolchange:

    #if HAS_LEVELING
      // Set current position to the physical position
      //TEMPORARY_BED_LEVELING_STATE(false);
    #endif

After testing, my two strips are now even. But who knows what can of worms I have opened by changing this.

Another change I did (which I am not sure if it contributed to the fix) is setting TOOLCHANGE_ZRAISE to 0.

[abbrowna]

This issue seems to have been fixed, I did not experience nor implement my change when grabbing the latest version of Lux marlin

[klack]

@abbrowna Thanks for updating and experimenting! Seems like this was a bug within base Marlin.