My printer takes forever to cancel a print: 9 times out of 10 I give up and hit the emergency stop: it's much quicker, even though that involves a load of extra faff.
Is this normal, or some quirk of my printer setup?
1 Like
How long is forever?
Do you have any waits at the end of the gcode added by the slicer? For example on mine when the print finishes it sets the LEDs to Blue, and waits while the heated bed gets to 45C then switches the LEDs to green. And only then will Octoprint show the operation as finished, and allow you to print something else. (If I know I am printing lots of stuff quickly back to back I just remove code from gcode)
I have heard of people with similar issues, not sure if they ever raised them as issues, but they were getting around it by putting breaks in their gcode..
Well there is that well known tale about the sparrow sharpening his beak on a mountain...
Perhaps not that long, but too long. I think it may vary, depending on factors that I cannot begin to guess at.
I suppose I could try some experiments...
No, I don't think so...
For example in end script
M190 R45 - tells printer to wait till bed temp gets to r45
M140 S0 ; turns off bed straight away
Often used with LEDs, or using part fan to cool bed etc.
1 Like
If it's a blocking temperature issue you could enable the option EMERGENCY_PARSER in marlin and it will actually kill the temp on cancel from octoprint even if it hasn't been reached.
Which log(s) would you like?
Because you raised in general rather than get help you did not get the template.
These messages are all over the place:
| Recv: // Heater extruder not heating at expected rate
| Recv: // See the 'verify_heater' section in config/example-extras.cfg
| Recv: // for the parameters that control this check.
| Recv: //
| Recv: // Once the underlying issue is corrected, use the
| Recv: // "FIRMWARE_RESTART" command to reset the firmware, reload the
| Recv: // config, and restart the host software.
| Recv: // Printer is shutdown
| Recv: !! Heater extruder not heating at expected rate
| Recv: // Heater heater_bed not heating at expected rate
| Recv: // See the 'verify_heater' section in config/example-extras.cfg
| Recv: // for the parameters that control this check.
| Recv: //
| Recv: // Once the underlying issue is corrected, use the
| Recv: // "FIRMWARE_RESTART" command to reset the firmware, reload the
| Recv: // config, and restart the host software.
| Recv: // Printer is shutdown
| Recv: !! Heater heater_bed not heating at expected rate
This is printer related. You may check the cables and connectors. Maybe the power supply is insufficient. Please also share the serial.log. (this maybe has to be enabled)
And BTW: What printer are you using?
Nah, they're all in the file. 
Quite possibly, but this is not the problem that I came here with.
As you say, this has to be enabled... I'll maybe get back to you with that.
It's an Anet A8 chassis with a TriGorilla board.
Quite possibly, but this is not the problem that I came here with.
It might be though - if your printer is waiting for a temperature change, it'll be stuck in a single line of gcode. When you press "pause" or "stop" in Octoprint, it just stops sending any further gcode to the printer. If the printer is still executing the last few lines sent, then that could take a while if one of those steps is to wait for something that's taking longer than expected.
Honestly, if you've got a power supply issue, it's probably the cause of a world of issues that you may have been ignoring up to now. A power supply issue makes you somewhat unique. Your issue is somewhat unique. Taking away your uniqueness in one area may well not fix it in another, but we can't know for sure until you've done it.
Why would it be waiting for a temperature change?
Obviously, it might be, if that was the stage of the print that it is at, but it isn't usually, and it certainly wasn't on the occasion that it took five minutes.
If it can force through an emergency stop, then why can't it force through a cancellation?
@Hairyloon, we wouldn't have to bicker about what the printer is or isn't doing if you would take the time to reproduce the problem with the serial.log enabled and then upload it.
What the printer is doing a the end of a print job is determined by the end code added by the slicer. Since you haven't bothered to tell us which slicer you are using we can't even guess what that might be and we shouldn't have to. Provide us with a copy of the end code from the slicer. Alternatively, provide us with a copy of the gcode for a small part that exhibits the problem.
The more details you provide, the better help we can give you.
Depends on your firmware, it's capabilities, and buffer. For example there is the EMERGENCY_PARSER in Marlin that if that is enabled (disabled by default) it can break through waiting for temperatures, etc.
If it was getting to the end of the print job, then I wouldn't be cancelling it would I?
If it was hanging on the last few commands of the Gcode this could be determined from the serial log and the GCODE. Without it is guess work.
There are definitely gcode commands that will cause the behaviour you are seeing. But it could be something completely different.
I mentioned above I have command I put in that cause it to wait, this also effects cancel but emergency stop will work.
It's hardly an argument to dismiss a suggestion that is self evident nonsense.
Thank you for your contribution and my sincere apologies for bruising your ego.