How to prevent Klipper from disconnecting upon every single little error? - Klipper's absent error handling...

[Simon2.4]

This is becoming very frustrating. Every error puts Klipper in limbo, requiring a reset and reconnect. Surely there has to be a way to modify the behavior on faults. This is quickly piling up to hour and hours of wasted time since every reset lets the bed cool down, bakes plastic in the hotend, etc etc

Here's a typical failure loop related to this:

1 - garbage Chinesium inductive probe is only good before it warms up so you want quad gantry leveling to happen fast before the hotend warms up the head too much.

2 - bed heats up slowly due to its mass, hotend stays idle

3 - bed is hot but nothing happens for 15-20 seconds

4 - head heats up

5 - nothing happens for 15-20 seconds

6 - 1st homing and QGL starts

7 - gantry was a bit too racked so QGL fails

8 - Control board goes in limbo, cuts communications, stops heating and 1 out of 5 times goes in hard fault necessitating a power cycle and reboot of the whole machine (+- 3min) and back to step 1 with a warm probe now!   or

9 - reconnect, send 'firmware_restart' command, wait for board reboot, start print and go back to step 1 with a warm probe now!

 

Sincerely, this is bad programming... at step 7 above, firmware should go into a 'soft fault' mode, KEEPS COMS OPEN, send message: "Check gantry racking and restart print", all while keeping the elements hot! This would have saved me hours of my life already..   I don't get it! This is one of many examples of poor error handling by Klipper; or should I say 'Absent error handling' by Klipper.

I'm still new at this and I have searched ways to address this but I need help to find a solution, if one even exists.

Anyone else?

[rjorgenson]

You could change your start macro to probe before any heating starts. Will probably extend the total start time, but at least in your above failure scenario the bed/hotend will still be cool for your probing. Still pretty new to klipper so I got nothing on why you might be running into those problems, just a possible workaround, sorry =/

[Simon2.4]

Are you telling me your Klipper does not disconnect on faults?

does not require a firmware_restart after a fault?

yes I'm looking into refining my Start-Print routine; still any mistake I make is exacerbated by the behavior described above. Klipper's error handling is the issue here. Why does is need to disconnect and fault its self into limbo every time there is any issue. I'm hoping it's something I did wrong..

Edited February 6, 2022 by Simon2.4

[rjorgenson]

1 hour ago, rjorgenson said:

Still pretty new to klipper so I got nothing on why you might be running into those problems, just a possible workaround, sorry =/

I have not had that specific issue on Klipper, no. But I've only used it for a few months and not on anything as complex as a v2.4 (Sidewinder X1 w/BLTouch and dual independent Z). I do remember running into an issue early on where I had to restart the printer to get everything working again, but that was because of a config setting. It was long enough ago that I don't remember the exact circumstances of the failure, but I remember it being when I tried change config and restart klipper, not when running into any issues while printing. This is the issue I ran into https://github.com/Klipper3d/klipper/blob/master/docs/FAQ.md#when-i-set-restart_methodcommand-my-avr-device-just-hangs-on-a-restart

 

[Simon2.4]

1 hour ago, rjorgenson said:

You could change your start macro to probe before any heating starts. Will probably extend the total start time, but at least in your above failure scenario the bed/hotend will still be cool for your probing. Still pretty new to klipper so I got nothing on why you might be running into those problems, just a possible workaround, sorry =/

 

Added this to my cura machine profile start gcode: It does save some time and prevent cooking in case of bad QGL

M140 S{material_bed_temperature}      ;set bed temperature and dont wait
print_start                           ;run printer's start_print macro (QGL and home)
M109 S{material_print_temperature}    ;set hotend temprature abd WAIT for it to be ready
G28                                   ;cause lase homing was done with cold tip

 

 

Edited February 6, 2022 by Simon2.4

[hannibal.lector]

I really wish the Voron team would ditch the python2 based klipper... I want to 3D print, not maintain a linux distro.

[Simon2.4]

Wow, I forgot this thread..  I turns out it was all octoprint causing these issues. Klipper was just obeying bad commands.

Octoprint is good for many uses but is not the best for Klipper. Mainsail is way better as it was built for it.