When I send a command G1 X2222 it moves printer head to the max X position and writes the message “Move out of range” and it is ok.
But when I send a command G1 X222222 it moves printer head to the max X position after that it throws the error “Timer too close” and shutting down the printer. During that python process klippy is loading CPU up to 100%.
In case of Y axis there is no this error.
I’ve truncated it for your comfortable reading. Before that error it just printing Stats.
I have 200x200 printing area but accidentally found this error.
klippy.log (1.0 MB)
Full log from turning on of the printer to the error attached.
Of course in real life this error will not occur as printing head will never be sent to 222222 position. But i have no this error with Y axis. And as it looks like cpu overloading who can predict under what circumstances the error may appear.
Clarification: This error occurs only if bed mesh loaded. Otherwise printer head is not moving and throws the error “Move out of range”.
In case of Y axis for example if i send g1 y222222222 it loads cpu and do nothing for a long time but the error “Timer too close” doesn’t occur.
Looks like check of coordinates correctness in case of loaded mesh follows after z correction calculation. As this topic has no answers there is no error and everything is ok.
I think if error exists it should be fixed. This error on this printer is really often. I can’t tell what causes it but it is often.
You might be right, but how often are people going to try to move their printer head to unrealistically high coordinates? At worst it just rams the printer head into one of the axis.
This is a community driven project so takes people to debug on personal time, In this situation I think the easiest solution is simply “Don’t do that”.
Yes, you are right. Nobody will send print head to coordinates which doesn’t exist except me. I am uniqum.
But the main logic is broken.
When bed mesh is not loaded print head will not go to this coordinates with error “Move out of range”
But when bed mesh loaded it will go. Who can predict how this can affect.
I am just a singer who is singing what he observe.
Can you pls point me to files in klipper code where I can try to remove this behaviour.
BTW: opensource is a great thing because people are working with highest motivation ever. This motivation is interest. All replies in this topic looks like you are tired of this motivation
Not tired of the open source, It’s just there is plenty to work on outside of edge cases on a situation that someone is having on one printer.
If this is a problem on EVERY printer or a lot of printers and repeatable then that’s a different story.
It’s like that old story of the guy who goes to the doctor and says “Doctor, It hurts if I poke here.” and the Doctor replies “Well, Don’t poke there”.
If I INTENTIONALLY try to do things outside of the normal operation of my printer, I bet I will find all kinds of things that break. The idea is that people WON’T try to do things outside of the normal operation of their printer.
You simply CANNOT program around ALL possible fault scenarios because your codebase will be huge, you’ll spend your entire life doing that, and even when you think you’re done someone WILL find another way to break things.
I asked a guy to check and his printer head is not moving but when he sent x2222222 klipper process load cpu to 100% and throw the error “Move out of range” after some time. And this time increased by higher X coordinate.
I understood why Timer too close is thrown. When i send X2222222 the klipper loads CPU to 100%. But head is moving and klipper logic decide that system is overloaded. When i send this command to printer and its head is already located in X200 “Timer too close” is not thrown because no needs to move head it is already there.
So this error with CPU overload is reproducible. Axis moving can be platform specific issue for example.
Clarification:
When bed is at highest Y200 then if i send x222 it moves to X50
If bed is in Y100 then X is not moving and throw the error Move out of range.
When Y is in 0 then if X222 X is moving to 185 sometimes 190 and throw the error (move out of range).
First three strings when bed mesh is not loaded. Other strings when it is loaded. Toolhead is moving by segments which was calculated with probe_count values.
Maybe my configuration is bad? But as i can see the logic is differ when bed_mesh loaded and it should be reproduced on other cartesian printers.
As I can see on the last screen amount of segments is calculated based on bed curvature. When Y100 in this area difference between probes is about 0.05 mm
-0.387500, -0.377500, -0.367500, -0.355000, -0.347500, -0.335000
In this case two segments is enough
But when Y0 difference is bigger.
-0.045000, -0.107500, -0.152500, -0.195000, -0.247500, -0.305000
in this case we need more segments.
If ones have aligned bed than it can be only one segment and error will not reproduce because Move out of range throws without movement.
This config came from producer of the printer. And I checked it as accurately as I can.
Do you mean homing_retract_dist should be configured to zero only for X axis but not for Y?
But how it can lead to the described error?
Can you please answer on my previous post. Timer too close after moving to X out of range - #16 by Lebensgefahr
I can’t understand. I asked about homing_retract_dist. Is it should be in configuration for stepper x and stepper y? As i can read configuration guide yes it is. Printer has two sensorless axis X and Y.
At the time I understood that printer was made with many errors in OS, some errors in configurations I completely reinstall OS, check everything in the printer config especially including all options about sensorless homing.
Of course i can make a mistake, but at this moment i can’t find it.
I wrote this guide for other kp3s pro v2 users:
Look at the first string. I wrote all points equal so there is no needs to interpolate points for Y0. And now tool head is not moving at all.
This is the proof that this error occurs only if bed is not straight.
And now it is obvious that there is no such error which can cause this behavior. This is the error in klipper code. There is no checks of the target coordinate before it starts interpolation.
About Doctor story. There is a lot of vulnerabilities in software. We can just ask attackers do not use it. This error causes firmware to stop working properly until it will be restarted.
