Assisted Tramming not working due to incorrect TRAMMING_POINT_XY

Marlin Firmware Service Bug Reports
1

Setup
Ender 3, 4.2.7 board, Micro Swiss DD Kit with all metal hot end, CR Touch, right mounted on Petsfang blokhead fan shroud.

Your Firmware Builder exposes ASSISTED_TRAMMING and ASSISTED_TRAMMING_WIZARD but does not expose NOZZLE_TO_PROBE_OFFSET or BED_TRAMMING_INSET_LFRB.

The resulting firmware has incorrect values for these, which results in Marlin refusing to probe Front-Left or Back-Left because it’s out of range of the probe. NOZZLE_TO_PROBE_OFFSET Probe offsets can be set in the LCD menus but BED_TRAMMING_INSET_LFRB cannot AFAIK, which means they need to be set in the firmware builder. In my case I needed
#define NOZZLE_TO_PROBE_OFFSET { 49.5, 1, -2.11 } and #define BED_TRAMMING_INSET_LFRB { 49.5, 49.5, 49.5, 49.5 } in order to set #define TRAMMING_POINT_XY { { 49.5, 30 }, { 205, 30 }, { 205, 205 }, { 49.5, 205 } } so that the firmware would probe the correct points during the assisted tramming operation.

As is now, the Assisted Trimming as generated by your Firmware Builder will not be usable to most people. It generated "TRAMMING_POINT_XY": "{ { 20, 20 }, { 180, 20 }, { 180, 180 }, { 20, 180 } }", so as you can see, the 20 value is far below the minimum 49.5mm on the x axis I would need. to probe all four points.

There are two options I can think of:
1- Expose NOZZLE_TO_PROBE_OFFSET in the UI and calculate the values for BED_TRAMMING_INSET_LFRB and TRAMMING_POINT_XY by subtracting the NOZZLE_TO_PROBE_OFFSET x value from the X_BED_SIZE value (and the same for the y values)
2- Expose NOZZLE_TO_PROBE_OFFSET, BED_TRAMMING_INSET_LFRB and TRAMMING_POINT_XY to let the user decide. You’d have to do some validation to make sure the user wasn’t entering invalid values, but the advantage of this is that the user may want to get their four tramming points in as identical of a position as possible, so they may want to set #define TRAMMING_POINT_XY { { 49.5, 49.5 }, { 185.5, 49.5 }, { 185.5, 185.5 }, { 49.5, 185.5 } } (all points equal distance from the corners) or in my case, get the tramming points as close to the bed leveling screws as possible with only the front left and back left being slightly right of the bed leveling screws.

2

Re NOZZLE_TO_PROBE_OFFSET, its better to set these in the Start G-Code in your slicer.

The best practice has been to always expand your Start G-Code to set up your printer as if it was reset to factory defaults right before your print. This includes things like the probe offset, the steps setting, any other non-factory settings. Essentially, this is a safeguard to ensure that your printer is correctly configured on each print.

As is now, the Assisted Trimming as generated by your Firmware Builder will not be usable to most people.

Yeah - this has always been a Marlin problem in how the points are interpreted. It can’t be fixed in firmware as the implementation is currently written. This is because when a probe is put into the mix, it will still have points that the probe cannot reach.

To have this work, then the NOZZLE_TO_PROBE_OFFSET has to be set to 0,0 - which is not able to be done without static, unchanging values everywhere. Of course, this all goes out the window when the probe offset is anything but 0,0. Any other value pushes the target coordinates outside of the box set by TRAMMING_POINT_XY - resulting in a value that is physically not reachable by the probe.

Ideally, a new implementation should happen in Marlin where it takes X_MAX, then applies the probe offset and comes up with a new location. This is not how its currently implemented however.

3

Yeah - this has always been a Marlin problem in how the points are interpreted. It can’t be fixed in firmware as the implementation is currently written. This is because when a probe is put into the mix, it will still have points that the probe cannot reach.

My manually configured configuration.h and configuration_adv.h works correctly for Marlin’s current implementation. I understand what you’re saying about the way they should be doing it, but for now they don’t do it that way.

Without you exposing in your UI at least the TRAMMING_POINT_XY values, anyone expecting your generated firmware to have working Assisted Tramming will be disappointed.