BED_MESH_OFFSET doesn't seem to work properly

[Mario]

Basic Information:

Printer Model: Replicator 2X
MCU / Printerboard: MightyBoard Rev G, ATmega1280
klippy.zip (682.4 KB) (exported just after the left and right nozzle test prints were done)

Describe your issue:

I have a dual-nozzle printer with a Beacon ABL probe. When printing with the left nozzle (the primary extruder, that the probe offsets are relative to, and that I did the probe calibration with), I get good results on a first-layer test. When printing with the right nozzle, which uses BED_MESH_OFFSET (and SET_GCODE_OFFSET) as described in the documentation, I get poor results (underextrusion in some areas, but more importantly, not identical results compared to the left nozzle despite printing on the exact same area of the build plate). Only the right nozzle exhibits the issue. Photos at the bottom.

The documentation for BED_MESH_OFFSET says “a positive X offset should be specified if the secondary extruder is mounted to the right of the primary extruder”. The second nozzle is to the right, and I have specified a positive offset.

My probe and nozzles are all aligned in X (no Y offset). The probe is leftmost, 36mm to the right is the primary extruder, and 35mm more to the right is the secondary extruder.

Here are my T0/T1 macros:

[gcode_macro T0]
gcode:
    SET_GCODE_OFFSET X=0 Y=0
    BED_MESH_OFFSET X=0 Y=0
    ACTIVATE_EXTRUDER EXTRUDER=extruder

[gcode_macro T1]
gcode:
    SET_GCODE_OFFSET X=-35 Y=0
    BED_MESH_OFFSET X=35 Y=0
    ACTIVATE_EXTRUDER EXTRUDER=extruder1

And probe config:

[beacon]
serial: /dev/serial/by-id/usb-Beacon_Beacon_RevH_0E2FA4724E5737374D202020FF113C29-if00
; Probe is left of the left nozzle, centered in Y
x_offset: -36
y_offset: 0
mesh_main_direction: x
mesh_runs: 2
cal_nozzle_z: 0.3

[bed_mesh]
algorithm: bicubic
bicubic_tension: 1.0
speed: 200
#   Movement speed during mesh measurement.
zero_reference_position: 125, 75 ; 125, 75 nozzle position
#   Setting this parameter will normalize mesh adjustments to the offset found
#   at the specified position. This should nearly always be the same as your
#   safe_z_home position and the position where beacon_calibrate was performed.
mesh_min: 17, 7 ; 53, 7 nozzle position when probe is in correct spot
mesh_max: 204, 140 ; 240, 140 nozzle position when probe is in correct spot
probe_count: 19, 13
fade_start: 1
fade_end: 10

Probe and mesh offsets are correct, I can see the probe moving to the intended locations when running a bed mesh and when doing the z offset calibration (nozzle and probe go to the same location).

My first-layer test print is printed with the exact same gcode for the left and right nozzles, only my START_PRINT line is altered to specify the left or right nozzle, which heats the correct one and then calls T0/T1. The gcode offset is correct and causes the prints to be printed in the same spot on the bed for either nozzle.

What I’ve tried:

1. Swapped filaments between the nozzles. I got the same results either way, perhaps some slight differences, but clearly not the problem
2. Test prints with BED_MESH_OFFSET to -35 and 0. These produced different results than 35 offset, but still not correct, and definitely not the same as with the left nozzle
3. Disabled X-axis twist compensation. Same result. Side note, does this take into account gcode offset?
4. Checked height difference between the nozzles with an 0.3mm metal shim and slowly raising Z (from the same direction both times to eliminate backlash, and in the same spot on the bed). Right nozzle seems to be 5-10 microns higher (2-4 Z microsteps), I don’t think this would cause the difference I’m seeing.

I am running unofficial MCU code. GitHub - dockterj/klipper: Adding support for MakerBot Replicator 2
I unfortunately don’t have a way to test with the main branch because it doesn’t yet support the later MightyBoard revisions. I’ve been using this firmware for ~100 hours and haven’t had any problems. I only got the Beacon recently and have been running tests, whereupon I found this issue. Klipper is fully up to date and this firmware also just pulled in the upstream changes last week.

First layer test results. Main area to pay attention to is the middle-right and bottom-right squares. Even the left nozzle isn’t perfect everywhere (I suspect a slight Y axis twist on my printer causing the probe to have a Y-dependent change in angle along X), but I’d call it definitely good enough. No major over or underextrusion in the middle of any square.

Left nozzle (no X-twist compensation, 0 gcode/mesh offset):

Right nozzle (no X-twist compensation, -35 gcode offset, 35 mesh offset):

Comparison of the worst areas:

In the same color for a better comparison. I don’t think the nozzle height difference would cause this, the initial babystepping I did was ~50 microns and it gave a similar change in extrusion fill. The nozzle height difference is 5-10x smaller

A representative bed mesh, as probed. Note, the problem areas highlighted above are outside the probing area, but even still, I would at least expect the same results as from the left nozzle.

[Mario]

I realized one potential problem is that if the bed height deviation is high enough within the span of the nozzles, then the non-printing nozzle would ride on top of the already-printed plastic and push the printing nozzle higher, possibly negating the bed mesh altogether. (Technically this will always happen, but I think it would only become much of a problem if the deviation is too high.)

With this test print specifically, when printing with the left nozzle, the right nozzle is completely off the bed and thus wouldn’t have this problem. But with the right nozzle, the left is over the bed and could cause this problem. To make sure this isn’t the case, I printed 30x30mm squares (nozzle spacing is 35mm) in the corners and middle of the bed, so the non-printing nozzle cannot drag across any already-printed material.

Except, I’m now getting the results I would have expected from this test! The print from either nozzle looks very similar. So it seems, as usual, it’s a problem with my hardware and not the wonderful software you guys have written. Though I am a bit confused by this, because I would have only expected underextrusion on the previous right-nozzle test in the horizontal strip where the left nozzle would drag on top of the print - but there’s clearly underextrusion in the whole square. Hmm.

Well, guess I’m gonna need a flatter bed or to remove one of the nozzles!

I’ll update this topic if I find concrete evidence of any problem, but things look good for now.

Not the best photo, but in person these squares are extremely similar, certainly far more than I was getting before.