Octoprint: Pausing the printer using gcode causes octo print to time out the connection. (Marlin M600 command)

Created on 26 Sep 2017  Â·  9Comments  Â·  Source: OctoPrint/OctoPrint

What were you doing?

Printing a dual color print using Prusa MKS2 M600 command. If I happen to be printing over night, octo print most definitively time out because I cannot baby sit the printer to change the filament.

What did you expect to happen?

Printer pauses till someone insert the new filament, then continue with the print.

What happened instead?

Connection time out and loses connection to the printer. Only if I take time to get to the printer.

Branch & Commit or Version of OctoPrint

1.3.5rc3

Operating System running OctoPrint

OctoPi on a pi3

Printer model & used firmware incl. version

Prusa MKS2 FIRMWARE 3.0.12

Link to octoprint.log

2017-09-26 05:57:41,295 - octoprint.printer.standard - ERROR - Exception while pushing current data
Traceback (most recent call last):
  File "/home/pi/oprint/local/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/printer/standard.py", line 155, in _sendCurrentDataCallbacks
    try: callback.on_printer_send_current_data(copy.deepcopy(data))
  File "/usr/lib/python2.7/copy.py", line 163, in deepcopy
    y = copier(x, memo)
  File "/usr/lib/python2.7/copy.py", line 257, in _deepcopy_dict
    y[deepcopy(key, memo)] = deepcopy(value, memo)
  File "/usr/lib/python2.7/copy.py", line 163, in deepcopy
    y = copier(x, memo)
  File "/usr/lib/python2.7/copy.py", line 256, in _deepcopy_dict
    for key, value in x.iteritems():
RuntimeError: dictionary changed size during iteration
2017-09-26 05:59:30,821 - octoprint.server.util.sockjs - INFO - Client connection closed: 172.168.1.41
2017-09-26 06:14:31,439 - octoprint.printer.standard - ERROR - Exception while pushing current data
Traceback (most recent call last):
  File "/home/pi/oprint/local/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/printer/standard.py", line 155, in _sendCurrentDataCallbacks
    try: callback.on_printer_send_current_data(copy.deepcopy(data))
  File "/usr/lib/python2.7/copy.py", line 163, in deepcopy
    y = copier(x, memo)
  File "/usr/lib/python2.7/copy.py", line 257, in _deepcopy_dict
    y[deepcopy(key, memo)] = deepcopy(value, memo)
  File "/usr/lib/python2.7/copy.py", line 163, in deepcopy
    y = copier(x, memo)
  File "/usr/lib/python2.7/copy.py", line 256, in _deepcopy_dict
    for key, value in x.iteritems():
RuntimeError: dictionary changed size during iteration
2017-09-26 06:30:16,897 - octoprint.server.util.sockjs - INFO - New connection from client: 172.168.1.41
2017-09-26 09:24:43,004 - octoprint.printer.standard - ERROR - Exception while pushing current data
Traceback (most recent call last):
  File "/home/pi/oprint/local/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/printer/standard.py", line 155, in _sendCurrentDataCallbacks
    try: callback.on_printer_send_current_data(copy.deepcopy(data))
  File "/usr/lib/python2.7/copy.py", line 163, in deepcopy
    y = copier(x, memo)
  File "/usr/lib/python2.7/copy.py", line 257, in _deepcopy_dict
    y[deepcopy(key, memo)] = deepcopy(value, memo)
  File "/usr/lib/python2.7/copy.py", line 163, in deepcopy
    y = copier(x, memo)
  File "/usr/lib/python2.7/copy.py", line 256, in _deepcopy_dict
    for key, value in x.iteritems():
RuntimeError: dictionary changed size during iteration
2017-09-26 09:31:06,364 - octoprint.util.comm - INFO - No response from printer after 6 consecutive communication timeouts, considering it dead.
2017-09-26 09:31:06,906 - octoprint.plugins.detailedprogress - INFO - Printing stopped. Detailed progress stopped.

Link to contents of terminal tab or serial.log

Send: N78279 M600*38
No response from printer after 6 consecutive communication timeouts, considering it dead. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Changing monitoring state from 'Printing' to 'Offline: Too many consecutive timeouts, printer still connected and alive?'
Connection closed, closing down monitor
Changing monitoring state from 'Offline' to 'Detecting serial port'
incomplete

All 9 comments

Hi @hansaya,

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-10-10 15: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.

This maybe not a bug, now I think of it. Might be an feature to add? I know that you can change the timeout interval but that is not a solution to this problem. I dont know what makes the octo print consider "No response", is there a heart beat? or is it just simply waiting for M600 to be done? If there need to be an heart beat, I'll post a question out the Marlin firmware guys.
P.S Great project and I love it!

This happens also if you install a filament runout sensor tot he control
board instead of installing to the RPi IO pins.... The printer stops and
after a some time Octoprint timeout the connection.... Octoprint should be
able to identify that is a pause and not a timeout.

Em ter, 26 de set de 2017 às 13:35, Hans notifications@github.com
escreveu:

This maybe not a bug, now I think of it. Might be an feature to add? I
know that you can change the timeout interval but that is not a solution to
this problem. I dont know what makes the octo print consider "No response",
is there a heart beat? or is it just simply waiting for M600 to be done? If
there need to be an heart beat, I'll post a question out the Marlin
firmware guys.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/foosel/OctoPrint/issues/2129#issuecomment-332258359,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Aa1_mXZiLf8bKeVVU-jvSSo1mxrWUr8Zks5smSe-gaJpZM4PkdlC
.

@brunofporto Thanks for the heads up :-). I was thinking of installing filament run out sensor this weekend. My guess is with the new release of Prusa MK3 lot more people going to see this issue. New printer will pause the printer for so many reasons. :-S

Maybe solution here is to have octoprint detect different flavors of gcode pause commands as paused status? Then get out of the Pause status if command succeeded? Then do normal temperature request commands to check whether printer is alive? Same goes with if the printer stopped executing the gcodes then go into paused status and send normal status requests? I have little to no knowledge on how all this works together but let me know if anyway I can help to solve this issue, I'm happy to do research and contribute in anyway.

is there a heart beat

Some firmwares will send out "wait" when they're idle or "busy" when they're doing something that may block the host. I know Repetier firmware does, I think Marlin might, no idea about Prusa's version of Marlin though.

After digging through marlin I found M113 - Get or set the timeout interval for Host Keepalive "busy" messages http://marlinfw.org/docs/gcode/M113.html

I'm guessing we can set this to a set interval before starting the print. I'm going try this out when I get home

That keepalive message would already be sent if your firmware was compiled with the corresponding flag and supported it on the first place. You stated however that you are running a MK2 and their firmware flavor doesn't even support that feature.

A couple months ago I opened a ticket on the prusa marlin fork's bug tracker for exactly this kind of issues but so far I think they didn't fix the issues with the various commands that nuke the serial communication and/or add support for the busy protocol. At least I can't remember seeing an update on the ticket. See prusa3d/Prusa-Firmware#67. And also #2026 of which this ticket is a duplicate of ;)

That traceback in your log looks like #1951, if you could add some info on how you got this trace to that ticket that would be great because that one I still haven't been able to reproduce.

Thank you for the reply. I can see whats going on now, and I'll keep a close eye out on the prusa firmware ticket you opened. Closing this ticket :)

Was this page helpful?
0 / 5 - 0 ratings