Octoprint: [Request] Report to user when the printer is unresponsive due to a blocking heatup

[ManuGithubSteam]

---

What were you doing?

Click on the cancel button next to the print button in the main window.

What did you expect to happen?

1. Print does not start (abort was early!) -> yes it does indeed not start.
2. Hotend to get turned off -> does NOT happen
3. Bed to get turned off -> does also NOT happen
   4.(Nice to have) Extruder moves 1cm away from print.
4. Octoprint should be ready to start a new print imidietly -> no nothing happens, if i start a new one. I assume it is because the hotend and bed are not cooled so it assumes it is not "ready"???

I assumed octoprint would handle the shutdown of the hotend and heated bed, but it did not. Still i had the gcodes in place so as it should execute them after cancel the hotend and bed should shut down with that too. So both methods seem not to work......

What happened instead?

Hotend was warming up and bed was warming up.
Printer shows "Operational" but as stated it is not possible to start a new print and the old one does not start.

I had to manualy set the bed and hotend temp to zero.
I have this in my gcode sections:

After print job completes
G4 ; wait
M104 S0 ; turn off temperature
M140 S0 ; turn off heatbed
M107 ; turn off fan
M84 ; disable motors

After print job is cancelled
(same as above)

But it did not get executed i guess...

Branch & Commit or Version of OctoPrint

master, synced yesterday

Printer model & used firmware incl. version

Prusa i3 Mk2 Firwamre 3.08

Browser and Version of Browser, Operating System running Browser

Firefox, Linux, Arch 64 bit.

Link to octoprint.log

http://pastebin.com/gWmhZdnb

Link to contents of terminal tab or serial.log

http://pastebin.com/A174anSK

[GitIssueBot]

Hi @ManuGithubSteam,

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 2016-10-02 22:20 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.

[foosel]

Contents of terminal tab please. serial.log needs to be enabled (performance reasons), terminal tab is always available however, which it why there's an "or" in the request for it ;) So please provide what's in there directly when you are observing the problem.

Chances are high however that your printer simply was still in the blocking heatup which OctoPrint cannot interrupt (there is no command to do that, that's an oversight on the firmware side of things), so if you cancel when that is active you either have to reset the printer for it to become responsive again or simply wait for it to finish before OctoPrint will send new commands to it (because if it tries to do that while it is still active, depending on the printer model buffer overflows can occur and cause bad things to happen). Yes, I know, stupid, but again, really nothing OctoPrint can do since the printer simply becomes unresponsive during blocking heat ups.

PS: do not remove any lines not enclosed in [ and ] from the ticket template or the bot will become active.

[foosel]

Ah, never mind, didn't see that you'd edited your ticket with the serial.log when I wrote that comment.

It's exactly as I thought:

2016-09-19 00:47:12,772 - SERIAL - DEBUG - Send: N7 M190 S95*83
2016-09-19 00:47:13,782 - SERIAL - DEBUG - Recv: T:26.72 E:0 B:25.7
2016-09-19 00:47:14,781 - SERIAL - DEBUG - Recv: T:26.81 E:0 B:25.9
2016-09-19 00:47:15,785 - SERIAL - DEBUG - Recv: T:27.06 E:0 B:25.8
2016-09-19 00:47:16,788 - SERIAL - DEBUG - Recv: T:27.53 E:0 B:25.8
2016-09-19 00:47:17,788 - SERIAL - DEBUG - Recv: T:28.56 E:0 B:25.7
2016-09-19 00:47:18,792 - SERIAL - DEBUG - Recv: T:30.13 E:0 B:25.7
2016-09-19 00:47:19,791 - SERIAL - DEBUG - Recv: T:31.47 E:0 B:25.8
2016-09-19 00:47:20,794 - SERIAL - DEBUG - Recv: T:33.23 E:0 B:25.9
2016-09-19 00:47:21,798 - SERIAL - DEBUG - Recv: T:35.13 E:0 B:26.0
2016-09-19 00:47:22,798 - SERIAL - DEBUG - Recv: T:37.48 E:0 B:26.1
2016-09-19 00:47:23,801 - SERIAL - DEBUG - Recv: T:39.87 E:0 B:26.2
2016-09-19 00:47:24,805 - SERIAL - DEBUG - Recv: T:42.17 E:0 B:26.4
2016-09-19 00:47:25,804 - SERIAL - DEBUG - Recv: T:44.34 E:0 B:26.5
2016-09-19 00:47:26,807 - SERIAL - DEBUG - Recv: T:46.67 E:0 B:26.8
2016-09-19 00:47:27,807 - SERIAL - DEBUG - Recv: T:49.09 E:0 B:26.8
2016-09-19 00:47:28,811 - SERIAL - DEBUG - Recv: T:51.27 E:0 B:27.2
2016-09-19 00:47:29,813 - SERIAL - DEBUG - Recv: T:53.35 E:0 B:27.3
2016-09-19 00:47:30,387 - SERIAL - DEBUG - Changing monitoring state from 'Printing' to 'Operational'

That's your printer heating up the print bed with a blocking heat, as instructed by the M190. It's still busy with that when you clicked cancel (which OctoPrint logs with that "changing state" line there).

It continues to heat for quite a while until:

2016-09-19 00:54:13,227 - SERIAL - DEBUG - Recv: T:240.00 E:0 B:95.0
2016-09-19 00:54:14,256 - SERIAL - DEBUG - Recv: T:240.10 E:0 B:95.0
2016-09-19 00:54:15,262 - SERIAL - DEBUG - Recv: T:239.92 E:0 B:95.0
2016-09-19 00:54:16,263 - SERIAL - DEBUG - Recv: T:240.10 E:0 B:95.0
2016-09-19 00:54:16,553 - SERIAL - DEBUG - Recv: ok
2016-09-19 00:54:16,556 - SERIAL - DEBUG - Send: G4
2016-09-19 00:54:16,561 - SERIAL - DEBUG - Recv: ok
2016-09-19 00:54:16,563 - SERIAL - DEBUG - Send: M104 S0
2016-09-19 00:54:16,569 - SERIAL - DEBUG - Recv: ok
2016-09-19 00:54:16,571 - SERIAL - DEBUG - Send: M140 S0
2016-09-19 00:54:16,577 - SERIAL - DEBUG - Recv: ok
2016-09-19 00:54:16,578 - SERIAL - DEBUG - Send: M107
2016-09-19 00:54:16,585 - SERIAL - DEBUG - Recv: ok
2016-09-19 00:54:16,586 - SERIAL - DEBUG - Send: M84
2016-09-19 00:54:16,590 - SERIAL - DEBUG - Recv: ok
2016-09-19 00:54:16,591 - SERIAL - DEBUG - Send: M104 S0.000000
2016-09-19 00:54:16,598 - SERIAL - DEBUG - Recv: ok
2016-09-19 00:54:16,599 - SERIAL - DEBUG - Send: M104 S0.000000
2016-09-19 00:54:16,605 - SERIAL - DEBUG - Recv: ok

it finally reaches its target temperature. Then the printer accepts commands again (finally) at which point OctoPrint immediately sends exactly what you defined as cancel GCODE - followed by a couple of manual temperature set commands by you.

So - sadly that's behaviour as expected. We could turn that into a feature request to add a new state report so that OctoPrint flips to "Heating" here while it is still heating to indicate that it can't talk to the printer (since it won't listen) right now and hence can do absolutely nothing, but that's about all I can do from my side with current firmware behaviour.

[ManuGithubSteam]

Hi

Thank you for clearing that up! YES a Heating state maybe with a overlay
(heating - please wait) or something would be great!

I assume i can include a "move Z axis 1 cm up" into the termination code.

Thanks for your quick response :-)

Manuel

On 09/19/2016 08:11 AM, Gina Häußge wrote:

Ah, never mind, didn't see that you'd edited your ticket with the
serial.log when I wrote that comment.

It's exactly as I thought:

|2016-09-19 00:47:12,772 - SERIAL - DEBUG - Send: N7 M190 S95*83
2016-09-19 00:47:13,782 - SERIAL - DEBUG - Recv: T:26.72 E:0 B:25.7
2016-09-19 00:47:14,781 - SERIAL - DEBUG - Recv: T:26.81 E:0 B:25.9
2016-09-19 00:47:15,785 - SERIAL - DEBUG - Recv: T:27.06 E:0 B:25.8
2016-09-19 00:47:16,788 - SERIAL - DEBUG - Recv: T:27.53 E:0 B:25.8
2016-09-19 00:47:17,788 - SERIAL - DEBUG - Recv: T:28.56 E:0 B:25.7
2016-09-19 00:47:18,792 - SERIAL - DEBUG - Recv: T:30.13 E:0 B:25.7
2016-09-19 00:47:19,791 - SERIAL - DEBUG - Recv: T:31.47 E:0 B:25.8
2016-09-19 00:47:20,794 - SERIAL - DEBUG - Recv: T:33.23 E:0 B:25.9
2016-09-19 00:47:21,798 - SERIAL - DEBUG - Recv: T:35.13 E:0 B:26.0
2016-09-19 00:47:22,798 - SERIAL - DEBUG - Recv: T:37.48 E:0 B:26.1
2016-09-19 00:47:23,801 - SERIAL - DEBUG - Recv: T:39.87 E:0 B:26.2
2016-09-19 00:47:24,805 - SERIAL - DEBUG - Recv: T:42.17 E:0 B:26.4
2016-09-19 00:47:25,804 - SERIAL - DEBUG - Recv: T:44.34 E:0 B:26.5
2016-09-19 00:47:26,807 - SERIAL - DEBUG - Recv: T:46.67 E:0 B:26.8
2016-09-19 00:47:27,807 - SERIAL - DEBUG - Recv: T:49.09 E:0 B:26.8
2016-09-19 00:47:28,811 - SERIAL - DEBUG - Recv: T:51.27 E:0 B:27.2
2016-09-19 00:47:29,813 - SERIAL - DEBUG - Recv: T:53.35 E:0 B:27.3
2016-09-19 00:47:30,387 - SERIAL - DEBUG - Changing monitoring state
from 'Printing' to 'Operational' |

That's your printer heating up the print bed with a blocking heat, as
instructed by the |M190|. It's still busy with that when you clicked
cancel (which OctoPrint logs with that "changing state" line there).

It continues to heat for quite a while until:

|2016-09-19 00:54:13,227 - SERIAL - DEBUG - Recv: T:240.00 E:0 B:95.0
2016-09-19 00:54:14,256 - SERIAL - DEBUG - Recv: T:240.10 E:0 B:95.0
2016-09-19 00:54:15,262 - SERIAL - DEBUG - Recv: T:239.92 E:0 B:95.0
2016-09-19 00:54:16,263 - SERIAL - DEBUG - Recv: T:240.10 E:0 B:95.0
2016-09-19 00:54:16,553 - SERIAL - DEBUG - Recv: ok 2016-09-19
00:54:16,556 - SERIAL - DEBUG - Send: G4 2016-09-19 00:54:16,561 -
SERIAL - DEBUG - Recv: ok 2016-09-19 00:54:16,563 - SERIAL - DEBUG -
Send: M104 S0 2016-09-19 00:54:16,569 - SERIAL - DEBUG - Recv: ok
2016-09-19 00:54:16,571 - SERIAL - DEBUG - Send: M140 S0 2016-09-19
00:54:16,577 - SERIAL - DEBUG - Recv: ok 2016-09-19 00:54:16,578 -
SERIAL - DEBUG - Send: M107 2016-09-19 00:54:16,585 - SERIAL - DEBUG -
Recv: ok 2016-09-19 00:54:16,586 - SERIAL - DEBUG - Send: M84
2016-09-19 00:54:16,590 - SERIAL - DEBUG - Recv: ok 2016-09-19
00:54:16,591 - SERIAL - DEBUG - Send: M104 S0.000000 2016-09-19
00:54:16,598 - SERIAL - DEBUG - Recv: ok 2016-09-19 00:54:16,599 -
SERIAL - DEBUG - Send: M104 S0.000000 2016-09-19 00:54:16,605 - SERIAL

• DEBUG - Recv: ok |

it finally reaches its target temperature. Then the printer accepts
commands again (finally) at which point OctoPrint immediately sends
exactly what you defined as cancel GCODE - followed by a couple of
manual temperature set commands by you.

So - sadly that's behaviour as expected. We could turn that into a
feature request to add a new state report so that OctoPrint flips to
"Heating" here while it is still heating to indicate that it can't
talk to the printer (since it won't listen) right now and hence can do
absolutely nothing, but that's about all I can do from my side with
current firmware behaviour.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/foosel/OctoPrint/issues/1504#issuecomment-247916926,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADS_4ttSV3bFt6FLr_DdpS2BE2G_X3kaks5qrid0gaJpZM4KACGP.

[ntoff]

@foosel

but that's about all I can do from my side with current firmware behaviour.

According to the reprap wiki http://reprap.org/wiki/G-code#M108:_Cancel_Heating_.28Marlin.29 Marlin can now break out of the heating cycle with M108.

[foosel]

@ntoff No, the current Marlin RC can (I was actually part of the discussion). Which is a very small percentage of all installations out there and will take years to propagate through (if it does at all).

[ntoff]

Yeah but it's still something to think about for octoprint version 1.3+ isn't it? I guess you don't want to go randomly sending M108 "just in case" when the user hits cancel either in case it does something else on other firmware like how the "stop motors" button in the controls page does absolutely nothing if you're running repetier firmware.

[foosel]

It is, and I have it on my radar, but it doesn't help in this specific case
here sadly.

[markwal]

We could make a plugin that sends M112 on cancel. Though that will make any Marlin printer that supports it cancel the heatup and then go into a freeze loop until you restart it.

[gruvin]

I think this one deserves a re-look ...

See, it's not _really_ the printer blocking, in this case. It is Octoprint blocking, waiting for an "ok" and refusing to do anything until it gets one -- even though the printer _will_ in fact happily swallow an M108 and return an ok, meaning it's not _technically_ blocking.

SUGGESTED SOLUTIONS

Obviously, we need a solution that doesn't require knowledge of any given printer's firmware capabilities. Two ideas follow ...

How about a new snippet style function? Do you call them macros? Something like {% fake_acknowledgement %} or (% skip_ok %)?

Such a feature would avoid the issue of firmware differences, by leaving it all up to the user and their cancel script.

If that would break too much existing logic -- maybe things just aren't set up to handle reading scripts ahead of the line presently waiting for an ok -- then a checkbox below the cancel script,

[ ] Fake Acknowledgement before script execution
or
[ ] Don't wait for 'ok' and send cancel script immediately

... might do the trick.

Guess you'd want to purge the serial output buffer (not flush) before triggering the fake acknowledgement logic.

It sure would be nice to have this one.

For now, hitting Cancel then Fake Acknowledgment -- strictly in that order -- seems to do the trick for me.

[foosel]

See, it's not _really_ the printer blocking, in this case. It is Octoprint blocking, waiting for an "ok" and refusing to do anything until it gets one -- even though the printer _will_ in fact happily swallow an M108 and return an ok, meaning it's not _technically_ blocking.

That's like saying it's not technically a red light that's blocking traffic on the road at a given moment, it's just the drivers adhering to traffic laws ;)

OctoPrint must not proceed sending data to the printer if the firmware hasn't signaled that it may do so. M112 and M108 are exceptions to that rule since they are handled differently in some firmwares and may be received even while the printer is processing a blocking operation. If the firmware has capability reports enabled (which thankfully is something that more and more machines out there do) it's possible to detect this.

So the best approach here would be to add an M108 to the cancel script (possibly by default, but that has to be evaluated thanks to the thousands of firmware variants out there), modify OctoPrint to detect the presence of the emergency parser (EMERGENCY_PARSER capability) and if so enable sending of M108 without acknowledgment - but only then.

[gruvin]

:-)

Well I disagree about the traffic analogy. There is no red light. In the US
(I don't live there) at night their light flash on/off amber only, meaning
proceed at your own discretion -- because otherwise you can be sat waiting
for green forever, when there's not another vehicle in sight. If we're
going to use traffic analogies, that's my rebuttal. :p Anywho ...

So, you didn't like my suggestions, where none of the difficulties you just
reiterated would be an issue, since the power to use it or not would be
entirely in the user's hands?

I believe you're overthinking it -- trying to make the software be too
smart. Just give us a way, either in a script or as an option before
running a script, to trigger Fake Acknowledgment. Call it an advanced user
thing or whatever. Who cares if it has anything to do with emergency
commands or whatever. Just give us a way to abort waiting for an ok -- for
whatever reason we choose. No?

I'll leave it that. If you don't agree, well OK. I'll live. Might even just
fork (privately) and do it myself, then go back to upstream/master some
time down the track when you've solved this in better than I can imagine,
as you often do. Just feeling lazy and busy with other things, so you know,
was hoping. ;-)

Have a great day.

Bryan.

[ntoff]

that's my rebuttal

And it's a terrible one because as far as printers go, there's always traffic when communicating via serial, without that red light, you're going to have a bad time.

[foosel]

So, you didn't like my suggestions, where none of the difficulties you just reiterated would be an issue, since the power to use it or not would be entirely in the user's hands? I believe you're overthinking it -- trying to make the software be too smart. Just give us a way, either in a script or as an option before running a script, to trigger Fake Acknowledgment.

There already is a way - it's called "writing a plugin".

As for core capabilities, I have to "overthink" it - the average 3d printing user these days expects things to work out of the box, without them having to dig through configuration options. Most people don't even know anymore what firmware they are running, let alone what the correct configuration for it would be to work around problems like this one, even if shown corresponding step by step guides.

The past years of maintaining this software have sadly shown me that just slapping a config option for every possible situation in there won't solve the issue, in fact it will often times only make it worse (and make the UX terrible as well).

[foosel]

Since I was looking at the comm layer anyhow for a different fix I've now added detection of the EMERGENCY_PARSER capability, special handling for M108 and M410 (no longer wait for ok if EMERGENCY_PARSER is enabled) and added M108 to the cancel procedure.

Pushed to maintenance, soon devel, will be part of 1.3.10.

[gruvin]

I have to "overthink" it

Fair enough.

... shown me that just slapping a config option for every possible situation in there won't solve the issue ...

Indeed. That was my thinking for the kind of obscure, hidden (% secret_sauce %) option, though implementing that way would have been a pain, I'm sure.

... I've now added detection of the EMERGENCY_PARSER capability

Whoa, what?! AWESOME! Thanks so much. Super duper cool.

Best not make this a habit, pushing your schedule out just because I'm moaning at you.

Or ... did you know it was my 48th birthday to day? You've made it a good one already. :-) (8:20am here in NZ.)

EDIT: Oh and, I didn't know a plugin could go that deep. Must look into those more.

Bryan.

[gruvin]

that's my rebuttal

And it's a terrible one because as far as printers go, there's _always_ traffic when communicating via serial, without that red light, you're going to have a bad time.

Hence the word, "discretion". OctoPrint _can_ exercise discretion. No OK? Look left, look right, proceed if clear.

This is called a protocol, albeit a badly broken one (thanks Marlin!) Don't even get me started on M117 and how it trashes GCODE to the point of requiring all kinds of annoying state machine exceptions -- especially if you want to comply with the "case doesn't matter" part.

It is what it is and we just have to deal with it.

Ah, don't ya just love these pointless banterings. Seems I don't have enough work to do. 😛

[foosel]

1.3.10 has been released.