Log 8 and 9 were done without modifying smooth time and pwm cycle time.
As for log10, since I upgraded to 80w heater, which is quite an overkill for such a small hotend, standard 1 sec smooth time causes overshoot, temp varies about 5C, so I tuned down the smooth time step by step, and decreased pwm cycle time, managed to stabilize the temp.
I will try to reproduce the error and command m112.
Just checked PSU voltage, 24.37V with and without bed and hotend heating, very stable
I desperately tried my luck with a dangerous fork of klipper, and it didnât work either.
But fortunately, its log unveil another error prior âHeater extruder not heating at expected rateâ, which is âMCU âmcuâ shutdown: Timer too closeâ, though the system reports âHeater extruder not heating at expected rateâ anyway. Could this be the actual cause?
klippy (11).log (3.0 MB)
Timer too close is a totally different error and a different cause.
When seeking support here: Please use exclusively the latest git version from the official repository and if possible produce a log with a follwoing M112.
We do not offer any support for forks or modified versions, as they actually might be the reason for the issue.
OK, I understand.
Since the error occurs quite randomly, ususlly during long prints, I might not be able to issue M112 command instantly, which could even be hours later. Does the delay of M112 matter?
Yes, this only works if issued shortly after the unwanted behavior.
The root cause of the problem reported here is overloading of the Klipper host process. One can see this from a system graph of the log:
In effect, the Klipper host process couldnât process all the work it needed to do in sufficient time. This resulted in extended duration between heater checks to the point that when the heater check did eventually run it came up with surprising results. One can see this in the logs by the fact that the âStatsâ messages do not come once per second (there are gaps of several seconds between Stats messages which indicates that the internal Klipper host tasks got starved for multiple seconds at a time).
Itâs not entirely clear why the Klipper host process is so overloaded. If I had to guess Iâd say it is:
[gcode_arcs]
resolution = 0.05
These types of âextremeâ settings are likely to cause the âextreme resultsâ seen here.
-Kevin
Thanks!
I also suspected this could be the cause of âtimer too closeâ, so I changed it to 0.1.
Now the printer has been working continuously more than 12 hrs. Maybe I can get this job done finally!
I just checked log10, 9, 8, 7, and confirmed there are the same symptom of delayed stats messages. I think host overloading might be the cause.
I will also try to increase the priority of klipper thread, since I also host spoolman and vpn on the same SBC.
That would be great if it is working now!
Caused me sleepless nights alreadyâŚ
Iâll change the arcs settings on my printers as well now. 
Sorry for that. 
I turned off arc fitting entirely, since I still got 20GB+ storage avaliable.
Thanks @koconnor 
Again a learning experience.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.