Octoprint fails to connect to printer. Timeout error

What is the problem?
When I attempt to connect to my printer it begins connecting and then runs into a timeout error. This may be a lack of "ok" response to M110 after reading other topics, but unsure how to solve this...

I previously had octoprint set up with no issues. After building a second printer I followed a YouTube guide and have set up both printers on the same pi. After set up had no problems and could connect to both printers. I have since made a single change (z probe offset) to Marlin and re-uploaded my original printer's firmware. After powering everything up today I can no longer connect to my original printer. I have no issue connecting to the new printer, just the original that worked fine yesterday and on previous set up.

When I attempt to connect the Terminal shows the following:

Connecting to: /dev/BBCUBE
Changing monitoring state from "Offline" to "Opening serial port"
Connected to: Serial<id=0x69cbb390, open=True>(port='/dev/BBCUBE', baudrate=250000, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Changing monitoring state from "Opening serial port" to "Connecting"
Send: N0 M110 N0*125
Recv: �tart
Recv: echo:Marlin 1.1.9
Recv:
Recv: echo: Last Updated: 2018-08-01 | Author: (none, default config)
Recv: echo:Compiled: Sep 20 2019
Recv: echo: Free Memory: 4404 PlannerBufferBytes: 1232
Recv: echo:Hardcoded Default Settings Loaded
Recv: echo: G21 ; (mm)
Recv: echo: M149 C ; Units in Celsius
Recv:
Recv: echo:Filament settings: Disabled
Recv: echo: M200 D1.75
Recv: echo: M200 D0
Recv: echo:Steps per unit:
Recv: echo: M92 X80.00 Y80.00 Z400.00 E805.00
Recv: echo:Maximum feedrates (units/s):
Recv: echo: M203 X300.00 Y300.00 Z5.00 E25.00
Recv: echo:Maximum Acceleration (units/s2):
Recv: echo: M201 X3000 Y3000 Z100 E10000
Recv: echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
Recv: echo: M204 P2000.00 R10000.00 T2000.00
Recv: echo:Advanced: Q<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> X<max_x_jerk> Y<max_y_jerk> Z<max_z_jerk> E<max_e_jerk>
Recv: echo: M205 Q20000 S0.00 T0.00 X10.00 Y10.00 Z0.30 E5.00
Recv: echo:Home offset:
Recv: echo: M206 X0.00 Y0.00 Z0.00
Recv: echo:Auto Bed Leveling:
Recv: echo: M420 S0 Z0.00
Recv: echo:Material heatup parameters:
Recv: echo: M145 S0 H200 B45 F0
Recv: echo: M145 S1 H235 B70 F0
Recv: echo:PID settings:
Recv: echo: M301 P22.75 I1.83 D70.83
Recv: echo: M304 P116.17 I8.98 D375.89
Recv: echo:Z-Probe Offset (mm):
Recv: echo: M851 Z0.00
Recv: echo:Stepper driver current:
Recv: echo: M906 X850 Y850 Z800
Recv: M906 T0 E800
Recv:
Recv: echo:Hybrid Threshold:
Recv: echo: M913 X100 Y100 Z3
Recv: M913 T0 E30
Recv:
Recv: echo:Sensorless homing threshold:
Recv: echo: M914 X10 Y10
There was a timeout while trying to connect to the printer
Changing monitoring state from "Connecting" to "Offline"
Connection closed, closing down monitor

I get no error message under state, it simply changes from "Connecting" to "Offline"

I can connect to the printer via Pronterface, just not through OctoPrint.

What did you already try to solve it?

  • Rebooting both printer and pi
  • Downloaded a new version of Marlin 1.1.9, manually changed configuration and re-uploaded
  • Tried Auto baudrate settings
  • Using different USB ports on pi
  • Disconnecting new printer and webcam

octoprint (1).log (74.8 KB)
serial.log (1.4 KB)

Additional information about your setup
OctoPrint version 1.3.11
OctoPi version 0.16.0
I have the official pi power supply providing 5V 2.5A
Printer: Custom build using Arduino Mega 2560 and Ramps shield
Browser: Chrome
OS: Windows 10

Link to YouTube tutorial if useful:

Hi @BB_CUBE!

You should activate your serial log as it is written in the log you sent:

2019-09-20 19:38:23,789 - serial.log is currently not enabled, you can enable it via Settings > Serial Connection > Log communication to serial.log
2019-09-20 19:44:19,843 - serial.log is currently not enabled, you can enable it via Settings > Serial Connection > Log communication to serial.log
2019-09-20 20:01:04,017 - serial.log is currently not enabled, you can enable it via Settings > Serial Connection > Log communication to serial.log
2019-09-20 20:46:21,348 - serial.log is currently not enabled, you can enable it via Settings > Serial Connection > Log communication to serial.log
2019-09-20 20:47:56,206 - serial.log is currently not enabled, you can enable it via Settings > Serial Connection > Log communication to serial.log
2019-09-20 20:47:58,539 - serial.log is currently not enabled, you can enable it via Settings > Serial Connection > Log communication to serial.log
2019-09-20 20:51:02,973 - serial.log is currently not enabled, you can enable it via Settings > Serial Connection > Log communication to serial.log
2019-09-20 21:05:49,434 - serial.log is currently not enabled, you can enable it via Settings > Serial Connection > Log communication to serial.log
2019-09-20 22:11:11,877 - serial.log is currently not enabled, you can enable it via Settings > Serial Connection > Log communication to serial.log
2019-09-20 22:14:09,277 - serial.log is currently not enabled, you can enable it via Settings > Serial Connection > Log communication to serial.log

The octoprint.log gives a hint:
9-09-20 19:28:04,719 - octoprint.util.comm - ERROR - Please see https://faq.octoprint.org/serialerror for possible reasons of this.

The firmware sends garbage. That should say start. You could try disabling "wait for start on connect" in the serial settings.

I think I would test things at 115200 to see if the problem goes away. It could be something as simple as the serial cable.

I've tried disabling "wait for start on connect" and still have the same issue.

I had seen that myself and wondered if it was the issue. Any idea why the firmware sends this? It's a completely new version of Marlin 1.1.9 I'm running.

Sadly different baudrates doesn't solve the issue and often just results in garbage sent back from printer. I've tried swapping USB cable to see if that was the issue, using the one that worked from my PC to connect to Pronterface, but no luck...

It may be necessary to (temporarily) reconfigure and flash your Marlin so that the baudrate is 115200. If that works then you know that you're looking at a serial-related problem. In other words, if something works great at a slower baudrate then either stay at the lower baudrate or fix whatever is wrong with the (unshielded) cabling, add a ferrite core, change the power adapter or something else.

So, going into Marlin and changing the Baudrate to 115200 solved the issue!

I'm not sure what's causing it to be unable to connect at 250000 when it's the exact same setup and cabling as before, which worked at 250000...

Provided I don't run into any other issues as a result of the lower baudrate I'll probably just leave it as it is for now.

Thanks for the help everyone! :smiley:

Long ago when the Earth was cooling and dinosaurs still roamed the lanscape, I used to fix Teletypewriters and we had this test bench where we could inject noise into the serial line. The typical baudrate was 42 or 75 in those days (something screamingly fast). You'd upgrade the baudrate by switching out a gear assembly with a different ratio to it from the motor.

If you could see all this on an oscilloscope it would make more sense to you. It's like when your car mechanic puts the signals to your spark plugs on an oscilloscope, takes one look at it and says "aha..." to acknowledge an understanding of things based upon the shapes of the signals.

  • Longer serial cables add more resistance so the signal won't be as tall when it gets to the other side. In some cases a "1" will be slightly less than some magic threshold and be seen instead as a "0".
  • Wires in parallel pick up signals from other parallel-oriented wires. Twisting each pair tends to lower these induced signals.
  • Unshielded serial cables may have other noise induced into them, say, from those driver circuit daughterboards on your printer's board. The noise can affect a signal bit and create a bogus character. Use a cable with an internal metallic shield.
  • Lowering the baudrate by a factor of two stretches everything out. So a tiny blip of noise doesn't so much affect the entire bit itself.
  • A ferrite core around the serial cable helps to filter out high-frequency noise (like what you'd get from a spark gap or one of these fast-changing driver daughterboards, say).
  • Each connection forms a small amount of capacitance which itself acts as a filter for low-frequency signals. Try to avoid unnecessary adapters on the serial line.