Need help with "verify_heater extruder"

Basic Information:

Printer Model: voron trident
klippy logs.zip (4.7 MB)
MCU / Printerboard: btt manta8p 2.0
Host: orangepi CM4 debian 11
PSU: Meanwell UHP500 24v
umbilical setup with toolhead pcb

my printer is sealed with some insulate foam, chamber temp usually gets up to 65C.
I’m using this type hotend:
Amazon.com: Haldis 3D Upgraded Rapid Heat V6 Hotend 24V 48W Ceramic Heating Core Bimetal Heatbreak Copper Titanium Compatible with 1.75mm Filament 3D Printer (Hotend Kit) : Industrial & Scientific
I have done pid calibration. The hotend with full power is capable to get up to 360C.

The printer worked normally, until during a 14 hrs print, it shutdown midway with the warning of “Heater extruder not heating at expected rate”. I found the hotend fan blowing on the heatblock causing it struggle to keep temp up, so I sealed the leakage, and thought it’s done. Then I try to reprint, twice, both failed with the same reason. But I dont see any temp problem in the log for the later two case.

Wasted 800g ASA, really scratching my head for the cause, any help wanted!

Interesting that your extruder has a single 1-star review from three months ago that mentions this specific issue. The reviewer hypothesizes that the heater is simply too weak. Try slowing your print down and see if that helps.

1 Like

Thanks for your reply! I just see that review, wish I saw it before buying :rofl:


My flow is 12 mm^3, but the load graph seems to be ok?

The resolution in the graph does not allow judging it.
Noteworthy is the area around 21:00 where you suddenly have high PWM values. “Something” happened here forcing Klipper to push more power into it.

yep, thats part cooling fan kick in.

Just before error reported, the last log is:
“Stats 83328.1: gcodein=0 mcu: mcu_awake=0.003 mcu_task_avg=0.000004 mcu_task_stddev=0.000006 bytes_write=53181435 bytes_read=16488108 bytes_retransmit=9 bytes_invalid=0 send_seq=1493610 receive_seq=1493609 retransmit_seq=2 srtt=0.000 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=399992911 opi: mcu_awake=0.000 mcu_task_avg=0.000006 mcu_task_stddev=0.000007 bytes_write=117954 bytes_read=365939 bytes_retransmit=0 bytes_invalid=0 send_seq=19626 receive_seq=19626 retransmit_seq=0 srtt=0.000 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=49999744 adj=50000402 sd_pos=8151016 z_thermal_adjust: temp=32.8 heater_bed: target=105 temp=104.9 pwm=0.000 sysload=0.55 cputime=3422.269 memavail=3541256 print_time=19542.576 buffer_time=1.864 print_stall=0 extruder: target=265 temp=264.5 pwm=0.759”
Is the log interval longer than the heater verify period? So it didn’t record the temp drop.

From klippy(7).log:

grafik

Klipper is not able to reach a stable temperature.
Some things you could try:

  1. Use a stronger heating cartridge. If you only have these 40W variants, you will not have much fun at these temperatures
  2. Insulate your hotend with a silicone sock
  3. Perform PID tuning at this temperature with fan on. Most likely in your current configuration Klipper will fail to perform the PID tuning as the disturbances are too large for the heaters power
  4. Possible but not recommended: desensitize the settings via verify_heater

hotend comes with a silicone sock.
I have done PID tuning with 100% fan at 15C room temp.
I already set verify_heater like this before log 9: :sweat_smile:
[verify_heater extruder]
max_error: 120
check_gain_time: 20
hysteresis: 5
heating_gain: 2
Should I try to increase hysteresis even more?

Rather than the heating power, the small thermal mass might be the cause of fluctuation, which makes PID control overshoot. I have seem someone discussing improve PID algorithm by utilizing trapezoidal rule on github before.

I do not understand what you mean with 15°C. You need to calibrate PID at your relevant target temperature, e.g.

PID_CALIBRATE HEATER=extruder TARGET=265

PID tuned with cool chamber.

I upgraded heating cartridge to 80w, recalibrated PID, reprint, and failed again.
klippy (10).zip (1.9 MB)
The temp drop is filament change.
printer.cfg (14.4 KB)

Sorry, no further idea. The recorded temps do not warrant this error IMO:

The big drop at the end is the error

From the log, the temp drop is after the error.
What a doom. :scream:

Unfortunately not, since this would be too easy :wink:
Your last recorded temperature is 270.5°C. The drop in the graph is an artifact due to the crash.

Have you checked the PSU?

You mean PSU overheat?

What ever. You read the thread? At last the solution?

@EddyMI3D I don’t think this is the cause. The hotend is quite good on target temperature and this is exactly what’s puzzling me:

grafik

These are the last recorded values before the error.

1 Like

@woodencliff can you try to reproduce the error and immediately after it issue the M112 command?
This will output additional debug information. Maybe it is good for nothing, maybe it helps. Absolutely possible that I’m dramatically missing something obvious, but currently I’m dumbfounded.

Your config shows non-standard values in the extruder section:

pwm_cycle_time: 0.01
smooth_time: 0.1

Where are those values from?
Maybe with this small smooth time there are some artefacts steadily increasing the max_error parameter of the verify_heater check.
See the description of smooth_time:

A time value (in seconds) over which temperature measurements will
be smoothed to reduce the impact of measurement noise.

Even the small pwm_cycle_time might cause some unnecessary peaks.

If you can reproduce the error quite easily stick to the defaults (comment out those two lines) and verify it after a restart.

1 Like

Excellent observation @LifeOfBrian
Personally, I would think that indeed such parameters could be the cause but IMO they would cause unstable temperature readings and in my view the readings are OK.

What do you think?

In any case: @woodencliff comment out both parameters to force their default values and try again please.

I bet on that horse…
If I’m not wrong the standard smooth time averages/smooths the temperature readings and hides unwanted peaks.
Like on Digital filters with averaging or reduced FFTs.
With this short time those peaks can come out of the dark and make trouble.
And doesn’t klippy.log logs the stats only every second maybe hiding stuff inbetween as well?