Octoprint: 'Cancel Job' waiting for the bed heated.

[halxinate]

What were you doing?

Canceling the print using the dedicated button

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

What did you expect to happen?

print stopped to allow new print starting

What happened instead?

octoprint been waiting for the bed temperature to rise all the way to the target temp

Did the same happen when running OctoPrint in safe mode?

most likely

Version of OctoPrint

1.3.10

Operating System running OctoPrint

OctoPi

Printer model & used firmware incl. version

Rigidbot 1

Browser and version of browser, operating system running browser

Link to octoprint.log

Link to contents of terminal tab or serial.log

Link to contents of Javascript console in the browser

Screenshot(s)/video(s) showing the problem:

I have read the FAQ.

When clicking 'Cancel' at the very beginning of the print job it strays in the 'canceling' state until the bed temp is reached. On my printer, it takes several minutes which is a rude waste of my time. Please, find a solution.

[GitIssueBot]

Hi @halxinate,

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 - that can be found at discourse.octoprint.org. Go there for any kind of issues with network connectivity, webcam functionality, printer detection or any other kind of such support requests or general questions.

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 2019-02-09 21:50 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.

[ghost]

which is a rude waste of my time

How rude of whom, however?. Although I can immediately perceive one very obvous candidate.

Depending on your printers firmware, how it is configured and how you have configured octoprint, all of which is suitably well documented (what a rude waste of their time if it is not read by someone), you may or may not be able to interrupt the heating process.

So you may be able to solve this, or you may not.

That's life.

Please, find a solution.

Google things like M109, EMERGENCY PARSER and suchlike to get an idea of what may be involved.

On my printer, it takes several minutes

Bad choice of printer, and/or bad choice of firmware and/or wrongly configured

Nuff said

[JustAnother1]

I had a similar issue, and a possible solution was probably suggested before.
As I understand it the issue is the M190 command. It is defined to wait until the bed reaches the commanded temperature. You need to use them in gcode files as you want the printer to wait.

For Octoprint using this command creates a "long running" command. The printer _should_ not read the next command before finishing this one. So there might be work around in some firmware that help, but it really is the way it is supposed to be.

The possible solution would be for Octoprint to detect that the command is a M190 and to replace it with a M140. The M140 just configures the heater and returns immediately. Octoprint could then monitor the heated bed temperature until it reaches the level defined in the M190 command. Once the bed is heated Octoprint could then continue sending commands. This would allow Octoprint to talk to the printer during the "long running" command.

[foosel]

There's an FAQ entry on this. So this ticket is a rude waste of my time.