Printer Model: Ender 3v2 w/SpritePro
MCU / Printerboard: 4.2.2 Creality, connected with UART to Orange PC Plus klippy.logKlipper Log Parser
Fill out above information andin all cases attach yourklippy.logfile (use zip to compress it, if too big). Pasting yourprinter.cfgis not needed Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there
Describe your issue:
Hello.
I think, one of wanted features in klipper - disabling that damn verify. Error “Heater extruder not heating at expected rate”
The error appears suddenly and is not related to the physical parameters of the printer. The firmware may simply not receive the data in time, for example, due to some processor load spikes. This will be enough for the klipper to stop printing. A lot of expensive material will be sent to the trash. Time and money wasted. And all because this setting cannot be disabled. If indeed the klipper honestly checked the temperature and shut down in case of serious problems, it would still be acceptable. But the Klipper can turn off printing simply because it “didn’t like something”. The wires, thermistor, heating unit and all other components are working perfectly fine. This algorithm is obviously not working well, but why can’t it just be turned off if I am sure that the equipment is in good working order? I’ve been struggling with the klipper for a week now to get it to stop stopping printing for obscure reasons. You can change thermistors and check wires until you’re gray hairs - it’s not them. It’s the klipper.
Unfortunately, your assessment or perception is completely wrong. With some years of experience in Klipper:
Most of the time, this error occurs, indeed an issue in the heater’s hardware is present → Search here and you will find just enough examples
Yes, also timing issues can lead to this, but
quite rarely, here you will find only one or two examples
also these cases are highly detrimental, since it will mess up Klipper rather sooner than later. Not receiving MCU updates for multiple seconds is not something that Klipper accepts
Depending on the nature it of the issue it can be a safety relevant issue
So the bottom line is quite simple: If you experience this error then something is not correct and needs to be fixed. A system that has properly functioning heating hardware and a clean timing between the MCU and the host just does not show this error.
When you wrote this, my printer stopped again. I’m one hundred percent sure the hardware is working fine. Because I have double-checked everything three times. Moreover, the problem only occurs a few hours after starting to print. And the logs show that there are no fluctuations in temperature, the graph is even, as if it was drawn on a ruler. I have done all the calibrations several times. In addition, the Marlin firmware worked without any problems, sometimes I printed for several days without interruption. Did the mere fact that I installed Klipper break my extruder? That’s not even funny.
All this talk about safety is good if the software is actually working properly. Not suddenly stopping printing just because who knows what it didn’t like. And I am a mature and responsible enough technician to be able to make my own decisions. I should have the ability to disable questionable verify algorithms that break printing process and log something unrelated to reality, don’t you think?
I’m telling you, there is a problem with Klipper, it suddenly stops printing with fully functioning hardware!!! Perhaps my Orange PC Plus is too weak for such serious firmware. I haven’t used anything else on the host though. There’s no webcam connected, for example. Only Klipper. Instead of one line in the configuration, tomorrow I will reinstall all the software from scratch, including Armbian. And try my luck again. And most likely, the result will be the same. And then I will look for a laptop to install Debian and Klipper on it. And I will buy a USB-TTL converter. And I’ll try again. And when it happens again, I’ll roll back to Marlin. Oh, right, safety first. Well, it turns out that Marlin is not as safe, but at least it PRINTS.
You can change whatever you want (the code is open and you have the ability to modify it), but if the existing controls for this behaviour (Configuration reference - Klipper documentation) aren’t sufficient then you have something very strange going on.
None of these parameters disable the check mechanism. And it fails for reasons unrelated to the thermistors. And it is not known why at all. So these parameters are useful only if the functionality works correctly.
I think changing the Klipper code is too much, it’s easier for me to go back to Marlin. For now, maybe someday the community will pay attention to this problem.
According to your log you haven’t even attempted changing any of the parameters in your config so your assertion that they don’t help seems unfounded. E.g. if you changed hysteresis to 200 it would only be possible for the mechanism to halt your printer if the temperature was more than 200 degrees away from your target for an extended period of time, which is basically the same as disabling it.
I sincerely appreciate you trying to help. All I’m saying is that the parameters only talk about temperature. But in my case Klipper stops despite normal temperature settings. That is, even if I set your recommended parameter to 1000 degrees, Klipper still stops. Probably because I didn’t get the temperature information in time due to a brief CPU lag on the host. I don’t know why. The error message is misleading and you can’t disable the check. I can try your advice, I have a lot of free plastic. Just a reminder that the problem occurs after a few hours of printing.
Yes, those log lines point to something other than heating problems going on; sysload spikes to 9.94 right before the shutdown, which is abnormally high and is probably the core issue that you’re facing (which will not be resolved by disabling this check, you’ll just have your print fail in a different way.)
This is why @Sineos suggested finding and addressing the underlying issue, rather than blaming a useful check and disabling it.
Did you try it, or are you just guessing what would happen? I haven’t tried it (and wouldn’t be able to easily replicate your situation), but I would be very surprised if that was the case.
Your host got severely delayed. So the error message in fact is just a symptom of the underlying problem and it makes no sense to tune around on the “symptoms settings”.
Not sure what the cause is. You may try:
Reflash your board
Do a make distclean to start with default settings
Triple check your parameters for make menuconfig, especially WRT to MCU type and clock settings
Check your host OS if it is running extra stuff although from the log it does not seem so
If you should be using OPi provided OS, check if switching to Armbian makes a difference
