Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Print aborts immediately after start #1838
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).
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
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
Link to octoprint.log
[On gist.github.com or pastebin.com. ALWAYS INCLUDE and never truncate.]
Link to contents of terminal tab or serial.log
Screenshot(s) or video(s) showing the problem:
I have read the FAQ.
It appears to be hiccuping hard while reading from your GCODE file here:
That looks like a race condition that was already fixed on the
To quote a6c4f8b:
referenced this issue
Mar 27, 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).
Just had the same or similar error right now, few seconds after upload completed (if it makes any sense):
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