[Request] Report to user when the printer is unresponsive due to a blocking heatup #1504
Comments
|
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, 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. |
GitIssueBot
added
the
incomplete
|
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
added
needs information
|
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: That's your printer heating up the print bed with a blocking heat, as instructed by the It continues to heat for quite a while until: 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. |
foosel
added
request
foosel
changed the title
|
Hi Thank you for clearing that up! YES a Heating state maybe with a overlay 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:
|
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. |
|
@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). |
|
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. |
|
It is, and I have it on my radar, but it doesn't help in this specific case
here sadly.
|
|
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. |
|
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 SUGGESTED SOLUTIONSObviously, 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 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
... 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. |
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. So the best approach here would be to add an |
|
:-)
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.
|
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. |
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). |
|
Since I was looking at the comm layer anyhow for a different fix I've now added detection of the Pushed to |
Fair enough.
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.
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. |
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 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. 😛 |
|
1.3.10 has been released. |
What were you doing?
Click on the cancel button next to the print button in the main window.
What did you expect to happen?
4.(Nice to have) Extruder moves 1cm away from print.
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
The text was updated successfully, but these errors were encountered: