Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auto reconnect after turning the printer off and on. #1388

Closed
MichMich opened this issue Jun 23, 2016 · 17 comments

Comments

Projects
None yet
6 participants
@MichMich
Copy link

commented Jun 23, 2016

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

This comment has been minimized.

Copy link
Collaborator

commented Jun 23, 2016

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

This comment has been minimized.

Copy link
Owner

commented Jun 23, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Jun 23, 2016

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

This comment has been minimized.

Copy link

commented Jun 24, 2016

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

@MichMich

This comment has been minimized.

Copy link
Author

commented Jul 1, 2016

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

This comment has been minimized.

Copy link
Owner

commented Jul 2, 2016

[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

This comment has been minimized.

Copy link
Author

commented Jul 2, 2016

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

This comment has been minimized.

Copy link
Owner

commented Jul 2, 2016

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

@MichMich

This comment has been minimized.

Copy link
Author

commented Jul 2, 2016

Exactly.

@bolsoncerrado

This comment has been minimized.

Copy link

commented Jul 19, 2016

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

This comment has been minimized.

Copy link
Owner

commented Jul 19, 2016

@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

This comment has been minimized.

Copy link
Author

commented Jul 19, 2016

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

@foosel foosel added this to the 1.2.14 milestone Jul 21, 2016

foosel added a commit that referenced this issue Jul 21, 2016

Track consecutive timeouts
Should allow to detect if a device actually has gone missing.

See #1388
@foosel

This comment has been minimized.

Copy link
Owner

commented Jul 28, 2016

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

This comment has been minimized.

Copy link
Owner

commented Jul 28, 2016

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

image

@MichMich

This comment has been minimized.

Copy link
Author

commented Jul 28, 2016

Great, I'll give it a try!

@foosel

This comment has been minimized.

Copy link
Owner

commented Jul 28, 2016

Merged to master and released with 1.2.14.

@foosel foosel closed this Jul 28, 2016

@MichMich

This comment has been minimized.

Copy link
Author

commented Aug 6, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.