Auto reconnect after turning the printer off and on.

[MichMich]

What were you doing?

When a print on my Lulzbot Mini is finished I take it off the built plate and turn off the printer. The Raspberry Pi (Running OctoPrint) remains on. If I want to print something new, I turn on the printer, and open OctoPrint in my browser. OctoPrint then still thinks it's connected, but the communication with the printer doesn't work until I click "Disconnect" and reconnect after disconnecting using the "Connect" button.

What did you expect to happen?

I expect OctoPrint to automatically try to reconnect with the printer if it stops responding. As soon as I turn on the printer, the connection should be reestablished.

What happened instead?

OctoPrint says it's connected, but all commands fail. The printer does not respond until reconnecting.

Branch & Commit or Version of OctoPrint

Version: 1.2.13 (master branch)

Printer model & used firmware incl. version

Lulzbot Mini. (Firmware unknown, will look into this after my print finishes.)

Browser and Version of Browser, Operating System running Browser

Safari 9.1.1 (But the browser has no influence on this.)

Link to octoprint.log

http://pastebin.com/3gbJ1QrH

Link to contents of terminal tab or serial.log

Send: M105
Recv: ok T:80.8 /0.0 B:50.2 /50.0 T0:80.8 /0.0 @:0 B@:0
Send: M105
Recv: ok T:80.0 /0.0 B:50.1 /50.0 T0:80.0 /0.0 @:0 B@:0
Send: M105
Recv: ok T:79.1 /0.0 B:49.9 /50.0 T0:79.1 /0.0 @:0 B@:21
Send: M105
Recv: ok T:78.2 /0.0 B:49.9 /50.0 T0:78.2 /0.0 @:0 B@:31
Send: M105
Recv: ok T:77.4 /0.0 B:50.2 /50.0 T0:77.4 /0.0 @:0 B@:0
Send: M105
Recv: ok T:76.6 /0.0 B:50.0 /50.0 T0:76.6 /0.0 @:0 B@:6
Send: M105
Send: M105
Recv: start
Recv: echo:Marlin1.0.0
Recv: echo: Last Updated: May 12 2015 10:00:43 | Author: (Aleph Objects Inc, Mini-2015Q1)
Recv: Compiled: May 12 2015
Recv: echo: Free Memory: 4882  PlannerBufferBytes: 1296
Recv: echo:Hardcoded Default Settings Loaded
Recv: echo:Steps per unit:
Recv: echo:  M92 X100.50 Y100.50 Z1600.00 E833.00
Recv: echo:Maximum feedrates (mm/s):
Recv: echo:  M203 X800.00 Y800.00 Z8.00 E40.00
Recv: echo:Maximum Acceleration (mm/s2):
Recv: echo:  M201 X9000 Y9000 Z100 E1000
Recv: echo:Acceleration: S=acceleration, T=retract acceleration
Recv: echo:  M204 S2000.00 T3000.00
Recv: echo:Advanced variables: S=Min feedrate (mm/s), T=Min travel feedrate (mm/s), B=minimum segment time (ms), X=maximum XY jerk (mm/s),  Z=maximum Z jerk (mm/s),  E=maximum E jerk (mm/s)
Recv: echo:  M205 S0.00 T0.00 B20000 X12.00 Z0.40 E10.00
Recv: echo:Home offset (mm):
Recv: echo:  M206 X0.00 Y0.00 Z0.00
Recv: echo:PID settings:
Recv: echo:   M301 P28.79 I1.91 D108.51

[Printer Turned Off/On]

Changing monitoring state from 'Operational' to 'Printing'
Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: N51888 M105*43
Recv: Error:Line Number is not Last Line Number+1, Last Line: 0
Recv: Resend: 1
Printer requested line 1 but no sufficient history is available, can't resend
Changing monitoring state from 'Printing' to 'Error: Printer requested line 1 but no sufficient history is available, can't resend'
Recv: ok
Send: N0 M110 N0*125
Recv: ok
Send: M105
Recv: ok T:22.3 /0.0 B:23.0 /0.0 T0:22.3 /0.0 @:0 B@:0

[Pressed Connect Button]

Changing monitoring state from 'Error: Printer requested line 1 but no sufficient history is available, can't resend' to 'Closed'
Connecting to: /dev/ttyACM0
Changing monitoring state from 'Offline' to 'Opening serial port'
Connected to: Serial<id=0x2308bb0, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Changing monitoring state from 'Opening serial port' to 'Connecting'
Send: N0 M110 N0*125
Recv: ok
Changing monitoring state from 'Connecting' to 'Operational'
Send: N0 M110 N0*125
Recv: ok
Send: M21
Recv: ok
Send: M105
Recv: ok T:22.7 /0.0 B:23.2 /0.0 T0:22.7 /0.0 @:0 B@:0
Send: M105
Recv: ok T:22.7 /0.0 B:23.1 /0.0 T0:22.7 /0.0 @:0 B@:0
Connection closed, closing down monitor
Send: M105
Recv: ok T:22.7 /0.0 B:23.1 /0.0 T0:22.7 /0.0 @:0 B@:0
Send: M105
Recv: ok T:22.7 /0.0 B:23.1 /0.0 T0:22.7 /0.0 @:0 B@:0
Send: M105
Recv: ok T:22.6 /0.0 B:23.0 /0.0 T0:22.6 /0.0 @:0 B@:0
Send: M105
Recv: ok T:22.7 /0.0 B:23.1 /0.0 T0:22.7 /0.0 @:0 B@:0
Send: M105
Recv: ok T:22.8 /0.0 B:23.1 /0.0 T0:22.8 /0.0 @:0 B@:0
Send: M105
Recv: ok T:22.7 /0.0 B:23.1 /0.0 T0:22.7 /0.0 @:0 B@:0
Send: M105
Recv: ok T:22.8 /0.0 B:23.2 /0.0 T0:22.8 /0.0 @:0 B@:0
Send: M105
Recv: ok T:22.7 /0.0 B:23.2 /0.0 T0:22.7 /0.0 @:0 B@:0
Send: M105
Recv: ok T:22.7 /0.0 B:23.2 /0.0 T0:22.7 /0.0 @:0 B@:0

Link to contents of Javascript console in the browser

NA

Screenshot(s) showing the problem:

NA

[GitIssueBot]

Hi @MichMich,

It looks like there is some information missing from your bug report that will be needed in order to solve the problem. Please take a look at 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, please take special note of the title format to use as described in the Contribution Guidelines.

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-07-07 14:00) 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]

Bot complained because you didn't copy the template completely...

Telling it to step down but marking the ticket as "awaiting information" since this a problem that definitely needs a serial.log or at the very least the output from the terminal tab to have any change to diagnose further.

[nophead]

I have found that more recent OctoPrint versions need a fake ack after
switching the printer on and off.

On 23 June 2016 at 15:53, Gina Häußge notifications@github.com wrote:

Bot complained because you didn't copy the template completely...

Telling it to step down but marking the ticket as "awaiting information"
since this a problem that definitely needs a serial.log or at the very
least the output from the terminal tab to have any change to diagnose
further.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#1388 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAijhQ-lVoBgdYUpkrPJXM-SwMEVFKPBks5qOp34gaJpZM4I81f0
.

[KC703]

I also use the Fake Ack under the Terminal->Advanced to re-connect to the printer after shutting it off / on remotely.

[MichMich]

I've added the Serial log to the initial issue.

I can confirm that the Fake Ack is a solution, but it would be better if this wasn't nessecery.

[foosel]

[Printer Turned Off/On]

Changing monitoring state from 'Operational' to 'Printing'

That looks like immediately after turning the printer back on you directly started printing - is there something missing from the log or is that really what happened here?

Or am I simply misreading that log annotations by you?

It also looks a bit like while powering off the printer lead to the firmware not replying anymore, the serial connection was nevertheless still kept open. Is that indeed the case?

[MichMich]

No, after turning the printer back on, there simply isn't any communication. Even if I wait 10 minutes before I press print, it wont work. I need to do a Fake Ack and then the communication will work again.

[foosel]

But while the printer is turned off there is also no communication, even though the serial connection is still present?

[MichMich]

Exactly.

[bolsoncerrado]

Not sure if related, mine is not a "branded" printer, but i've noticed since recent updates that Autoconnect on startup no longer works?

[foosel]

@bolsoncerrado huh, that works just fine here, both with a real printer and the virtual printer, on master (1.2.13) and maintenance branch (1.2.14.dev).

The issue described by @MichMich rather seems to be caused by the fact that OctoPrint never picks up on the printer being AWOL since the serial connection never drops on its own but instead just stops responding with ok. OctoPrint currently ignores serial timeouts while not printing, so I guess that has to be changed in order to fix this. That will still not allow OctoPrint to immediately detect that the printer went away if it just stops responding without dropping the serial line - I can only work with timeouts there sadly, the printer not responding because it decided to die reads exactly the same as a printer which is currently busy with an extra long move or a printer which send an ok just right but it got garbled on the serial line.

Been trying to fix this today but ran into some odd deadlock issues I don't fully understand so far.

[MichMich]

Hi Gina, the fake acknowledgement is a workable workaround for the time being. So take your time looking for a resolution.

[foosel]

It's "solved" now in the way that at least OctoPrint will now again detect printers that just go AWOL with any life sign, but still keep the serial line (which they don't reply on anymore) open. I've added a tracking of consecutive communication timeouts, once a certain limit is reached (individually configurable - via config.yaml only for now - for idle, printing and during long running commands) the printer will be considered gone and the connection closed.

That means you will have to reconnect though, which is better than having to press semi-hidden buttons or disconnect AND reconnect however, and it better mirrors the actual state of the connection - the printer is no longer really connected when it doesn't respond on serial anymore.

[foosel]

via config.yaml only for now

Correction, I in fact did add those settings to the serial configuration dialog and just forgot about it O_O

[MichMich]

Great, I'll give it a try!

[foosel]

Merged to master and released with 1.2.14.

[MichMich]

@foosel I can confirm this issue is solved in the latest release! Thanks!