As far as I can see check of coordinate should be added in BedMesh class move method (or in build_move method). Somewhere here:
I have asked @koconnor. Here is his explanation:
This explains, why it only happens when there is “work” for the bed mesh system.
Side note:
I tried hard to reproduce the “Timer too close” on my printers under the above conditions. I could see a CPU increase on the host when the mesh was enable, but it was by far not enough to stall it.
Yeah it works exactly Koconnor described. I checked that.
To reproduce Timer too close you need have two things at the same time.
-
Bed should be be curved enough. You can manually curve your table by setting its mesh points from my previous posts. The goal is to split whole asxis travel for highest amount of segments. In my case it’s about 8.
If your bed is not curved it will be one big segment X0 - X200. -
X should be high enough. For example 222222.
I turned on logging for some methods and in case of high X it just prints the same values very quickly like infinite loop.
In methods which are calculating this segments there is no any check of the last coordinate at the first iteration as you can see in the screenshot of bed_mesh.py
While I agree with you that it is slightly unexpected behavior, the main goal is fulfilled: Klipper errors out before damage is done.
I’ll leave it up to you to decide, If it is worth now to invest much time in a scenario that does not seem to have a major real-world impact.
I’d guess that the “timer too close” is due to the same underlying mechanism - bed_mesh takes that absurdly large move and splits it into many many small segments. That takes cpu time.
My initial reaction is that the error handling ultimately did succeed in preventing damage to the machine, and otherwise, “it is best to not issue commands like that”.
Cheers,
-Kevin
1 Like
Is bed mesh working only for the first layer?
If bed mesh is working during all printing process cube become a parallelepiped if bed is curved. Without bed_mesh it will have only bottom layer curved.
There are these parameters in [bed_mesh]
#fade_start: 1.0
# The gcode z position in which to start phasing out z-adjustment
# when fade is enabled. Default is 1.0.
#fade_end: 0.0
# The gcode z position in which phasing out completes. When set to a
# value below fade_start, fade is disabled. It should be noted that
# fade may add unwanted scaling along the z-axis of a print. If a
# user wishes to enable fade, a value of 10.0 is recommended.
# Default is 0.0, which disables fade.
#fade_target:
# The z position in which fade should converge. When this value is
# set to a non-zero value it must be within the range of z-values in
# the mesh. Users that wish to converge to the z homing position
# should set this to 0. Default is the average z value of the mesh.
So it is not for all layers. Which would make no sense, because the model would be distorted.
Without bed_mesh, there is nothing curved with the exception of the squishing of the first layer. But not by moving the z-axes.
Sounds cool. Thanks a lot. Am I right it is disabled by default because fade_end is below fade_start?
The description specifically says it is disabled by default.
1 Like
Interesting thing. This error stopped to reproduce until new bed mesh was created.
But if I send printer head to max X position (g1 X200) before run G1 X222222 it still occurred.
But I can offer a solution. Can I make a PR with fix?
You have a solution for the “Timer too close” events?
Of course no. I have a solution to limit z_offset calculation in case it goes out of the mesh range.
1 Like
I’ve made PR and now it is at the discretion of the higher mind.
After this question I feel myself like an idiot. Or you are thinking I am an idiot.
I never assumed that.