Fix bilinear ABL grid_start probe/nozzle coordinate mixup

[PenguinAkiko]

Description

This PR fixes a critical coordinate-space mixup for the bedlevel.grid_start position when using Bilinear Auto Bed Leveling (AUTO_BED_LEVELING_BILINEAR).

The Problem:

The bilinear ABL probing process builds its mesh in probe-space, where abl.probe_position_lf represents the coordinate directly under the probe. However, the resulting bedlevel.grid_start value is later consumed by other systems (like bedlevel.get_z_correction()) as a motion/nozzle-space origin.

On machines with a non-zero NOZZLE_TO_PROBE_OFFSET in the XY plane, this discrepancy caused the entire leveling mesh to be incorrectly shifted by the probe's XY offset, leading to inaccurate bed compensation.

The Solution:

To resolve this, this PR introduces a centralized utility function, Probe::convert_to_nozzle_xy(), to handle the conversion from probe-space to nozzle-space. This function is now used in two key locations:

1. In G29: The bilinear grid origin is now converted to nozzle-space before it is compared with a stored mesh or saved with bedlevel.set_grid().
2. In M420 S2: The test pattern generator is also updated to use the same conversion, ensuring that all methods of generating a bilinear mesh use consistent, nozzle-space coordinates for the grid origin.

This change has no functional effect on setups where the XY probe offset is zero or when using NOZZLE_AS_PROBE.

Requirements

Any 3D printer configured with AUTO_BED_LEVELING_BILINEAR.

Benefits

Fixes a bug that incorrectly shifted the entire Bilinear ABL mesh by the probe's XY offset.

Configurations

No configuration files are attached as the change is hardware-independent.

To test this PR, any configuration with the following enabled will reproduce the issue and verify the fix:

// in Configuration.h
#define AUTO_BED_LEVELING_BILINEAR

// A probe with an XY offset from the nozzle
#define NOZZLE_TO_PROBE_OFFSET { 10, -5, 0 }

Related Issues

Fixes a bug that does not appear to have a corresponding open issue.

[DerAndere1]

In my recent experiments with probing, I set up the probe as a dedicated tool (dummy extruder) with hotend offsets for the probe being equal to NOZZLE_TO_PROBE_OFFSET with good success.:

#define EXTRUDERS 3
#define NOZZLE_TO_PROBE_OFFSET {40, 40, -10}
#define HOTEND_OFFSET_X {0, 20, 40}
#define HOTEND_OFFSET_Y {0, 20, 40}
#define HOTEND_OFFSET_Z {0, -5, -10}
#define PROBING_TOOL 2

The trouble I had in getting probing to work indicates that the proposed changes are indeed needed. Or maybe we just need to improve documentation on how to set up a probe for G30, G38 and G29.

[Maker-Paul]

Hi. I have a pull request I think yours might be connected to. My issue involves using a separate Z stop and probe #28418. I have extensively tested and regularly printed graphic representations of the bed map and still have tiny discrepancies in the mesh values I haven't identified. My machine now probes at the XY home position before commencing with G29. The probe trigger height is then taken off the probe readings for the rest of the mesh readings (probe Z offset). That should mean that when the probe measures the bed at the XY home position (bed center) during the mesh scan it should read 0 but it never does.

I can see that an area roughly corresponding to the XY probe offset is very close to 0 now I have reviewed my maps. Is that what you would expect to see? The difficulty here is that the differences in the mesh values is now so small, because of all the major improvements I've made, they are almost lost in the noise caused by thermal expansion and repeatability accuracy of the probe.

The first image shows a Bed map control taken a few days ago compared to one just done. with the Bed cold.

Legend Red is above 0, Yellow is below 0, Blue is 0
The image below shows the bed is very consistent between origonal scan and two days later (16/04/2026).

This image below shows the surface topology after the bed has heated and soaked for 15 minutes (The bed was trammed Hot nearly a week ago)

The Mesh visualizer is a spread sheet I created to display the data provided from the printer with M503.

[Maker-Paul]

This is a comparison of the cold control from a couple of weeks ago and one done today 28/04/2026 with your fix applied to my local firmware build. note the square just above the center square which is the XY home coordinate is 0.008 and is the closest of any point on the mesh to the expected 0. I Since checked my Y offset to find it was a bit out which would account for this so I will rerun the test.

Bed Mesh cold comparison with #28380 applied

I still have an issue where all the values in the mesh seam to slowly increase if I don't reset the Eprom quite often, so there is still an accumulative error getting in to the calculations somewhere. Any thoughts?

[Maker-Paul]

Now with my corrected X and Y offsets. Looks pretty good the center square and the one above are the closest to 0 either side of it so the actual zero must be between them. that looks to be pretty much the center of the bed. The actual values at 3 decimal places are getting into the repeatability tolerance of the sensor. The sensor is 17mm square at the bottom and although I assume it reads at the center of that 17 x 17mm there is no guarantee of that. But I think the pattern is pretty easy to see.

Thanks for your efforts I will be keeping your fix in the local firmware build that I use on my Tronxy's