Issue title: Communication error
 Issue body: #### What were you doing?
Start the print as normal, then aft first layer it just stops and the text comes up:
Unhandled communication error
There was an unhandled error while talking to the printer. Due to that OctoPrint disconnected. Error: Too many consecutive timeouts, printer still connected and alive?

#### What did you expect to happen?
A finnished print

#### What happened instead?
Just stopped

#### Branch & Commit or Version of OctoPrint
Version: 1.2.18 (master branch)

#### Printer model & used firmware incl. version
Craftbot+ 1.1.9657/3

#### Browser and Version of Browser, Operating System running Browser
Google Chrome Version 54.0.2840.99 m (64-bit)

#### Link to octoprint.log
[octoprint.txt1.txt](https://github.com/foosel/OctoPrint/files/627315/octoprint.txt1.txt)

#### Link to contents of terminal tab or serial.log
[OctoPrint1.txt](https://github.com/foosel/OctoPrint/files/627441/OctoPrint1.txt)


#### Link to contents of Javascript console in the browser
Dont know how to add that link


#### Screenshot(s) showing the problem:
![octoprint](https://cloud.githubusercontent.com/assets/18622410/20838296/3ad2414a-b8a8-11e6-99c3-e42f52b0ceca.png)



 Comments: 
 Comment 0: Hi @Jpson67,

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](https://github.com/foosel/OctoPrint/blob/master/CONTRIBUTING.md) 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](https://github.com/foosel/OctoPrint/blob/master/CONTRIBUTING.md).

**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](https://groups.google.com/group/octoprint) or the [G+ Community](https://plus.google.com/communities/102771308349328485741) 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](https://github.com/foosel/OctoPrint/wiki/FAQ)** and searched the [**existing tickets**](https://github.com/foosel/OctoPrint/search?q=&ref=cmdform&type=Issues) 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 2016-12-16 11:00 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.

 Comment 1: > collect all requested information **(don't forget the terminal)**, 

^-- quoted from your initial ticket #1595. Something apparently goes wrong between your printer and OctoPrint. Without being able to *see* what they are talking about (NOT only the error but what goes *before* this), how is anyone supposed to analyse this? 

FULL ticket. 

Please. 

Including the FULL terminal output and your `octoprint.log` (no, what you provided there is NOT the requested log, the requested log can be found under Settings > Logs and definitely not a truncated version of your terminal output). Do not truncate anything, you are making it impossible for anyone to help you here.
 Comment 2: Seems to be the same problem as #1603, to me.
 Comment 3: Going by this excerpt from the terminal output which was finally provided apparently:

```
Send: N1328 G21*34
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: N1329 M105*30
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: N1330 M105*22
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: N1331 M105*23
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: N1332 M105*20
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: N1333 M105*21
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
```

The printer basically goes AWOL and refuses to respond entirely to anything sent to it. So either the firmware crashed, or something else happened with the printer, but this is nothing that can be solved by OctoPrint. You need to figure out why your printer stops responding. I've seen issues like this with overheating controllers, so maybe check that. But unless your printer/your printer's firmware keeps on replying to messages sent by OctoPrint, printing via serial will be impossible (with any host for that matter).

@skorokithakis doesn't look like #1603, it's not the serial port that's actually breaking off (which would indicate a possible power issue) but instead it's the printer simply stopping to reply. Which of course makes it impossible to tell it to print. After a while OctoPrint simply gives up and throws an error to tell the user "Look, something's seriously broken with your printer here".
 Comment 4: ?

/Jimmy
> 5 dec. 2016 kl. 13:58 skrev Gina Häußge <rodriguezpatrick@example.com>:
> 
> Closed #1615 <https://github.com/foosel/OctoPrint/issues/1615>.
> 
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub <https://github.com/foosel/OctoPrint/issues/1615#event-881996765>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARwnyoiCo3PlIALhZnIXK9fcifUc_MB0ks5rFAqJgaJpZM4LCbb2>.
> 


 Comment 5: Dont get this error when the printer its hooked up direct to computer
 Comment 6: > Dont get this error when the printer its hooked up direct to computer

Aha. And I'm supposed to know this how? Also, hooked up how? Same USB cable, other cable? And through what software? You realize you haven't been very forthcoming with information so far, right? 

If it's not working with the Pi *with the same printed GCODE file and USB cable* but it's working fine with a regular PC *with the same printed GCODE file and USB cable*, @skorokithakis might be right after all and this is in fact another manifestation of a brown-out issue due to some weird power issues of the Pi. Or it might be something else, but we won't be able to figure this out unless you are a bit more forthcoming with regards to the exact steps to reproduce this issue.

So... let's start from the beginning. Explain in full sentences and with as much detail as possible when it happens, when it doesn't happen, if there's any pattern with it happening, how often it does happen, etc. Basically: tell us everything you know about that issue. It is not possible to debug this without your collaboration. And also: try printing a file that failed on the Pi in the past with the same USB cable you used on the Pi from something like Pronterface from your PC. Report back how that goes.
 Comment 7: 
Why are you fucking rude in your response? All are not experts, join a charm course.


> 5 dec. 2016 kl. 14:28 skrev Gina Häußge <rodriguezpatrick@example.com>:
> 
> Reopened #1615 <https://github.com/foosel/OctoPrint/issues/1615>.
> 
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub <https://github.com/foosel/OctoPrint/issues/1615#event-882030936>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARwnyuu6UiHpQFIuKPRlqeZmvE1x8A6mks5rFBFggaJpZM4LCbb2>.
> 


 Comment 8: @Jpson67 Thanks for the serial logs, that's helpful.  I understand that we're not all experts here, but take it from an expert, issues like these are hard to diagnose precisely even when a lot of information is available.  And when little information is provided it gets frustrating for everyone.

The serial log does show that OctoPrint is still operating normally, but getting no response from the printer on the serial line. This makes it unlikely that it is actually the OctoPrint software causing the problem (though it could possibly be a problem with the serial over USB driver or the python serial module under certain circumstances, but if so, it'll be really hard to track down unless some developer can get a reproducible problem).

However, experience with these slow serial over USB connections show that it is really sensitive to environmental issues. Many users in the past have been able to significantly improve reliability by changing some things relating to power and electrical noise.

Since you have success with the same USB cable connected to your PC, perhaps the USB cable is good.  However, I'd be interested to know what software you use to send the job on that PC.  Perhaps that software has longer time-outs and more retries and recovers from this.  It could also be that the USB cable is in a different position when connected to the Pi and is getting more noise from the stepper motors.  You may still want to try a shorter/thicker USB cable.

My current best guestimate is that the Pi is having a slight power issue that is causing a communication problem. It could be the power supply isn't maintaining the voltage precisely under load (is it a Pi 3?  One of my supposedly in-spec power supplies I got for a Pi had too much resistance in its cord, so the delivered voltage was only correct most of the time.  You may want to try a different wall wart (On a Pi3, I'd recommend 2.5A and something with a relatively beefy, short cable.)
 Comment 9: For the record, I had the same problem and it was solved when I upgraded to the official Pi power supply (phone/tablet chargers didn't work properly).
 Comment 10: Since apparently some of the required information is still missing, I'm closing this now, sorry. Feel free to request a reopen of this or create a new issue once you can provide **all** [required information](https://github.com/foosel/OctoPrint/blob/master/CONTRIBUTING.md#how-to-file-a-bug-report).
This is nothing personal. Thank you for your collaboration.

{'source': 'GithubIssues', 'repo_name_with_owner': 'OctoPrint/OctoPrint', 'issue_id': 193087875, 'repo_stars': 6992.0}