I recently upgraded from an original Raspberry Pi model B (the 256MB or RAM 1st run version) to a spiffy new 3 B+. I initially installed the 0.15 beta and today I flashed a fresh 0.15 install. Both with the beta and the final version of .15 I've been getting this at the end of every print:
"There was a communication error while talking to your printer. Please consult the terminal output and octoprint.log for details. Error: Too many consecutive timeouts, printer still connected and alive?"
There have been no changes to the slicer I'm using (Simplify3D) nor the printer. Is this something to do with the 3 B+?
This is the only thing I see in octoprint.log:
2018-05-05 19:14:56,383 - octoprint.util.comm - INFO - Changing monitoring state from "Operational" to "Printing"
2018-05-05 19:14:56,403 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2018-05-05 19:28:36,691 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2018-05-05 19:43:36,696 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2018-05-05 19:58:36,698 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2018-05-05 20:13:36,700 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2018-05-05 20:22:00,261 - octoprint.util.comm - INFO - Finished in 4023.879 s.
2018-05-05 20:22:00,284 - octoprint.util.comm - INFO - Changing monitoring state from "Printing" to "Operational"
2018-05-05 20:22:00,290 - octoprint.filemanager.analysis - INFO - Starting analysis of local:rocktopus.gcode
2018-05-05 20:22:00,295 - octoprint.filemanager.analysis - INFO - Invoking analysis command: /home/pi/oprint/bin/python2 -m octoprint analysis gcode --speed-x=9000 --speed-y=9000 --max-t=10 --throttle=0.0 --throttle-lines=100 /home/pi/.octoprint/uploads/rocktopus.gcode
2018-05-05 20:22:22,206 - octoprint.filemanager.analysis - INFO - Analysis of entry local:rocktopus.gcode finished, needed 21.92s
2018-05-05 20:24:00,352 - octoprint.util.comm - INFO - No response from printer after 3 consecutive communication timeouts, considering it dead.
2018-05-05 20:24:00,364 - octoprint.util.comm - INFO - Changing monitoring state from "Operational" to "Offline (Error: Too many consecutive timeouts, printer still connected and alive?)"
I couldn't tell you if this is an OctoPi version thing but I do know that the USB Type B cable between the Raspi and the RAMPS board either needs to be super short in length or it needs a ferrite core around it.
Untwisted cables are AM antennas, by definition, and will both transmit and receive signals. The longer the cable, the more receptive it is to induced signals into it (assuming that you don't use a ferrite filter as described). If you've ever been in an old car and you could hear sounds on your AM radio when you pressed on the accelerator, this is the same thing.
I do know that this interference can be enough to negatively affect OctoPrint's ability to connect and to stay connected to the RAMPS board.
I've had no issue with the same cables on the older RaspberryPi running 0.14
I should also have mentioned the printer is a MP Select Mini V2 (Malyan M200) with the connectivity fix plugin installed.
Perhaps @foosel can shed some light on this if it's not the USB cable.
Not without a serial.log since it's an issue in the communication with the printer.
disconnect.log (59.3 KB)
See the last 1000 lines of the serial log with the disconnect shown.
This G4 there:
2018-07-08 03:19:44,509 - Send: N210707 G4 P300000*109
2018-07-08 03:24:44,496 - Recv: ok N210707 P15 B15
2018-07-08 03:24:44,500 - Send: N210708 M106 S1*90
2018-07-08 03:24:44,506 - Recv: ok N210708 P15 B15
2018-07-08 03:24:44,525 - Changing monitoring state from "Printing" to "Operational"
2018-07-08 03:26:44,617 - 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-07-08 03:26:44,623 - Changing monitoring state from "Operational" to "Offline (Error: Too many consecutive timeouts, printer still connected and alive?)"
2018-07-08 03:26:44,632 - Connection closed, closing down monitor
2018-07-08 15:57:49,123 - Disabling serial logging
tells your printer's firmware to block and do nothing for 300s = 5min. I guess this is part of some cool down procedure? It's most likely the fault of this issue since for some reason your printer seems to ignore it (it happily continues to respond) and severely confuses OctoPrint by that.
I'd get rid of this command - holding up every print for five minutes isn't the right way to get things to cool or whatever, this should be solved in the firmware by leaving fans switched on as long as the nozzle is above a certain threshold value, not managed by the client code. I know that some vendors recommend end code like this for their printers, but that's simply because they either didn't know how to or didn't care about doing this the proper way.
Rather look into flashing a firmware that takes care of whatever this command is supposed to accomplish on its own. Blocking the serial host for minutes certainly will always cause issues, not necessarily this weird timeout situation (which I'll have to dig into) but rather no temperature reporting taking place, no control being possible anymore and so on and so on.
Wow, the official scripts on their site suggest G4 360. See "Ending G-code with fan off after 6 minutes" and "Turn fan off after print is completed" and even...
"If the fan remains on after a print is completed try increasing G4 S360 to G4 S420."
@foosel Would you like me to talk to them about the effect of this in OctoPrint?
Feel free. It's not OctoPrint only either. The whole printer becomes unresponsive on serial while a dwell is active to any host connected via serial. Intentionally locking up printer communications for several minutes is just - sorry - idiotic and vendors recommending this are - in my eyes - either too lazy or too incompetent to solve their cooling issues properly.
Backing up from all this for a moment, it strikes me that you have a wealth of awareness in your head regarding the available printers out there.
If you did an annual or quarterly review of the top five printers or whatever, you'd be able to tell consumers what sort of underlying quality you're seeing. I think everyone respects you in this space so your review would carry some weight. And if the manufacturers then realize that this is a recurring review, this would give them some incentive to get their act together. Just a thought.