Heaters Stay on after "Move exceeds maximum extrusion" with hotend melting the part.

[bung69]

Hi, Just had my printer stop due to a "Move exceeds maximum extrusion" error. - my fault as I forgot to change the nozzle size in the config. no problem there.

However the printer just stopped without disabling heaters. is that expected behaviour? I assume / hope the heaters will eventually time out?

Thanks

Matt

[klipper-gitissuebot]

Hi @bung69,

It did not look like there was a Klipper log file attached to this ticket. The log file has been engineered to answer common questions the Klipper developers have about the software and its environment (software version, hardware type, configuration, event timing, and hundreds of other questions).

Unfortunately, too many people have opened tickets without providing the log. That consumes developer time; time that would be better spent enhancing the software. If this ticket references an event that has occurred while running the software then the Klipper log must be attached to this ticket. Otherwise, this ticket will be automatically closed in a few days.

For information on obtaining the Klipper log file see: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

The log can still be attached to this ticket - just add a comment and attach the log to that comment.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[bung69]

KlipperLog- move exceeds maximum extrusion.txt

[github-actions]

Hello,

It looks like there hasn't been any recent updates on this
Klipper github issue. If you created this issue and no
longer consider it open, then please login to github and
close the issue. Otherwise, if there is no further activity
on this thread then it will be automatically closed in a few
days.

Best regards,

~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[jman1o1]

Just experienced the exact same scenario. Seems like a major safety issue.

[monoxide13]

Just experienced the exact same scenario. Seems like a major safety issue.

Same

[github-actions]

Hello,

It looks like there hasn't been any recent updates on this
Klipper github issue. If you created this issue and no
longer consider it open, then please login to github and
close the issue. Otherwise, if there is no further activity
on this thread then it will be automatically closed in a few
days.

Best regards,

~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[KevinOConnor]

Responding to an error like this is typically handled by OctoPrint. However, I agree Klipper could do a better job now that many users are using moonraker and mainsail/fluidd. Adding a better default behaviour is something we will look at adding.

-Kevin

[damaddin]

+1 for me, had the same issue using fluidd. I would expect Klipper to be failsafe and switch the extruder off after some time - i didnt check that.

I wanted to add, the problem "Move exceeds maximum extrusion" was caused by my SuperSlicer Profile, derived from an Ender3 Profile, that somehow had custom G-Code added:

M83 ; extruder relative mode

but then generated absolute coordinates. Changing this to M82 and also removing G92 E0 on the layer change custom G-Code fixed the issue.

[dudeofawesome]

+1 from me too. Just had it destroy a build platform due to leaving the heater and bed on with the nozzle oozing PETG onto the bed. Definitely should fail-safe with the heaters turning off in this event.

Edit: using Moonraker + Fluidd

[vladbabii]

Just had the same issue and managed to destroy a pei sheet. Could we have an option to run some gcode on errors that stop the print, with an error code as a parameter? This way we can handle any possible issues in the best way for that printer

[Sineos]

Could we have an option to run some gcode on errors that stop the print, with an error code as a parameter? This way we can handle any possible issues in the best way for that printer

I second such a flexible approach. There is one instance, where I really would like to have the (bed)heater staying turned on:
With one of my printers I'm using
SCREWS_TILT_CALCULATE MAX_DEVIATION=0.02
which tends to error out if the heat bed is not fully heat-soaked (or if I had to force off the last print from the bed). Here it would be really annoying if the heater gets turned off.

[hamster65]

It would be usefull to me to switch off a wifi plug when there is an error with the heaters or sensors. Should be possible with this idea.... Right now it switches off for any error, such as "movement out of range". Very annoying, because it cuts all power, including the raspberry.

[bwittig]

The heaters also stay on after a TMC error (GSTAT 0...1) - A similar solution would be good for that too.
(Still chasing the error - probably a bad connection on the motor?)

[bernhardberger]

Responding to an error like this is typically handled by OctoPrint. However, I agree Klipper could do a better job now that many users are using moonraker and mainsail/fluidd. Adding a better default behaviour is something we will look at adding.

-Kevin

Is it possible to have klipper itself handle security features? I find it a bit "dangerous" that it has to be handled by the frontend on a separate hardware that can fail for numerous reasons.

Imho it should cut all power on the board where klipper mcu code itself runs in the case of a hardware failure :/

[lmamakos]

A thing that I've done is to use the klipper Idle Timeout macro to turn off the heaters and otherwise "safe" the printer. Of course, this means that it'd be great if there were no errors in that macro, and if the rest of klipper crashed, then this macro likely doesn't get run, either.

In my case, I turn off the hotend and bed heaters the usual way by setting their temperature to zero. And I also have relays in series with those heaters connected to GPIO pins on the Raspberry Pi that also use to "arm" and "disarm" the hot bits. So even with a shorted MOSFET, I can interrupt power to the heaters. Or a crashed firmware, since the relays are connected to GPIO pins on the Raspberry Pi, while the MOSFET devices are driven from the MCU.

A more robust solution might be to have some sort of watchdog timer implemented in the klipper firmware, associated with the GPIO pin that's driving a heater. And some periodic command from the klipper host to reset it, otherwise the firmware would take some action (set PWM to zero, or whatever.)

[pedrolamas]

The bare minimum I would expect is for something like this to call CANCEL_PRINT - or at least give me an option to make it so!

Best case scenario, I would propose a new ERROR_HANDLER macro would run and inside of it we would check what the error was and handle however we want to (most likely, call CANCEL_PRINT)

[pedrolamas]

With #5491 now merged, we now have a way to mitigate the above issue, by adding the following to the virtual_sdcard section:

[virtual_sdcard]
; other stuff here...
on_error_gcode:
  CANCEL_PRINT

This will be enough to make sure that a "Move exceeds maximum extrusion" error cancels the print and turns all heaters off!

[OzzieOrca]

I experienced this with SuperSlicer due to this Monster Gap Fill issue supermerill/SuperSlicer#2214.

I'll try adding that on error hook, thanks :)

[kjkent]

Just commenting here after reading #5430 (comment) which links to this thread.

@Sineos — is this the same underlying issue? It seems that this issue keeps the heaters at their specified target, i.e. not reducing the targets to zero, whereas the linked issue had their HE temp almost double to > 450°C after an apparent Klipper error.

Also, you mention in the linked issue that GitHub is not the place for support questions, but does a Klipper error leading to thermal runaway not qualify as a significant development concern?

Aside from obvious user error, one would think that Klipper should fail safe rather than forcing the heaters on an in uncontrolled manner. Just voicing my concern that this potential serious safety issue seems overlooked.

[kjkent]

@KevinOConnor apologies for tagging you directly, I was just looking over my old commented issues that remain open, and #5430 has stuck in the back of my mind since reading it earlier this year -- it seems @jdanders had a thermal runaway but the issue was closed as being not development-related, which I posit was an erroneous move. I understand this is a separate issue, but @Sineos linked this issue in marking it 'not-for-github'. The linked issue, however, had the hotend continue to increase in temp rather than remain at its target.

Thank you for your time/consideration.

[jdanders]

Hi @kjkent, to provide more context, the full diagnosis was done here on discourse: https://klipper.discourse.group/t/how-do-i-figure-out-why-mcu-was-disconnected/2634

The final conclusion was that the MCU overheated. I don't know MCU code well enough to know what's possible in that situation, but there are some comments about watchdog and scheduler code gaps. Once I hardwired the MCU cooling fan to "always on" the problem has not happened again.

Thanks for raising the issue again -- if an improvement can be made that prevents this it could save someone's house! 🔥

[kjkent]

@jdanders thank you for this -- I really appreciate it! I'm currently learning embedded C but I don't know enough either to add any value to the discussion, but I'll definitely look through it, thank you.

PS - Absolutely no disrespect intended to @Sineos or anyone else in my bringing this up. Just erring on the side of caution.

[KevinOConnor]

FYI, the functionality to disable heaters (or take other actions) on an error in virtual_sdcard was added in PR #5491.

-Kevin

[github-actions]

Hello,

It looks like there hasn't been any recent updates on this
Klipper github issue. If you created this issue and no
longer consider it open, then please login to github and
close the issue. Otherwise, if there is no further activity
on this thread then it will be automatically closed in a few
days.

Best regards,

~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[jdanders]

@KevinOConnor do you see PR #5491 as a solution to this thermal runaway case? This was fixed by making sure the MCU cooling fan is always on, so I assume it's a case of losing the MCU entirely when it overheated. My earlier comment has all the details.

The error in virtual_sdcard feature wouldn't work on that case, right? If not, is there any solution possible for this sort of error?

Edit: Oops, I just realized this isn't my issue thread, #5430. Sorry, I got the emails and assumed it was on my issue.

[github-actions]

Hello,

It looks like there hasn't been any recent updates on this
Klipper github issue. If you created this issue and no
longer consider it open, then please login to github and
close the issue. Otherwise, if there is no further activity
on this thread then it will be automatically closed in a few
days.

Best regards,

~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.