Deleting STL while printing leaves printer in unknown state #1694

CarnufexG opened this Issue Jan 7, 2017 · 7 comments


None yet

5 participants


When deleting(accidently) an STL while it is printing, the printer stops printing but leaves it in an uninitialized state; bed heater and hot end(s) ON. Perhaps, the "cancel print" functions should be run rather than just quiting and leaving everything in an unknown state.


Hi @CarnufexG,

It looks like there is some information missing from your bug report that will be needed in order to solve the problem. Read the Contribution Guidelines which will provide you with a template to fill out here so that your bug report is ready to be investigated (I promise I'll go away then too!).

If you did not intend to report a bug but wanted to request a feature or brain storm about some kind of development, please take special note of the title format to use as described in the Contribution Guidelines.

Please do not abuse the bug tracker as a support forum - if you have a question or otherwise need some kind of help or support refer to the Mailinglist or the G+ Community instead of here.

Also make sure you are at the right place - this is the bug tracker of the official version of OctoPrint, not the Raspberry Pi image OctoPi nor any unbundled third party OctoPrint plugins or unofficial versions. Make sure too that you have read through the Frequently Asked Questions and searched the existing tickets for your problem - try multiple search terms please.

I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next two weeks (until 2017-01-21 22:40 UTC) I'll close this ticket so it doesn't clutter the bug tracker. This is nothing personal, so please just be considerate and help the maintainers solve this problem quickly by following the guidelines linked above. Remember, the less time the devs have to spend running after information on tickets, the more time they have to actually solve problems and add awesome new features. Thank you!

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being, so don't expect any replies from me :) Your ticket is read by humans too, I'm just not one of them.


Do you really mean a *.stl file? I think this will happen if you delete a *.gco or *.gcode file while printing it.
But anyways. How do you delete a gcode file while printing it? This option is disabled in the Octoprint UI while printing.

@CarnufexG CarnufexG changed the title from [BUG?] Deleting STL while printing leaves printer in unknown state to [REQUEST] Deleting STL while printing leaves printer in unknown state Jan 8, 2017
CarnufexG commented Jan 8, 2017 edited

Yes, I meant gcode file. And yes, I accidentally hit the trashcan icon and my print stopped. It looked like it thought it was printing. I tried to resume and refresh the UI but I ended up having to restart the print from the beginning. Version 1.3.0 (master branch). I might have been near the end of the print (buffer printing out) but I have a stop and cancel script and neither of them ran. It just stopped.


That shouldn't happen at all...
Can you please try to reproduce this and upload the log files.
Hopefully we get some more info on this.
But this sounds like a very specific race condition, you normally shouldn't be able to remove the file you're printing, can you also please specify where this file was located, e.g. root, folder, folder in folder, maybe a full path.

And also this is not a [REQUEST] but a [BUG?], so don't change the title just to make the bot happy!

foosel commented Jan 9, 2017

Fully filled out ticket template please. Also include JS console output. As @Salandora said, marking this as a request instead of providing the information for a bug report asked from you is a sure way to not get the issue resolved.

@foosel foosel changed the title from [REQUEST] Deleting STL while printing leaves printer in unknown state to Deleting STL while printing leaves printer in unknown state Jan 9, 2017
@foosel foosel removed the type:request label Jan 9, 2017
CarnufexG commented Jan 9, 2017 edited
foosel commented Jan 11, 2017

Could it be that the file was in a folder and you deleted that by any chance? Because I just fixed a bug in d83440d that allowed this to happen due to the file-in-folder-detection having an issue and not getting the full data it needed to work properly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment