It seems like this one pops up regularly on github and in the forum, and every time someone follows up saying “it’s your hardware” (wiring, heater block, etc) but in my case, with the AnyCubic Vyper, I am very much doubting this because:
A) I can print the exact same print using the Marlin firmware + Octoprint and none of the thermals look in any way odd - the temperature ramp looks good, the extruder is functioning properly, etc.
B) Even if I crank these values way over what you would think would mask the error even if it was a genuine HW problem, it has zero effect:
I am working with Klipper TOT from github and have MainsailOS + Octoprint plugin running on an RPI4. As I noted previously, if I flash the Marlin FW and swap to an SD card which hosts Octoprint instead, the exact same gcode file (a benchy of course) prints just fine on the same HW, and the HW is also brand new (everything is in good condition, nothing worn) so I’m leaning away from “it’s a HW problem” - I think it’s more likely that this is a SW problem, just one that triggers as an edge case on certain printers.
Any tips? My next step is going to be to go into the Klipper firmware and disable the check entirely just to see how this behaves.
Ahhh, thank you for the insight on the value of heating_gain - I totally misunderstood that value and did indeed make it worse. Even cranking that value down and the gain time up, respectively, didn’t prevent the problem from recurring. I have now removed the call to heater_fault() entirely and the printer is printing a bench properly. As the attached screenshot shows, I think I have found a different problem with klipper and this particular printer.
Observe that Klipper has stopped powering the extruder entirely. The temperature is stable with Marlin, so the heater and thermistor works, and the extruder also stays at a stable temperature when not active.
Based on that image, I would expect the print to eventually fail as the temperature drops below the minimum to maintain flow. The drop likely syncs with the fan turning on, so you need to figure that out. Simply eliminating the error won’t fix this issue, and it’s definitely not safe.
Yes, I set max_power to 0.8 as part of my experiments when this first started happening, so I can set it back to 1.0 but I think the real problem is somewhere in the klipper control path.
I am looking into the code a bit now to see if I can understand the temperature control loop, but right now as a way of binary-searching through the problem space I am using the same octoprint control path to the same HW again (this time with the mainsailOS image since octoprint runs just fine as a module) but this time with octoprint talking directly to the Marlin firmware rather than the /tmp/printer UNIX domain socket and it’s printing the benchy just fine, though I do notice that the PID control loop with Marlin runs about 3 degrees cool (but it is stable at 217C, whereas with Klipper firmware I hit 220C and then the temperature immediately started dropping until the print failed).
Your image showed Klipper heating at full power (limited to 80% in your case), and the hotend couldn’t maintain temperature. I don’t see anything you’ve posted that indicates any issues with Klipper. The temperature is maintained at 220 until an event occurs (likely your part cooling fan) and then the temperature begins dropping.
P.S. Thanks for your feedback and help so far - would you like me to file a PR against the klipper github project? I’ve reverted my change since all it did was trigger a different failure path. I would just be sad if this got closed again as a “your HW is bad” ticket (Reported error: Heater extruder not heating at expected rate · Issue #2132 · Klipper3d/klipper · GitHub) since I am hitting literally the same issue. About 40 seconds into benchy.gcode I get the error reported in this thread, whereas with Marlin it prints just fine. I would like to help make the klipper firmware better, but if it’s seen as “behaves correctly” then I guess Marlin is the only option on the AnyCubic Vyper model I have.
By all appearances this is strictly a hardware issue. The hotend can’t maintain temperature when the part cooling fan is on. You can either use Marlin, or better insulate the heater block.
It’s not clear to me what code you would want to change in a PR, but it would need to be very thoroughly tested before being considered for merging. Anything regarding heaters is a safety issue, and the current code is extremely well tested and in use on tens of thousands of printers.
Sorry, brainfart on my part - I meant to say “issue” not “PR”. Do you want me to open a github issue against this rather than discussing this in discourse?
As to why I would open an issue at all, I am still not convinced that this is the HW and this is why:
I have compared the temperature ramp and the ability for the printer to physically maintain temperature, with and without the part cooling fan on. I have also tried the 100% power setting on the extruder, and even when the part fan comes on at essentially the same point during the printing process, the temperature plummets under Klipper but maintains a stable (+/- 1%) temperature profile under Marlin. If the problem was physically with the HW, do you not suppose it would fail under Marlin as well with the part fan at 100%?
The AnyCubic Viper is a budget 3D printer (<$400) which is moderately popular but also not “hackable” like the Ender or Prusa printers. The entire print module is swapped as a unit, including the heat break, hot end and pressure-sensitive bed leveling probe. It is not meant to have individual components swapped and the entire assembly comes at the end of a ribbon cable. I also have a spare unit and I’m 99.9% sure that it will behave the same way since, as I said earlier, the entire unit is new.
I can certainly use Marlin on this printer. I have already proven that Marlin works fine on it. That will not, however, help make Klipper better / more applicable to a broad array of printers, which is why I am bothering to do this at all. The goal here is not to just have the printer work, I had that days ago before I tried Klipper. The goal is to improve Klipper by not just running away at the first sign of printer incompatibility.
A MOSFET (here Q1) is connected to a PWM capable pin of the microcontroller (here HE1_PWM)
When this PIN is toggled high, the MOSFET closes the circuit and full 12V or 24V are pushed through the heating cartridge
When the pin is low, the heating cartridge is simply off
Power control is achieved by quickly toggling the pin (PWM)
Duty cycle of the toggling is controlled typically by a PID algorithm
Your log:
Log line 569
Heating starts
PWM is at 1 (full power, MOSFET permanently closed)
Temperature rises
Log line 758 and following
Approaching the target temperature
PID kicks in and reduces PWM duty cycle to avoid overshoot
Log line 858 and following
Stable phase, PID / PWM keeps temperature within +/- 0.2°C
Log line 874 and following
Something happens, measured temperature is dropping
Klipper reacts and increases PWM back to 1 to counter the dropping temperature but system is not reacting
From the log, Klipper perfectly works as intended and does the right thing. Nevertheless the temperature keeps dropping until Klipper errors out. What could be the reason?
Klipper suddenly forgets how to turn a single pin high but claims it does (PWM has been set to 1) → Quite unlikely IMO
Temperature probe problem, e.g. broken wires etc. with the effect only manifesting at certain temperatures and / or movement → Could be but not my favorite. One typically would see a rather steep, sudden decrease in such cases
Cartridge or MOSFET has a problem, e.g. MOSFET getting stuck, broken wires, bad contact etc, also only manifesting with temperature and / or movement → My favorite
Thank you for the schematic and explanation of the MOSFET power controller. So, here’s the deal I’ll make you guys - I have a brand new hot-end/heat-break/probe assembly fresh from AnyCubic sitting in a box. Unless the problem is actually in the AnyCubic controller board itself, and I will check the connectors as part of swapping out the hot end unit, that will be one less potential strike against the HW. Give me a day or two - the Vyper is currently printing a long print with Marlin.
