I hate to wait, I really do. So I want my homing speed to NOT BE dramatically SLOWER than the axis max travel speed. But of course the problem with running with too fast a homing speed is that the endstop/probe WILL NOT trigger in time to stop the stepper in time and then CRASH!
A simple change to solve that problem would be to have a “NEAR” endstop. If the NEAR endstop is triggered, the homing speed reverts down to the slower homing speed, from the faster max axis travel speed. Simple/cheap to implement. Would make homing all axis’s much quicker.
Example if the X axis has a simple levered endstop switch - Place a maybe proximity sensor or an optical sensor that will trigger and stay triggered, when the toolhead in within 10 mm to 0 mm from the zero position. Once that “near” endstop is triggered, the homing speed would revert to the much slower homing speed.
I don’t know how long your prints take and how large your printer is, but I think to rewrite the complete homing routines in Klipper for just a few seconds of waiting is quite disproportionate.
Also, if you put the printhead near the X/Y coordinates of the homing position can save you some seconds too.
You are forgetting about the Z. Not easy to move the Z axis. Plus I think your estimate of the effort involved for this change is quite exaggerated.
This mod is especially useful for those of us who ware frequently making tweaks/mods to their printers. My END_PRINT routine turns off the steppers, the heaters, and also raising the Z a good bit. Doing “the next try of something” involves fully homing all axis’s, and then waiting for temps to come back up. That is more than a few seconds.
If that is not you, don’t be a buzzkill for those of us that would find it useful.
Hardware complexity + additional points of failure
Documentation efforts
Support efforts
in the highly complex and sensitive homing area, just to shave off some seconds appears to be very poor “value for money”.
It also appears that it can easily worked around by changing the work flow. On my test printer, neither the cancel or the ending macros would turn off the bed heater or steppers.
I have already started doing that. The code is not that complicated to modify for this change. Kevin did a great job of structuring it. My experience is end-users or novice developers either wildly exaggerate the effort way to the upside, or minimize the effort, due to their lack of understanding of what actually happens under the hood…
You could even add a whole chain of endstops on the way to the final endstop and create a function to scale the speed as they pass the endstop “markers” to maximize your travel speed.
Furthest Endstop
Closer Endstop
A little closer Endstop
Half way endstop
Getting there Endstop
Near Endstop
Really close Endstop
Actual Endstop
Back again to put in my 2c. I’m a fan of the 8mm prox sensor for z home and bed mesh. The speed problem, since it takes several minutes, perhaps 10 to do an 81 point bed mesh, It strikes me that quite a bit of the slow, is because the prox switch is only running at a 1 klilohertz speed, requiring the slow approach, that and the recent lack of prox switches that can function on 5 volts, most now need 12 to 24, but that blows the opto’s BTT uses to isolate the probe inputs.
So I’ve developed a circuit using a schotkey diode to restrict the max input to the BTT board to 5.1 volts. It strikes me the prox sw makers need to supply us with switches that work on 5 volts, and work at a higher oscillator frequency for faster, but still accurate response.
You could buy them that worked on 5 volts 3 or 4 years ago. I have some of the older 5 volt switches that work fine as index pulse generators at 400 rpm, much faster than the current crop. We are a big enough market, but I’ve not a clue how to get thru to TPTB making prox switches for us to make them aware we need them.
Is there someone here who has an established comm channel to the makers to encourage the return to dependable 5 volt operation? At 10 to 20 kilohertz for faster detection?
Actually, I’m not sure how this relates to the original topic here.
Homing speeds, approach settings, lifting distance etc can set with the relevant options
Note: Kevin’s goal is to redo the homing code for 2024. So the FUD thrown out about changes/maintenance, docs, etc. is really mute.
“just to shave off some seconds”
It’s not a “few seconds”.
“It also appears that it can easily worked around by changing the work flow. On my test printer, neither the cancel or the ending macros would turn off the bed heater or steppers.”
I run all mains powered bed heaters (750-1000 watts), having to remember to turn those off manually is an absolute no go. And having to jerk around with changing start/end macros depending on what each print is also a no go.
I “FUD” that this is quite subjective to your personal workflow and may not reflect a broader user base.
We will see if and when such a topic will be considered in the revision of the homing topic as announced in the Goals.
But that is also switching the problem back to us, when the real problem is how fast the switch can switch, if we want real accuracy, we must not move anywhere near as fast as z can be moved. Double the approach speed lose half the accuracy. At some point we may as well make a heat proof touch pin to relay from touching the bed to a std mini-micro sw mounted higher for cooler. I think that is what a klicky is?
Asking the prox sw makers for a faster 5 volt switch seems like the sensible thing to.
I have another Q about bed tilt, and methods, where is the proper place to ask? Or is that covered in an .md file? I have a somewhat unusual config for an ender5+ reducing the Z motor count to one.
Sorry, @gene1934 but this is completely off-topic to the items discussed here. If you need clarification, then open a new topic.
On a side-note, nobody prevents you from supplying your proximity switch with whatever voltage you desire. This is a pure hardware question and not related to Klipper. Again, open a new topic if you need clarification.
As theophile said, Just home while heating the bed up.
I’m not quite sure I see where the issue is here?
You’re going to be spending a lot more time waiting for the bed to heat up than you are waiting for homing?
I have a 750 watt heater on my bed and I home when it’s heating up with no issues.
Homing takes 5 seconds or less, bed heating usually takes 30 sec to a few minutes depending on the size of your bed and the bed temp.
Also, you can change your print end macro to be dependant on what you want to do. As in, you can set a variable in Klipper gcode macros to tell the printer “If this value is 1, don’t turn off the heaters after the print is done, just set them to this minimum power, if it’s 0 then turn off all heaters.”
That’ll save you a lot more time than homing ever will.
Edit: Klipper also turns off the heaters/stepper motors after a set amount of time anyways.
Could be any of these reasons: I do not want to leave a mains powered bed heating, on a printer that does not have a flexible/removable build plate, the bed has to cool before that part can break free, I don’t want my extruder hot and oozing, …
Plus having to jerk around with settings (leave heaters on) is a no go, because if I am in testing/tweaking mode, it’s not until after the print that I know if another, quick turnaround try is needed - “gee, I should have set something…”
You do understand that if this feature goes in, no one will come to your house and force you to use it, yes?
If Klipper is used to control a mill, router, laser, pen, food squirter, etc., then heating the bed and hotend heatup time go away, and the big start up time is homing the axis’s. So adding a feature to increase homing speed by 3x,4x,5x is to me, a big plus.
You understand Klipper is programmed by volunteers in their free time and thus usually only work on changes that benefit a large majority of users, not one off things for a single user?
You said multiple times up top that it’s “Easy to implement”, If so, fork the repository and implement the change and submit a PR.
Be 100% sure you don’t break any existing functionality and your changes work for every combination of configurations as well.
Even then there is no guarantee it will get added to the mainline code cause you can imagine what would happen to the codebase if every possible edge case was programmed in. It would be unmaintainable. So you’ll need to get others to test it and agree that
A.) It works without fault
and
B.) It enhances Klipper overall and they’ll use the functionality in a meaningful way for a lot of users