Serial communication with Printer not reliable

Octoprint can not connect to the Printer (sometimes after restarting Octoprint it works)
Funny thing is, even if Octoprint cant connect, avrdude has no Problem flashing the firmware.

Printer is working fully via LCD or if i connect via Pronterface.

What did you already try to solve it?

Complete Format of the SD Card, reinstall all Plugins and tried 1.4.x, 1.5.1
I also tried to fiddle around with the serial settings in the web gui.
Tried to lower the Speed of the USB Port in Firmware to 115200 and in Octorpint Gui.
Changed the USB Cable, used a different Power Supply for the Raspi. Same result.

Connecting via Notebook and Pronterface does work flawless.

Have you tried running in safe mode and if so did it solve the issue?

2020-12-09 21:44:41,112 - octoprint.startup - INFO - ******************************************************************************
2020-12-09 21:44:41,117 - octoprint.startup - INFO - Starting OctoPrint 1.5.1
2020-12-09 21:44:41,118 - octoprint.startup - INFO - Starting in SAFE MODE. Third party plugins will be disabled!
2020-12-09 21:44:41,120 - octoprint.startup - INFO - Reason for safe mode: setting in config.yaml
2020-12-09 21:44:41,122 - octoprint.startup - INFO - ******************************************************************************

Nope, did not solve it.

Complete Logs

octoprint.log, serial.log or output on terminal tab at a minimum, browser error console if UI issue ... no logs, no support! Not log excerpts, complete logs.)

Changing monitoring state from "Offline" to "Opening serial connection"
Connecting to port /dev/ttyUSB0, baudrate 250000
Changing monitoring state from "Opening serial connection" to "Connecting"
Connected to: Serial<id=0x6e4e9430, open=True>(port='/dev/ttyUSB0', baudrate=250000, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Recv: start
Send: N0 M110 N0*125
Recv: Marlin bugfix-2.0.x
Recv:
Recv: echo: Last Updated: 2020-12-09 | Author: (Stefan Held, default config)
Recv: echo:Compiled: Dec 9 2020
Recv: echo: Free Memory: 2964 PlannerBufferBytes: 1200
Recv: Unified Bed Leveling System v1.01 active
Recv:
Recv: Unified Bed Levelingok
There was a timeout while trying to connect to the printer
Changing monitoring state from "Connecting" to "Offline"
Connection closed, closing down monitor

Additional information about your setup

OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible

I have a MKS GenL v1.0 Board with marlin-bugfix-2.0 (pulled today and compiled today).

OctoPrint version : 1.5.1
OctoPi version : 0.17.0
Hardware : BCM2835
Revision : a02082
Serial : 00000000f8782aff
Model : Raspberry Pi 3 Model B Rev 1.2

Browser. Whatever, i tried Firefox, Chrome, Edge (Chromium) on Win10, also Chrome + Firefox + Safai on MacOS 11.0, Safari on iPad, Chrome and Firefox on Linux.

Firmware bug right there, that ok should be on its own line. It isn't, this the handshake can never completed, this the connection attempt times out. Needs to be fixed in the printer's firmware, or someone could write a plugin. Firmware fix would be the clean way though.

1 Like

Oh wow, thx for the ultra fast respone, i have a look at recent marlin commits. And will try to fix it.

For anyone else:

diff --git a/Marlin/src/feature/bedlevel/ubl/ubl.cpp b/Marlin/src/feature/bedlevel/ubl/ubl.cpp
index 087fdf42b2..82ce79e025 100644
--- a/Marlin/src/feature/bedlevel/ubl/ubl.cpp
+++ b/Marlin/src/feature/bedlevel/ubl/ubl.cpp
@@ -43,7 +43,7 @@
#include "math.h"

void unified_bed_leveling::echo_name() {
- SERIAL_ECHOPGM("Unified Bed Leveling");
+ SERIAL_ECHOPGM("Unified Bed Leveling\n");
}

void unified_bed_leveling::report_current_mesh() {

I will open a Ticket on Marlin github, @foosel after applying the patch, everything works again.

Thx :slight_smile:

3 Likes

This is not the correct answer.
Yes there is a bug in Marlin bugfix, but it is not the above.
See https://github.com/MarlinFirmware/Marlin/issues/20417 for details.
Issue is in some debugging that was incorrectly always enabled.