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

Print aborts immediately after start #1838

christianh17 opened this issue Mar 26, 2017 · 5 comments


None yet
3 participants
Copy link

commented Mar 26, 2017

What were you doing?

Yesterday I updated octoprint to the newest version (1.3.2) and today tried to print. The first print went without any problems but since then I always get an error (Serial Communication lost).
Till the update everything worked without any problems.
Edit 20170326 11:17: I just restarted octoprint and now it works. Perhaps it is a problem with the second print? I'll try and give an update.

What did you expect to happen and what happened instead?

It's obvious, I wanted to print but I got an error.

Branch & Commit or Version of OctoPrint

OctoPrint 1.3.2 (master branch)

Operating System running OctoPrint

OctoPi. But I am not sure how to determine the version. /proc/version shows: Linux version 4.4.34+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #930 Wed Nov 23 15:12:30 GMT 2016
and /etc/os-release:
PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION="8 (jessie)"

Printer model & used firmware incl. version

Prusa I3 Chinese clone, Firmware: Marlin rcbugfix from about march, 15th.

Browser and Version of Browser, Operating System running Browser

Firefox 52

Link to octoprint.log

[On or ALWAYS INCLUDE and never truncate.]

Link to contents of terminal tab or serial.log and
first one: Serial.log and second one: terminal

Link to contents of Javascript console in the browser


Screenshot(s) or video(s) showing the problem:


I have read the FAQ.


This comment has been minimized.

Copy link

commented Mar 27, 2017

It appears to be hiccuping hard while reading from your GCODE file here:

2017-03-26 08:50:11,422 - octoprint.util.comm - ERROR - Exception while processing line
Traceback (most recent call last):
  File "/home/pi/oprint/local/lib/python2.7/site-packages/OctoPrint-1.3.2-py2.7.egg/octoprint/util/", line 2679, in getNext
    line = self._handle.readline()
  File "/home/pi/oprint/lib/python2.7/", line 672, in readline
    return self.reader.readline(size)
  File "/home/pi/oprint/lib/python2.7/", line 527, in readline
    data =, firstline=True)
  File "/home/pi/oprint/lib/python2.7/", line 486, in read
    self.charbuffer += newchars
TypeError: unsupported operand type(s) for +=: 'NoneType' and 'unicode'

That looks like a race condition that was already fixed on the maintenance branch. If that is indeed the same issue (the stack trace looks very much like it), that problem should be fixed in 1.3.3

To quote a6c4f8b:

When the sending of the first line of a file to print is still taking place while an "ok" from the firmware comes in, it's possible that two threads will try to access the file handle in parallel. That can lead to trouble within Python's codecs module.


This comment has been minimized.

Copy link

commented Mar 27, 2017

Hi! Thanks a lot. In the meantime I tried to reproduce the error but of course it did not happen again. I will wait for the next update. If it happens only while the print starts nothing serious will hapen and I can wait. Regards, Christian


This comment has been minimized.

Copy link

commented Mar 28, 2017

As far as I understand the issue (it's been impossible to reproduce intentionally so far, and I only even noticed it because @Booli ran into it and reported it on IRC) it should only be possible to happen on start of a print, because that's the only point in time where concurrent access to the file handle should be possible. But take that with a grain of salt because I haven't been able to reproduce it so I'm only going on code understanding here. In any case, it's a very rare problem - otherwise we'd probably seen this way earlier too, that code has been in there for a while. If it turns out to show up way more frequently I'll see into increasing prio to push out 1.3.3, but right now I'd not consider this a high prio issue that needs immediate hotfixing (with associated release overhead).


This comment has been minimized.

Copy link

commented Mar 31, 2017

Just had the same or similar error right now, few seconds after upload completed (if it makes any sense):

"Send: M105
Recv: ok T:16.9 /0.0 B:16.2 /0.0 T0:16.9 /0.0 @:0 B@:0
Send: M105
Changing monitoring state from 'Operational' to 'Printing'
Recv: ok T:16.9 /0.0 B:16.2 /0.0 T0:16.9 /0.0 @:0 B@:0
Send: N0 M110 N0125
Recv: ok
Send: N1 G90
Recv: ok
See octoprint.log for details
Changing monitoring state from 'Printing' to 'Error: TypeError: 'unsupported operand type(s) for +=: 'NoneType' and 'unicode'' @'
Changing monitoring state from 'Error: TypeError: 'unsupported operand type(s) for +=: 'NoneType' and 'unicode'' @' to 'Offline: TypeError: 'unsupported operand type(s) for +=: 'NoneType' and 'unicode'' @'
Connection closed, closing down monitor"

Perhaps something to do with the parser/stabilizer for the Gcode analysis?

Anyhow if this is fixed in 1.3.3, let it happen :P


This comment has been minimized.

Copy link

commented May 31, 2017

1.3.3 was just released.

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.