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:
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
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.
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.
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.
