Question Both heaters hit set point and then stop heating

[cat40]

Printer Model

V2.4 more or less R2

Extruder Type

Clockwork 2

Cooling Type

Stealthburner

I have a bit of a strange issue here. Both the bed and the hotend will heat up and reach their set points at the start of a print, and the gantry goes through the quad mesh level with klicky, and then begins the print. About halfway through the second layer the print stops and the printer shuts down with the expected error that the hotend is not heating at the expected rate. I haven't actually seen the moment the print ends visibly. From the klipper logs you can see the set point remains correct and the PWM duty cycle maxes out as you would expect when the temperature is dropping. It appears both the bed and the hotend reach the setpoint and hold successfully for a few minutes, and then both turn off at the same time. I would tend to suspect the 24V supply is thermally shutting down or something, especially since the position the gantry ends up in looks like it was extruding until the moment it died, but in that case, I would expect the control board (octupus, connected to pi 3 over USB) to also shut down because it is also powered of 24V. The pi is powered off of a mains to 5VDC converter so it should not be affected at all by the 24V supply shutting down.

Things I have ruled out:

• loose connections. I hand tested all of the relevant ones and re-mated the extruder heater with the terminal blocks on the Octopus.
• Random quirk. This is a repeatable error.
• Bed heater issue. I tested this by heating the bed to 60C and leaving it on for an hour, and it held temperature the whole time.
• Intermittent wiring issue (I think). Since this error is repeatable, and wiring issues would generally cause problems at random, I don't think this could be the cause. Also, the temperature data remains stable so the thermistors are obviously connected properly.

Events that happened shortly before the error / possible contributory factors:

• A while ago, I hard shorted the 24V supply be being careless soldering wires for caselights. I heard a crack and everything turned off, but nothing was damaged so I think the OC protection in the 24V supply did its job properly and caught the short before damage occurred. I got several successful prints (in the sense the temperature worked fine, at least) afterwards.
• Major print failure where the bottom of a box popped of the print bed and got stuck on the hotend, managed to push the back panel off (magnetic mounted) and I found it jammed in a corner with the motors skipping steps. This led to the hotend reassembly detailed below
• Immediately before, I reassembled the hotend (Dragon SF) from scratch, replacing the heat block and heat break. This was the result of a massive PLA leak that I suspect was due to a defect, and the cleanup of which resulted in me breaking the heat break. I have had this issue ever since then.

Printer specs:

• "stock" v2.4 configuration, more or less r2. Stealthburner with CW2
• Separate 24VDC and 5VDC power supplies, both powered directly from mains
• North America standard 120VRMS nominal split phase mains power.
• Octopus control board and Raspberry Pi 3, running mainsail os.
• 24V stepper motors and drivers

 

[ah2049]

Your bed shutting off at the same time as the hotend is likely due to the failure of the hotend heater tripping a Klipper shutdown, which would turn off all heaters.

You've tested the bed heater at temp, but have you tested the hotend at temp for a decent amount of time? Curious to know if it hits and holds temp at a stable PWM if it's just sitting around, versus not being able to keep up while plastic is dragging heat out of it.

I assume you have already, but run a PID tune on that hotend heater if you haven't. Due to the scale, it's hard to see what PWM is being utilized in those pictures.

Since you rebuilt it, make sure you didn't accidentally leave the clamp screw for the heater loose.


Anecdote:
I've had this issue with my 2.4 using a mosquito (after about 10 months of use), in which I ended up replacing the heater in the hotend. Putting the silicone sock back on it has also helped lower PWM a little bit as well.

 

[cat40]

Hm. I've not tested the hotend at temp because I don't like to bake those things but it's probably a good idea to try nontheless. The PWM on both hits 100% as the temp starts to drop so I guess you could call that stable. Naturally it bumps around a bit during heating but that's what you'd expect a control loop to do. I will run a PID tune on the heater, however, just looking at the graph it doesn't seem like the control loop is becoming unstable. I also have a sock on it.

Funnily enough, I initially cold tightened the clamp for both heater and thermistor, then went back and hot tightened them when this problem appeared.

I did notice the thermistor dropped out when I tightened the set screw too much so I suspect it may be faulty and worth replacing at some point, but since the temperature stays stable on the graph and doesn't have any discontinuities I don't think it's a thermistor problem. Even if it doesn't have enough samples to detect a dropout the microcontroller certainty would and would cut everything off, which has not happened obviously.

What makes you think the klipper shutdown is triggered right when the power shuts off? I'm not super familier with how klipper works near the hardware level, but since the PWM hits max duty cycle after the shutoff I'm inclined to think Klipper didn't shut down and was still actively trying to heat until it gave up and threw and error. This also would make sense because the data was still logged for quite a while after the heating ceased

As for the graphs, sorry about the poor quality. I used the built in python debug scripts to generate those and apparently it's configured to output quite low resolution. If I'm feeling adventerous and have the time I'll probably go back and at least configure it to have better colors that don't blend into the background.

Probably what I'll do next when I have time is run a hotend PID tune at 260 and then start the print again and watch it to see when it fails and get a better idea of what happened. I'll post the results here if the tune doesn't fix it.

 

[ah2049]

I can understand the fear of baking, but I have yet to have any issues with any of my printers heatsoaking with the hotend and bed at printing temps (245c and 95c, respectively).

I'd want to PID tune that heater in the conditions it will be used in. You might see issues when printing something with higher fan speeds than what you've tuned at before (think PLA with 100% part fan speed and the doors open, vs. ABS/ASA with no fan and the doors closed).

If the hotened keeps its temperature during PID tuning and testing, you could try jogging the toolhead around to see if temps start dropping at a certain position. If you're using the stock wire bundle and drag chains, a broken heater wire might be okay initially, but have issues once moving around.

If the thermistor started acting funny, I'd just replace it. I'd also replace the heater while I was at it. I'd hate to jump through a bunch of hoops to discovery some weird failure mode of one or both of them.

The Klipper shutdown is due to "not heating at expected rate" like you mentioned. Meaning Klipper has continued to give a heater more power, but the heater isn't responding fast enough/as expected. Once that failsafe is tripped, Klipper throws that error and shuts down, turning off all heaters and turning all fans to max to cool the printer and minimize damage.

I can just barely see that it starts your PWM at 100% on intial heating, then drops and bounces as it keeps the temp close to what's requested, which is good. But you can then see where the temp started dropping after a bit and the added PWM wasn't enough to keep it at requested temp, causing the shutdown. Since the PWM stuff seems to be fine initially, I believe the chart PWM is wrong after the shutdown and is not actually calling for full power, otherwise you'd have a thermally runaway printer melting itself down. It's probably some sort of graphing interpretation quirk.


Sorry for writing a book and just throwing ideas out there. I hope the issue can be fixed and you can get back to printing!

 

[cat40]

I did another PID tune at 260 with full part cooling, which failed because the temperature wouldn't go over 249 (which is odd since it did that manually. I suspect the initial PID constants were unable to regulate properly or something). I then realized I did not in fact have a sock installed so I put it back on, at which point the tune succeeded. It's going good so far printing PLA at 200C so I'll update when the print finishes or fails. I've got a new thermistor/heater pair on order due to the weird thermistor behavior, though I may hold off on installing them unless the issue persists or reoccurs.

I still don't quite understand the logs, then, if the microcontroller was not reset until temperature hit ambient how would a thermal shutdown have been properly handled? The whole point of a thermal shutdown is to kill the whole system upon realization it is behaving in an unexpected way with high potential for damage. I've actually stated before I think in an ideal world thermal shutdown would cut mains entirely in case a mosfet failed short and is no longer controllable. That's just slightly challenging, logistically, since you'd have power sequncing issues on startup (obviously you'd want a coil relay that's NO so almost all failure modes are safe) and would probably require more user intervention than simply flipping the switch.

And no worries about the book. I am of the opinion that it is better to say too much than not enough, at least in the context of tech help over the internet. I have done quite similar things when helping others over the internet.

 

[cat40]

I am happy to report that after putting the sock on and running a PID tune I managed to complete a print (bit of warping but that's probably just because I didn't clean the bed very thoroughly). I'm not actually sure how useful the tune was, since it may have just been the pid loop becomming unstable since it was tuned originally with the sock on. Thank you for all your help.

 

[Billbr]

Sounds like you may have found your issue. For others who have this problem, it can also be the name of the parameters passed into the print_start macro. If your slicer automtically shoves heating commands in your gcode (eg Prusa Slicer) and you use temperatures in your print start macro that don't match your slicer spec, your printer will exhibit the a very similar issue to the problem described. The macro can't get the value and assigns 0 to the temps. So the slicer auto heat gcode makes it heat-up and then executes the print_start. When the temperature gets set in the macro, it sets it to 0 i.e off. To fix, just verify the names of the parameters match between the slicer and the print_start macro...