Skip to content

Add support for calculating points like mesh_min and mesh_max based on physical bed size#879

Open
Luro02 wants to merge 8 commits intoKalicoCrew:mainfrom
Luro02:feature/automatic-offsets
Open

Add support for calculating points like mesh_min and mesh_max based on physical bed size#879
Luro02 wants to merge 8 commits intoKalicoCrew:mainfrom
Luro02:feature/automatic-offsets

Conversation

@Luro02
Copy link
Copy Markdown

@Luro02 Luro02 commented Apr 28, 2026

What will this PR introduce?

This PR extends Kalico with sections for specifying the physical bed size and where the nozzle would have to move, to be over the bed corner:

[printer]
kinematics: corexy
max_velocity: 400
max_accel: 5000
max_z_velocity: 30
max_z_accel: 350
square_corner_velocity: 5.0

bed_size: 300, 300
bed_corner_position: -4.3, -10.8

The properties will then bed used to calculate positions that previously had to be specified by the user.

For example, in the bed_mesh section, the user had to specify the bed_min and bed_max positions, defining the corners of the mesh that should be probed.

With this PR, the user can omit them, and instead specify a margin (how much the mesh should be away from the edges of the bed):

[bed_mesh]
zero_reference_position: 150, 150
speed: 300
horizontal_move_z: 3
margin: 30, 30
probe_count: 30, 30
algorithm: bicubic

The code will then calculate mesh_min and mesh_max based on the defined physical properties and the desired margin.

This PR updates the following sections to take advantage of this feature

  • [bed_mesh]
  • [quad_gantry_level]
  • [safe_z_home]
  • [axis_twist_compensation]

other sections might be implemented by others in future pull requests.

Why is this needed?

In many configuration sections points have to be specified that depend on the position of the bed, the offset of the probe and the physical limits of where the printer can move to:

  • bed_mesh
  • bed_tilt
  • bed_screws
  • screws_tilt_adjust
  • z_tilt/z_tilt_ng
  • quad_gantry_level
  • safe_z_home
  • axis_twist_compensation

When you change any of the following

  • The bed position
  • The min_position/max_position reachable on the axis, for example by switching to a different toolhead
  • The probe offset

you would have to go through every section and recalculate or update the positions. This is time-consuming, error-prone and can be confusing, because some sections use probe offsets, others not.
PR #500 added the use_probe_xy_offsets option, which allows making certain points relative to the probe. If there is enough space to move, this is not a problem, but consider the following example where
p is the probe and n the nozzle:

+----------------+
|                |
|                |
|                |
|                |
|  p             |
+----------------+
   n

now the offset in x direction is increased:

+----------------+
|                |
|                |
|                |
|                |
|  p             |
+----------------+

   n

The probe point remains the same, but it might not be possible to reach that position anymore, because the nozzle is too far from the bed. The use_probe_xy_offsets helps when the probe offset changes, but it does not have a concept of where the bed is or account for the axis limits, resulting in potential crashes into the bed or move out of bounds errors.

In the PR for the use_probe_xy_offsets, a kalico crew member commented:

So, I think with this, we could add a probe_margin, e.g. the sense radius on beacon.

Then we just have a bed size, and can mesh the safe region based on toolhead min/max plus probe offset plus margin.

#500 (comment)

Suggesting that this feature is desirable.

Checklist

  • pr title makes sense
  • added a test case if possible
  • if new feature, added to the readme
  • ci is happy and green
  • Add support for Quad Gantry Level
  • Add support for Axis Twist
  • Add support for calculating bed center in safe_z_home
  • Ensure the code does work on different kinematics systems
  • Allow keeping aspect ratio if desired
  • Axis twist should have the fields initialized for compatibility with external projects like carto

@Luro02 Luro02 force-pushed the feature/automatic-offsets branch 2 times, most recently from c3f16d4 to c3105bb Compare May 2, 2026 10:05
@Luro02 Luro02 marked this pull request as ready for review May 3, 2026 13:57
@Luro02 Luro02 force-pushed the feature/automatic-offsets branch from b63723c to 16d2d4a Compare May 5, 2026 11:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant