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.