[Solved] Communication with printer times out over USB


#1

What is the problem?
Two days ago I printed some parts without any issue. The next day I started the printer to continue and OctoPrint stopped connecting to it. Haven't made any updates to OctoPrint, plugins or printer firmware in between.

Solved while gathering information for this post but will post anyway as it might help other users in the future.

Solution:
Found a message in octoprint.log stating "No such file or directory: '/dev/ttyACM0'" so I set serial port and baud rate to auto and it connected to the printer again.
Very odd considering it worked with manually configured serial port and baud rate until now.

What did you already try to solve it?

  • Reboot everything several times, including cold boot
  • Set serial baud rate to 250000 then back to 115200
  • Reboot to safe mode to exclude any malfunctioning plugins
  • Reflash printer firmware via OctoPrint - failed with timeout
  • Recompiled and reflashed printer firmware via PC - worked
  • Connected to Pronterface to test printer communication - worked, connected almost instantly and was able to control the printer
  • Google
  • Similar topics here
  • Set serial port and baud rate to auto - worked

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, octoprint.log, serial.log or output on terminal tab, ...)

  • OctoPrint version is 1.3.10 (stable), running on a RPi 3
  • Printer is Prusa MK3 with custom firmware based on Prusa 3.5.0 (only mod is LCD library to support OLED display)
  • serial.log (after this is repeats trying to connect):
2019-01-27 15:48:50,829 - Connecting to: /dev/ttyACM0
2019-01-27 15:48:50,851 - Changing monitoring state from "Offline" to "Opening serial port"
2019-01-27 15:48:50,858 - Connected to: Serial<id=0x6e677f10, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
2019-01-27 15:48:50,862 - Changing monitoring state from "Opening serial port" to "Connecting"
2019-01-27 15:48:50,894 - Send: N0 M110 N0*125
2019-01-27 15:48:52,074 - Recv: echo: 3.5.0-1749
2019-01-27 15:48:52,084 - Recv: echo: Last Updated: Jan 26 2019 11:21:45 | Author: (none, default config)<a class="attachment" href="/uploads/default/original/2X/d/dc3326e17f29f80071532fbe4ada145e36bc075a.log">serial.log</a> (6.1 KB)
 
2019-01-27 15:48:52,088 - Recv: Compiled: Jan 26 2019
2019-01-27 15:48:52,093 - Recv: echo: Free Memory: 2084  PlannerBufferBytes: 1392
2019-01-27 15:48:52,097 - Recv: echo:Hardcoded Default Settings Loaded
2019-01-27 15:48:52,100 - Recv: adc_init
2019-01-27 15:48:52,433 - Recv: CrashDetect ENABLED!
2019-01-27 15:48:52,782 - Recv: PAT9125_RES_X=0
2019-01-27 15:48:52,787 - Recv: PAT9125_RES_Y=240
2019-01-27 15:48:52,790 - Recv: PAT9125_init:1
2019-01-27 15:48:52,794 - Recv: FSensor DISABLED
2019-01-27 15:48:52,798 - Recv: 
2019-01-27 15:48:53,055 - Recv: echo:SD card ok
2019-01-27 15:48:53,994 - Recv: echo:busy: processing
2019-01-27 15:48:53,998 - Printer seems to support the busy protocol, will adjust timeouts and set busy interval accordingly
2019-01-27 15:49:21,799 - Recv: MMU not responding - DISABLED
2019-01-27 15:49:51,840 - There was a timeout while trying to connect to the printer
2019-01-27 15:49:51,852 - Changing monitoring state from "Connecting" to "Offline"
2019-01-27 15:49:51,867 - Connection closed, closing down monitor
  • octoprint.log:
2019-01-26 22:26:45,059 - octoprint.util.comm - ERROR - Unexpected error while connecting to serial port: /dev/ttyACM0 SerialException: '[Errno 2] could not open port /dev/ttyACM0: [Errno 2] No such file or directory: '/dev/ttyACM0'' @ comm.py:_openSerial:2478 (hook default)

#2

You might try ejecting the SD card from your printer's controller board and see if this helps. Perhaps it was at the point of trying to read the SD card contents and that took too long...?


#3

Thanks for the reply, I hadn't considered that while investigating. However, the problem was that OctoPrint couldn't find the selected serial port for some reason. The solution is in the OP.