Better management of ERCF errors in START_PRINT

[Surion79]

Current (develop) behavior is for me not acceptable. If the filament is not loaded, i don't want the printer erroring out hard that even ercf requires an ercf_unlock to make the errored state of the printer void, meaning that i need to do all initial G28, QGL, Bedmesh, 2 soak timers go through AGAIN. Thats at least half an hour wasted for a 10 second problem. ☹️

[Benoitone]

I find it much safer to cause this error... in fact it almost never happens to have an ercf error at startup. But, it has already happened to me to forget to correctly place the initial filament in the ercf, and without putting such security, the pause occurs just after the primeline, and the hot hotend remains in the same place and made me a hole in the pei. Indeed, I was near the printer, but with an [idle_timeout] timeout: 1800 (so 30min) it has time to do a little damage. It's true that with the Park in the Pause it shouldn't happen... And, once everything is hot it doesn't take more than 5 minutes to redo the first parts of the start print. (I do bed mesh at the end, just before primeline.)

[Surion79]

When the exception throws the print away, you need to start from the beginning. You can't resume. the start print procedure of Klippain ist not designed for this kind of partial run of start_print based on previous aborted start. I don't know how to reconfigure klippain without firmware restart to do a conditional QGL... oh, there is none (yet). Even ERCF is in an 'anormal' state as it is locked outside a print. Funny message from ERCF to resume print after you fixed the issue when you do an ercf_unlock 🤪

This kind of error-nonhandling can raise issues in Klippain and ercf, since the command ercf_unlock does not work as expected/documented. And if you start print without ever using ercf_unlock you get another fail, since the ercf is still in locked state. It's really not a good solution currently.

[Frix-x]

I understand the problem and will put that on hold for now until v4 is released.

IMHO, one solution for later would be to integrate some kind of "RESUME_START_PRINT" macro to allow to start again from the failed module and then continue the sequence from there without starting again from the begining. It's not an easy task to implement and I don't want to explode everything again for now. Let's focus on polishing the current state for v4 :)

[Surion79]

I'll close this issue based on the soon integration of the new HHv2