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.