What is the problem?
Octoprint keeps giving me errors in the middle of printing. I keep getting (Error: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:2793. This only started after I switch to the new board.
What did you already try to solve it?
I have read the FAQ on the SerialException and have tried everything from it. I have tried to change the baudrate. Also removed my tft 24 completely. I will include my firmware config maybe I am missing something.
@foosel Noting this for you (probably unrelated to their problem, though)
2020-02-27 21:28:20,860 - octoprint.startup - INFO - Starting OctoPrint 1.3.12
| model: Raspberry Pi 4 Model B Rev 1.1
| octopi_version: 0.17.0
2020-02-28 13:21:43,701 - octoprint.plugins.pluginmanager - INFO - Looks like we are offline, can't fetch notices from network
2020-02-28 13:22:02,143 - octoprint.plugins.announcements - INFO - Looks like we are offline, can't fetch announcements for channel _octopi from network
2020-02-28 13:22:02,154 - octoprint.server.api - ERROR - Error calling SimpleApiPlugin pluginmanager
Traceback (most recent call last):
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/server/api/__init__.py", line 68, in pluginData
response = api_plugin.on_api_get(request)
File "/home/pi/oprint/lib/python2.7/site-packages/octoprint/plugins/pluginmanager/__init__.py", line 284, in on_api_get
if refresh_notices or not self._is_notices_cache_valid():
File "/home/pi/oprint/lib/python2.7/site-packages/octoprint/plugins/pluginmanager/__init__.py", line 865, in _is_notices_cache_valid
return mtime + self._notices_cache_ttl >= time.time() > mtime
TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'
I don't see Loaded notice data from disk, was still valid from the log anywhere. I also don't see Error while loading notices from in the log. My gut is telling me that _notices_mtime isn't getting set at some point somehow.
Search the serial log for 2020-02-28 13:56:26 and then start looking at the temperature of the hotend from that point, on. It's starting to fall from the target temperature without a correction. The same slight lowering appears to be happening on the bed temperature. It eventually ends with several preventions of cold extrusion followed by OctoPrint thinking that things were taking too long.
So maybe the firmware was trying to correct the temperature fall-off, didn't respond to OctoPrint during that in a way that OctoPrint liked and so OctoPrint stopped communications. But the underlying problem was likely that something upstream wasn't delivering power to the heaters.
The connection failed only because M20 command is sent.
So I unticked "sd support" on ocotoprint properties and connection works.
(Marlin 2.X skr 1.4 turbo)
THe connection probably fails then because something is wrong with the SD card currently in the printer. If you'd share a serial.log (which you need to enable first!) from when it doesn't connect it would be possible to verify that.
I suggest to remove the card from the printer, reenable SD support and then see if the issue vanishes. If so swap the SD card, something's wrong with it. Wouldn't be the first time that a corrupt SD card in the printer causes connection issues or even printer crashes.
i already read the serial file and haven't found something interesting.
It's seems the octoprint read the sd card ( i have the list of .gcode file ) and 3 seconds later BOOM disconnect