# Assisted Tramming not working due to incorrect TRAMMING\_POINT\_XY
**URL:** https://marlin.crc.id.au/forum/t/assisted-tramming-not-working-due-to-incorrect-tramming-point-xy/2109
**Category:** Bug Reports
**Created:** [22 March 2024 22:37 UTC](https://marlin.crc.id.au/forum/t/assisted-tramming-not-working-due-to-incorrect-tramming-point-xy/2109 "2024-03-22T22:37:04Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@objecttothis](https://marlin.crc.id.au/forum/u/objecttothis)
#### Post date: [22 March 2024 22:37 UTC](https://marlin.crc.id.au/forum/t/assisted-tramming-not-working-due-to-incorrect-tramming-point-xy/2109/1 "2024-03-22T22:37:04Z")
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.
---
### Author:  [@CRCinAU](https://marlin.crc.id.au/forum/u/CRCinAU)
#### Post date: [23 March 2024 01:51 UTC](https://marlin.crc.id.au/forum/t/assisted-tramming-not-working-due-to-incorrect-tramming-point-xy/2109/2 "2024-03-23T01:51:13Z")
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.
---
### Author:  [@objecttothis](https://marlin.crc.id.au/forum/u/objecttothis)
#### Post date: [23 March 2024 06:28 UTC](https://marlin.crc.id.au/forum/t/assisted-tramming-not-working-due-to-incorrect-tramming-point-xy/2109/3 "2024-03-23T06:28:17Z")
> 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.