Bed mesh first probed coordinate

General Discussion
1

I got a question about a development choice of the bed_mesh:
When I configured my bed mesh settings I first tried to set the min/max to mesh_min: 107.5, -65 , mesh_max: -112.5, 40 but this resulted in an “bed_mesh: invalid min/max points” error. Since the docs say mesh_min is used as “The first probed coordinate” and I wanted the calibration to start at this position I didn’t expect it to give an error.
Obviously bed_mesh calibration works fine when I swap the mesh_min_x and mesh_max_x, but in order to save on toolhead travel (thus time) I would still like to use the aforementioned setting. I see no reason why this wouldn’t work (on a rectangular bed at least), so I looked up the code and it should work just fine. I removed the error check and tested it with success.
I bet the error message was added for a reason, so this leaves me wondering what the intention was of this check and what I missed :sweat_smile:
If it turns out the min/max validation isn’t actually needed, can I just create PR?

2

Your mesh_min: 107.5, -65 , mesh_max: -112.5, 40 looks strange for a rectangle bed. Are you using origin center with a rectangle bed? And if yes, why?

3

Yes, and there’s no particular reason :see_no_evil:
It’s just how I set it up once, and never changed it. It works well though, so I don’t really see a reason to change it (as a side effect it’s easy to center the toolhead). But this is uncommon apparently? :sweat_smile:

Even if I change it (to only positive values starting at 0 for example), the mesh_min still won’t pass the error check if I want calibration to start at the right side of the bed, right?

4

Well, it is sort of a convention to have the origin in the bottom left-hand corner for a rectangular bed, and I have never had a problem with this in the way you describe. It also matches the positions of the endstops and the position_max / position_min values (depending on the position of the endstops).

Note that the coordinates for mesh_min and mesh_max are relative to the probe. IMO the easiest workflow to determine is (rectangular bed, bottom left origin)

  1. Move the toolhead to the bottom left corner. Move it so that the tip of the probe is as close as possible to this corner of the bed.
  2. Issue a GET_POSITION and note the toolhead coordinates.
  3. Correct these coordinates by the offset of your probe → this is your mesh_min.
  4. Move the toolhead to the top right corner. Again, make sure that the tip of the probe is as close to this corner of the bed as the kinematics will allow.
  5. Repeat steps 2 and 3 to obtain mesh_max.
5

Thank you for your explanation.
I noticed you set “bottom left corner” as the mesh_min, ever tried to set the bottom right corner to mesh_min in order to start the calibration at a different position?

6

Never tried and I do not think it is possible, or let me word it differently:

  • All my printers have their endstops at the max positions
    • Y at the back of the printer
    • X on the right side
  • This automatically means that 0,0 is to the front and to the left and this is how Klipper naturally calculates its movements

If you try to mess with this, then I would expect strange errors.

7

I’m afraid I disagree with you (might be out of ignorance on my side though :laughing:).
I never experienced any odd behavior by setting it to origin center. Klipper movement calculations are fine with whatever stepper min/max positions are given (apart from reversing orientation probably).
Setting the stepper_z position_min to -1 isn’t uncommon as far as I know, just to give the bed_mesh some space to do its compensation. Telling me using negative values isn’t impossible nor discouraged.

Even if 0,0 is supposed to be front left, this doesn’t automatically mean starting bed mesh calibration at any other position/corner is supposed to be impossible. The code for the probe points even works when setting the “bottom right” as mesh_min, it’s just the error message that’s preventing this use case.

Anyway, I was just asking why the error message was implemented during development, to prevent me from creating a pull request that breaks other peoples use cases I might have overlooked :person_shrugging:.

8

I’m just cleaning up here and not a developer by trade :man_shrugging:
Maybe @Arksine could shed some light into this

9

Thanks for your time and effort :+1:

1 Like
10

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.