Move hotend on thermal shutdown

[thinkyhead]

It has been suggested that on a thermal shutdown it would make sense to move the print head up and away from any print in-progress. I'm not sure how this would be handled when the machine is idle. Also, when remote-printing there's no explicit flag that a print job is in progress, so we might just have to infer that from the position of the hotend.

Thoughts?

[Wurstnase]

I've thought a bit today how to implement the filrunout without sd-card printing.

I think we could make a general mcode: Mxx1 print started Mxx2 print finished

So we could handle the filrunout-part and also a head moving for the thermal shutdown.

[AnHardt]

I could imagine a sequence like:

• disable all heaters,
• (cancel the buffer for the moves),
• lift the nozzle to ZMAX,
• send the messages to the display and serial,
• wait and refresh the display for some seconds,
• switch of the motors off (regardless how far z has come - it's some seconds away from the part)
• shut down the power
• shut down the interrupts,
• disable all heaters an other time for paranoia
• and finally loop until reset.

Emptying the buffer and sending to ZMAX would be the new parts in kill(). Everything else is already there. Emptying the buffer seems to be critical, else we can not guarantee the nozzle to be away from the part when we stop, or we had to wait for a long long time.

Maybe we should lift the nozzle only ~2cm to 1'' when unhomed, or not at all.

[thinkyhead]

Before lifting the nozzle to Z max, perhaps it would help to retract the E axis by 1mm or 2mm to prevent a large blob and string.

Also, ZMAX might be bad if G92 or some other auto-adjustment has changed the current Z. Maybe ZMAX minus 5mm would be a safer destination, or just lift Z by 10mm with ZMAX as the top limit.

[foosel]

Are we only talking about movement on thermal emergencies? Or generally also on external emergency shutdown or other unrecoverable errors? Because while the idea in general does make sense, I'd be wary of introducing "intelligent acting" into an unknown system situation. Blindly moving the head could cause more problems (maybe shaking loose something or running into something else). I'm envisioning something like a fallen out but still hot heater cartridge which through the emergency shutdown and consequent move gets dragged off the somewhat safe print bed and dangles still hot against something way less safe than that...

[thinkyhead]

only talking about movement on thermal emergencies?

Yes. Or potentially any situation where the firmware calls kill() requiring a reset to continue.

I'd be wary of introducing "intelligent acting" into an unknown system situation

It is good to be cautious. Once the axes have been homed, they are considered to be in a known state, and ordinarily the printer is considered ready to receive movement instructions. A thermal shutdown situation can occur with the axes in a known state or in an unknown state. If they are in a known state, then the machine should be ok to process G1 commands, and so movement within bounds is still supported. We can't do much if the stepper motors lose power, of course. In situations where a thermistor falls out, power is lost to the heater, or power shorts to the heater, as long as the position is known it should be as safe as any other time to attempt a movement before going into the dead loop. It makes sense to only move the axes that are "known" however.

…dangles still hot against something…

I'm not sure we can account for every situation, like all the places a dangling heater cartridge could do extra damage. But for extra insurance we could add a configuration option for the XY position or square region where the head should move in an emergency situation.

But perhaps it is enough just to raise the Z axis.

[foosel]

Voting for having it a configuration option all together. I can't help it, I have a bad feeling about this. Knowing your position is only a tiny part of the deal here. We don't have any external sensor data but temperature information, so even if we know the print head position and the temperatures it is still a completely unknown situation in the grand scheme of things.

You are right that we can't cover every possible scenario, and that is exactly the point I'm making here. Any emergency occurring is a hint that something is off/not as expected. Trying to still act in a sane fashion in that kind of unknown situation is hard, given Marlin's very limited knowledge about the physical world. Yes, in 99% of cases it will help the user, what worries me are the other 1% where it might cause even more problems.

[Lukelectro]

Please don't have the printer move on an emergency stop!

If I get my fingers stuck in some moving part of the printer I prefer the emergency stop to actually stop all movement (And heaters) like I expect it to do! Sure, some PLA printer part will "probably" break before my fingers do, and Sure I shouldn't be poking around moving parts in the first place. I know from experience.

I once lifted my printer of the floor while it was homing. That's a stupid thing to do, don't ever try it. I have a top homing Mendel90. My hand got stuck. Not crushed or broken, and no PLA broke either, because I pressed the endstop with my other hand just in time (it took a few extra seconds because first reflex is to pull the stuck hand out, and that didn't work. Waving/flailing it around wildly to ease the pain also didn't work because it had a rather heavy 3d printer attached to it that was still dutifully attempting to reach it's Home position.). Had painful fingernails for a couple of days. Not blue fortunately. Later mounted a killswitch to the printer (One of those though big red ones that are meant to be used for emergency stops).

(The idea was to move the printer during the homing procedure, to save some time. That turned out to be a bad idea...)

On a thermal stop, maybe moving the printhead up can prevent some damage to the print in progress. Maybe. But then that would need to be a separate routine from the emergency stop. Don't have it moving after an emergency stop. That's unexpected and unsafe, imho.

[boelle]

yeah, i think this is a bad one.... emergency means emergency.... like dangerous machinery... when you hit emergency stop its means STOP

[thinkyhead]

Sorry, the title was misleading. This would only apply to a thermal problem, and only during an active printing session.

So, what do we think about providing a single menu option that's still available while in the "dead loop" allowing users to retract to a safe zone and recover (or resume the print), rather than force a reboot?

[foosel]

and only during an active printing session.

How will you detect that? When the host is streaming data there is no way I am aware of for the firmware to know whether that data belongs to manual control or a streamed gcode file.

"Press button to home and reset" on the controller after an emergency makes sense. Print resuming will only be possible however in all cases if there's some way for the host to get signaled (eg // action:recover). Since for a streamed file the host has absolutely no knowledge which was the last command that the firmware executed before the emergency (thanks to the planner buffer) it can't pick up properly anyway however, so it's probably a moot point in any case and will only lead to users expecting magical things that won't work most of the time. Which will cause "bug" reports in both Marlin's and OctoPrint's tracker I fear ;)

[thinkyhead]

How will you detect that?

That is the question! We've come across a few instances where it seems like it might be good for the firmware to know that it's receiving a sequence of code rather than just a single command. Of course, the proposal is to add a new G-code that would indicate the beginning and end of a "code block" or "job." It's not the kind of thing we'd want to depend on, but it's a "hint" that might be useful for instances like this.

Print resuming … some way for the host to get signaled…

Yes, in fact it might even be useful now, so that if the printer fails for some reason it can tell the host the last line it processed and the reason for failure. Currently it signals failure but it doesn't say what line it last successfully processed. (Well, ADVANCED_OK provides that, I suppose…) With that information the host could manage the resume / recover and continue, if it has that feature. The firmware would only have the option to resume if it was SD printing, of course. But, as you say…

…[it] will only lead to users expecting magical things that won't work most of the time…

And that is also my worry. Especially as I've developed more appreciation for the simple "obedient robot" approach to Marlin – that it should be able to do lots of very simple things, but when it comes to complex ones it should take a back seat to hosts. Things like firmware retraction, resuming/recovering, automated filament change, etc., are just at the edge, and bed leveling is about as "autonomously active" as I think Marlin should get.

[foosel]

add a new G-code that would indicate the beginning and end of a "code block" or "job."

Are the regular status polls during a print (eg temperature) part of that? what about pausing a print. etc... Could lead to even more definition problems for minimal gain, because...

it doesn't say what line it last successfully processed. (Well, ADVANCED_OK provides that, I suppose…)

No. If that happens to be enabled (which if I remember correctly it isn't by default) it still doesn't allow the host to know which command was last executed, only which was last acknowledged. The planner buffer makes things complicated here. In order to correctly handle a resume, the host has to know exactly what happened last and where the head is. It can't track that just from acknowledgements, that would require to replicate the internal buffer handling on the host side and thus would drag presumed knowledge about firmware intervals to places where they don't belong. Yes, the host could just pick up after the last acknowledged command, but that would not be clean, produce artefacts add only work if the prior moves were short infill ones, not if it was something critical like a perimeter where then stuff could end up missing.

Also, no way to handle this at all when no advanced ok responses are there and also having to distinguish here makes processing even more complicated on the host side. Remember, hosts don't have to just talk with marlin, but with multiple versions of that and of multiple firmware alternatives too, which at the current point can't even be distinguished from each other, not even with M115.

However, we are now discussing things that are way beyond the scope of the original question I think, shouldn't we first concentrate on this? Also since you agree that too much "intelligence" and/or autonomy is just going to create expectations that neither firmware not host will be able to meet...

[Wackerbarth]

@boelle -- Transfer to MarlinDev is in order

[thinkyhead]

Yes, this definitely opens a can of vermicelli. We'll have to ruminate on this more and revisit the topic after the upcoming release.

[ruggb]

Great idea.... but My ZMAX is a looonnnggg way off. It seems like a relative move 10mm or so would entirely sufficient.

[jbrazio]

Thank you for your interest making Marlin better. You should re-open this topic on MarlinFirmware/MarlinDev for proper followup from the development team. We suggest you to use the MarlinFirmware/Marlin#<topic id> markdown to link back to this original topic.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.