Sorry i think some things got mixed up here as we got sidetracked with the move checking in general (such as the case of bed_mesh actually needing a negative position_min in case points on the bed is lower than homed z=0). Apologize the lengthy reply here, but i feel like the point of this thread has been misunderstood.
I’ll clear it up:
- i do not want to bypass limit checking in general, nor do i think that’s a good idea in any sense of the imagination.
- I want to avoid requiring the user edit his config to add potentially dangerous limits (apropos your example of ripping off endstops - for Z that is probably the least expensive disaster i can think of) to simply run PROBE_CALIBRATE. All probes will trigger before the nozzle (obviously), so i will in all situations have to go into negative
z to calibrate my probe. This is the extent of this proposition. Nothing more, everything else should function the same. Sorry the discussion got sidetracked.
Your proposed changes would result in PROBE_CALIBRATE ignoring the error, but the toolhead still wont actually descend. So, PROBE_CALIBRATE wont report an error, it would just come up with completely bogus results. I can’t see any utility in that.
Obviously that’s not the behavior i was looking for, i can’t see any utility in that either. You’re of course right that move() would stop execution when the error is raised in klippy/toolhead.py#L458.
How about reusing verify_no_manual_probe to sidestep kin.check_move() errors where z is the offending axis (refer to my initial suggestion) generated in toolhead.move()?
I’m guessing what you actually want is to implement two sets of error limits - the “definitely don’t rip the endstop off my my printer” limit and a “regular printing moves should not travel to this position” limit. It’s certainly possible to implement that.
No that’s not what i want. The “definitely don’t rip the endstop off my printer” should be position_min, and that should be 0. Not -5. Not -0.3. 0. In case of Z there’s only one general situation where you want to go below actual zero (if we ignore that bed_mesh, z_thermal_adjust etc needs negative zero to work as well - another topic of discussion), and that’s when you don’t actually know where Z0 is yet, such as before you have calibrated your probe or your endstop. I know some printers allow moving the toolhead outside the plate and may have some utility in negative Z when in that position, but that’s the exception, not the rule. It would still be possible to do this with a negative position_min, however that seems more appropriately handled by a different mechanism, but we don’t have to discuss that here as that case i not affected.
Would you not agree that it’s in general not safe to have a negative position_min on Z? Toolheads costs several hundreds of dollars today, and many performance oriented printers have Z drives powerful enough to break expensive things, especially when we’re talking large volume printers. Just a flexplate for a 500mm printer costs over $100.
FWIW, I would not recommend enabling an additional check like that by default, and I suspect few users would enable it by choice.
I’m assuming you’re referring to disabling all kinematic checks in general, in which case i agree (also never suggested such a thing). If you’re referring to disabling kinematics check for Z specifically, and only during probe calibration, then i very much disagree, and would love to know how you came to that conclusion.
The issue is, users really hate getting an error message.
I guess, but that’s not at all the issue, that was never the concern. The issue is when you need to calibrate your probe when provisioning your printer, you need to edit your config and restart your machine twice (not counting SAVE_CONFIG), not only that, but it’s for non obvious reasons that you have to dig up in the bed leveling docs. It’s not only a poor user experience, it’s a significant risk if the user forgets to reset position_min to 0 (and they do forget, more than you know).
For what it is worth, we see a notable number of users willing to disable the “don’t burn my house down checks” because they don’t want to get an error - I’m pretty sure the “maybe I didn’t want to move there error” wont be popular.
This is continuing down i sidetrack i never intended or suggested.
Another approach to solving the high-level problem described here is with documentation.
Generally you don’t solve poor illogical user experiences by making the user read more documents. That’s the last resort. If you have to explain an interaction scenario, you’ve failed as a UX designer (i say that having had to explain multiple designs in the past, and will have to explain and fix multiple designs in the future, nothing is perfect).
in the past we’ve seen a number of users confused by the max_temp safety check - some users thought it was the “maximum temperature that it is normal to print at” and then complained when the printer shutdown due to minor temperature overshoot. We’ve had to explain that max_temp is instead “the maximum temperature that could ever be possibly valid, and beyond which is obviously incorrect and indicates that something has gone drastically wrong”.
Not comparable. Again i’m not talking about the error, i’m talking about all the hoops you have to jump through to calibrate a probe and not set yourself up for disaster.
Similarly, the min_position is not the “minimum position that one would normal command the printer to” and is instead “the minimum position that indicates something has obviously gone wrong and we don’t ever want to move to because it will damage the printer”
I mean you just said it right there. By that logic, why are we telling users to set their [stepper_z] position_min to a negative value to run PROBE_CALIBRATE?
As such, for example, after configuring it for PROBE_CALIBRATE you do not reconfigure it - as it is a statement about the extreme limits of the printer hardware and it is not a statement about normal printing positions.
If i need to set it to -5 to calibrate my probe and end up with a z_offset of 5 in my config, then running G28 and G0 Z-5 will break my hotend. No? [probe] reports z_offset as position_endstop, that means when it triggers, the nozzle makes contact at kinematic Z0. I can still move to Z-5, that breaks things.
