Current released OctoPrint, on a Monoprice Mini Delta (aka M300). Fairly consitently I get a timeout/disconnect when the printing is done. Here's the serial.log output when this happens:
2018-06-23 21:50:30,255 - Send: N6907 M84*39
2018-06-23 21:50:30,259 - Recv: ok N6907 P15 B15
2018-06-23 21:50:30,264 - Send: N6908 G4 S420*95
2018-06-23 21:57:30,240 - Recv: ok N6908 P15 B15
2018-06-23 21:57:30,250 - Send: N6909 M107 S0*80
2018-06-23 21:57:30,255 - Recv: ok N6909 P15 B15
2018-06-23 21:57:30,287 - Changing monitoring state from "Printing" to "Operational"
2018-06-23 22:01:30,455 - No response from printer after 3 consecutive communication timeouts, considering it dead. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
2018-06-23 22:01:30,466 - Changing monitoring state from "Operational" to "Offline (Error: Too many consecutive timeouts, printer still connected and alive?)"
2018-06-23 22:01:30,477 - Connection closed, closing down monitor
This might end up as an Issue but I figure it's worth putting here first.
M18/M84 set the timeout on the stepper motors, not the serial.
Seems pinging for temperature every 5sec should keep it alive, but in the logs you can see it died immediately after going from 'printing' to 'operational'.
@tedder42 Can you provide a full serial.log of a reproduction? I don't see OctoPrint sending any M105 here, but that might be due to the printer claiming it supports temperature auto reporting, in which case OctoPrint won't trigger temperature queries itself but will then consider the printer to be dead if it also doesn't send out any pings.
Check if you have M18 or M84 in your code. Normally after you are done printing M18 or M84 are used to "turn off steppers" so you don't waste energy, stop heating the motors, allow for platform to be hand moved etc.. when you disable steppers lot of EMI happens and the USB can't handle it and your connection is lost. Most crappy electronic boards have issues with this.
Should be easy to test... turn on your printer and your octoprint, go to terminal tab, give it first one M17 to enable steppers... then you can go to control tab, home the printer and move your head around, then go back to terminal tab and shoot one M18 .. you should hear your steppers being "released" and if you lose your connection you found the issue ... if not, repeat the process few times to be sure that's not what's causing the crashes. For example most MKS boards have this problem (every single one I tried), some TearTime boards have this problem..
Sometimes you can solve the issue by using shorter and higher quality usb cable, adding chokes on the cable and shielding the cable with alu tape (grounding only one side of the alu tape), but in most cases the only real solution is replacing the electronic with a proper one... (and of course, for start, avoid M18/M84 codes if you really need that connection not to fail)
Not having trouble with M18. I'm going to hope that moving to 1.3.9 is fixing it, since there are serial fixes in there. Otherwise I'll at least relocate the Pi and cable to minimize RF exposure.
... if not, repeat the process few times to be sure that's not what's causing the crashes. For example most MKS boards have this problem (every single one I tried), some TearTime boards have this problem..