A change I would like to see implemented to in the homing code is a “near_endstop”. Especially when testing mods, doing very quick turnaround prints (first layer tests, extruder purging, bed adhesion, raft-part distance, etc.), cutting down the time to home all axis’s would really be helpful.
Proximity switches would work well, let’s say triggering when the axis is 5-10mm away from zero. No need to worry about endpoint to motor stop latencies. Precision of the switch used would not be important, could be mechanical or optical.
PSEUDO CODE:
IF NEAR_ENDSTOP DEFINED AND ALSO NEAR_ENDSTOP NOT TRIGGED THEN
Homing_move(near_endstop, max axis/rail speed)
ELSE
Homing_move(endstop, homing speed)
END IF
The 2nd home would always use the lower homing speed and normal endstop.
If Klipper is used to control a mill, router, laser, pen, food squirter, etc., then heating the bed and hotend heatup time go way, and so 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.
Filing one’s taxes can be very complicated. So how did the tax software folks solve this problem, enabling unsophisticated tax filers to file correct tax returns?
They do an up front interview in plain language, translating the answers given to specific tax forms and line number values/check boxes.
They do a final sanity check from the to check for missing or contradictory or not allowed entries/choices.
Just food for thought. Some of the best breakthroughs in field X came from outsiders in another field, because they did not have myopic tunnel vision - “This is the way we always do it or have done it” .
In context of complexity ‘Timer too close’ errors which very often popping out in forum
I would suggest to review and probably add additional goal for 2024 or 2025
MCU Communication channel aggregated statistics (Min/Max/Avg/Count) - it should aggregate all Stats for each MCU channel and dump it in log. It should have at least 2 slices (Last minute, Lash hour) and when slice timer is done - dump the stats to log and start over, if some Error did produce shutdown - both slices should be present in dump data.
This way log file would contain aggregated data on minute and hourly basis per each MCU channel.
This data can be quickly extracted and analyzed by user or support.
This kind of statistics is very useful when troubleshooting some issues.
Agreed. Users are idiots. And I’m counting myself among them. Sanity checks, readable explanations, and understanding that everyone is going to do something stupid occasionally really help prevent everything from going bad. Unfortunately, one thing even tax software has issues with is telling a user what went wrong and what to do to fix it.
Looking at the documentation for configuration checks, I’m curious about the sanity checking Clipper does? It also feels like many of these things can be automated. Like, determining if the temperature is increasing when the heater is on, or having some sanity checks to make sure the fan is not 10x the max RPM. When I worked on simulator feedback systems, the software there had safety factor configurations, where it expected the system to move in a certain way, and if the sensors did not match the expected values everything shut down.
Perhaps allowing merging/overwriting of configuration files, along with some base profiles already configured could also help.
I have some python code i have written with the help of chatgpt.
It will basically do what bambu labs printer does.
Through my analysis of watching it.
It looks to go fast it bursts.
So i assume those bursts will ha e different PA values.
The laser scans it, and will estimate what the pa will be based on when it can make straight lines with no blobs.
I recommend having a PA for slower moves and ones in-between the slowest to the highest. Ocra slicer has an advanced PA already so this could be a simple test print, with klipper giving you the values to input intoo the advanced section. I would like to see klipper handle it all instead of the slicer side being involved. PA is good at the speeds i test them at, but as soon as you have a over hang and it slows down due to an overhang it now doesnt have the same amount of pressure in the nozzle. I think bambu possibly could use multiple PA values. This would be good because if we have a set of PA values for diffrent speeds, clean prints will be in our future if i can achieve this.
Now that it’s 2025, maybe it’s time to take another look at those goals? It looks like most of these have at least been explored with topics here.
I can comment on this.
As of November 2024, Happy Hare (the software for pretty much every Klipper-based MMU) got a pretty big update to support Type-B MMU’s like the 3MS (my design), ERCF, Box Turtle, Night Owl, etc. It also has beta Mainsail/Fluidd integrations.
Thanks for the reminder. I agree it would be good to review the 2024 goals to see where we are now.
Support for MCU flashing from the graphical frontends
Alas, I did not make much progress was made on this topic. There was a prototype made a couple of years back and there has not been much progress since then. I still think it would be a very useful addition to Klipper.
A Klipper “plugin” system for external modules
There has been some discussion on this, and I did put together an early prototype ( New proposal for Klipper "extension" support ). Unfortunately, it still needs more work. It is still a goal of mine for 2025.
There has been quite a bit of progress here, including integration of load cell sensor support, and the mainline Klipper code can be used to actively monitor weight measurements. Work is actively in progress on full load cell probing support.
Rework of Klipper’s “homing” and “probing” code
Quite a bit of work was done on this in 2024 (and early 2025). The probe code was internally refactored and basic support for “eddy current probes” has been implemented. It is also now possible to home manual_stepper motors without an excessive delay.
The remaining topics on my 2024 goals list were things I planned to keep a “watch” on.
I have also observed quite a bit of work on “multi-material systems” in the last year - very interesting developments. Realistically though, I don’t see myself doing much direct development in this area. I’d be looking for other leaders in this space to reach out with proposals for merging into the main Klipper code base. Ideally proposals with a long-term plan for maintenance so users and developers rapidly know who to contact for issues and changes.
I also have some updated goals for 2025, however I’ll tackle that in a separate post.