Current Klipper logic for max X and Y doesn't seem to make sense and it prevents only the less damaging type of crash

[tinkerman]

Basic Information:

Printer Model: Custom
MCU / Printerboard: Octopus Pro 1.1
Host / SBC: OrangePi 5
[N/A] klippy.log

Describe your issue:

I am sorry @Sineos, I did read your homing theory article and I am not criticizing it, but the concept behind it. Your explanation was very clear. But I really don’t think the rationale behind the current homing theory makes sense because all it does is prevent the tool head from crashing into the frame, which can be loud, but in my experience does not result in serious consequences.

On the other hand, what it allows very easily is a crash of the toolhead/nozzle into the bed. And this is quite bad because I lost already 3 TMC2209 drivers during these events. And the latest one was more catastrophic because when replacing the driver, I inserted it incorrectly and lost my manta m8p board.

The last part is on me and my stupidity, but it could have been easily avoided if the homing and coordinate system could validate that probe actually has a bed underneath it. With current logic of having endstop limited within min, max, there is no way to tell klipper that anything is out of bounds of the bed or that you’re trying to print something on top of nothing.

Let me explain what I mean (I also like using Excalidraw, so will use that). And, by the way, I have not considered different kinematics and their flavors. The case below is about Cartesian with moving gantry and static bed.

The situation below is slightly exaggerated than the actual setup to make it easier to explain and hopefully understand. As is, consider homing X. where the endstop is, and close to the max position:

min_pos < endstop_pos ≤ max_pos

There is nothing to provent this crash, klipper doesn’t know there is no bed underneath and (apparently) there is no way to tell it.

It doesn’t make sense to me that endstop position cannot be used to indicate a gap and that it cannot exceed max position. To me it almost make the parameter redundant. It doesn’t make sense to me that the endstop position can be less than the max. Then it is not really an endstop is it?

Now, if the max position actually represent valid print moves, then the endstop will indicate where are both the origin and the end of the bed, which to me makes a lot more sense. If endstop is over the inside of the print bed, then endstop position and max position would be the same and it would also prevent both frame and nozzle crashes.

Here is how it would look:

min_pos < max_pos <= endstop_pos

I haven’t put a lot of thought if this would create problems in other types of setup, but intuitively I can’t see why it would.

Klipper has a style of trying to bring over what would usually be done in the slicer and relying on the slicer for this one seems to go in the opposite direction. And I don’t think it is a good idea to define the bed area there (at least, not only).

Would be interested on what you guys think and would be happy to hear about any blindspots this approach would have. Right now, I think it is not as good as it could be.

[Sineos]

@tinkerman

I am sorry @Sineos, I did read your homing theory article and I am not criticizing it, but the concept behind it.

I do not take it as critics. On the contrary, I’m happy that someone is actually reading it and I’m also happy about any form of input / critics / corrections.
In the end, I’m not writing these KB articles for myself but as a guide / aid for the users of Klipper.

@tinkerman

Now, if the max position actually represent valid print moves, then the endstop will indicate where are both the origin and the end of the bed, which to me makes a lot more sense. If endstop is over the inside of the print bed, then endstop position and max position would be the same and it would also prevent both frame and nozzle crashes.

So, if I understood correctly, your input boils down to: Do not home the Z axis, if the probe position is outside of the bed.

While I agree that this would be an useful sanity check, I have no idea what this would mean code wise. As far as my understanding goes:

• Klipper today has no notion about the bed size
• Klipper today only knows its kinematic limits (endstop positions and min/max limits only refer to the kinematic limits and define the bed’s origin relative to these limits)
• Additional settings, e.g. bed size or “gap” sizes would be needed along with the respective logic in the code

FWIW, an overhaul of the Klipper homing code is tentatively planned. Of course the final due date and potential scope is open and subject to change.

[EddyMI3D]

@tinkerman

If endstop is over the inside of the print bed, then endstop position and max position would be the same and it would also prevent both frame and nozzle crashes.

This does not work e.g. with IDEX printers, where the not used printhead has to be out of the way. On my T-Rex 3, the x-endstop is at -45.

[dockterj]

I’m not following - are you referring to Z endstops or a bed probe? Does your printer not have an actual z endstop?

Also consider printing a large vase - if your extruder can move outside of the envelope of the bed there is no reason that the vase can’t overhang the bed as well.

[tinkerman]

@Sineos

So, if I understood correctly, your input boils down to: Do not home the Z axis, if the probe position is outside of the bed.

Yes, basically. But I also think it conceptually makes more sense than the endstop being before the max. I can’t think of a way that an endstop comes before the max coordinate of the nozzle.

@Sineos

I have no idea what this would mean code wise

That’s quite simple actually. It’s less about code but more about coordinate calculation.

In klipper we configure the probe offset. Example:

offset X = 20
offset Y = -6

Then before Z Homing:
X = 220
Y = 150

probe pos X = X + X offset = 240
probe pos Y = Y + Y offset = 144

Pseudo code:

If (probe_pos_x > max_x || probe_pos_y > max_y || probe_pos_x < min_x || probe_pos_y > min_y) {
// Probe out of bounds
}

@dockterj

I’m not following - are you referring to Z endstops or a bed probe? Does your printer not have an actual z endstop?

My Z endstop is an inductive probe. The main topic here though are the X and Y endstop setup and how it could be used to prevent Z Homing when the probe is outside of bounds.

@EddyMI3D

This does not work e.g. with IDEX printers, where the not used printhead has to be out of the way. On my T-Rex 3, the x-endstop is at -45.

I don’t understand what this means and again, it doesn’t make sense to me that an endstop would be inside the max and min positions.

As with endstop being at - 45 is exactly what I am talking about. Look at my diagram. If I was to home towards min_x, then my x_endstop would be negative and “less” than min_x. Today it’s not possible to set it like that in klipper.

[EddyMI3D]

@tinkerman

it could be used to prevent Z Homing when the probe is outside of bounds.

What is about?

https://www.klipper3d.org/Config_Reference.html#safe_z_home

[dockterj]

exactly, or additionally Configuration reference - Klipper documentation (klipper3d.org)

[dockterj]

@tinkerman

As with endstop being at - 45 is exactly what I am talking about. Look at my diagram. If I was to home towards min_x, then my x_endstop would be negative and “less” than min_x. Today it’s not possible to set it like that in klipper.

If you want the printable area of the bed to be from 0 to some positive number then you can set the kinematic range (position_min and position_max) to be from -45 to 255 and set the position_endstop to -45 or 255 depending on which end it is on. It’s completely arbitrary and no matter what you do you have to set up your slicer to know the coordinate and size of the bed (unless you have a delta with the center being 0,0 which actually makes a lot of sense but that is a diffferent story). I’ve chosen to leave my kinematic min and max as 0 to 300 and because my bed doesn’t reach all the way on both ends I have a set_gcode_offset to make 0 be just inside the edge of the bed.

I think the x,y question is separate from the lack of a kinematic endstop for z - but as EddyMI3D responded safe_z_home should be the solution for that.

[Sineos]

The idea to prevent moves when the probe is outside the bed has some merits.

Depending on the geometry and settings, it can happen that you probe outside the bed during bed-meshing. This can indeed lead to ugly crashes. In the end it is a faulty config but catching it beforehand would be beneficial.

As to the other points, I do not have the knowledge to assess the implications.

Moved the post to the FR category.

[tinkerman]

@EddyMI3D

What is about?

https://www.klipper3d.org/Config_Reference.html#safe_z_home

If that prevented the issue I wouldn’t be here. Thanks for the feedback.

@dockterj

exactly, or additionally Configuration reference - Klipper documentation (klipper3d.org)

I wasn’t aware of this configuration, thanks. But there is nothing special about my Z homing. In fact, @Sineos noted something that I failed to specifically notice, I believe meshing is the main cause of my crashes.

@dockterj

It’s completely arbitrary and no matter what you do you have to set up your slicer to know the coordinate and size of the bed

I am not advocating against that, I merely presented an example. What I am talking about is a sanity check that would be possible when you can define the endstops arbitrarily as well (which I don’t see why not allow it).

I get what you’re saying about kinematic range, but the kinematic range for a printer is also meaningless if not to where you can move the nozzle towards. If you want to place your origin in the negative spectrum that’s your choice, and what I am proposing would allow that, or any other setup. In case of a delta, define -150 to 150 kinematic range and that would work fine too, and can also represent where the limits of the bed are (circle inside a square). It wouldn’t hurt and could also benefit from the same crash situation (with a bit more calculation).

As I mentioned previously safe_z_home does not prevent crashes as of today.

@Sineos

Depending on the geometry and settings, it can happen that you probe outside the bed during bed-meshing

I think you got it. Now that you mentioned it, if I go back to these crash events, I think they all happened when I was recreating meshes due to adjustments I made to the printer. This latest one, happened when I replaced my rail system to linear rails which affected the reachable range of my bed.

Sometimes I also make adjustments to maximize accuracy, which involve making small changes that affect my limits. As I have 3 independent Z lead screws this is quite a routine activity as I tinker around.

Anyway, thanks for having the insight and making this observation, that I hadn’t realized myself.

@Sineos

In the end it is a faulty config but catching it beforehand would be beneficial.

You’re right, and one that is easy to get wrong because it’s not immediately intuitive to project the usual nozzle coordinates to probe coordinates. It’s way too easy to make a mistake here. Either by forgetting that you need to set coordinates considering the probe offset or making a calculation mistake or measurement error.

And come to think of it, it would be a lot easier to simply define mesh margin with the information about where the bed ends.