Print hang & "Full RX Buffer"

What is the problem?
Sometimes prints via octoprint just pauses mid print or in worst case aborts with communication timeout.
The problem i see usually starts out small with a micro pause or two in the print, this usually mean soon the print will fail completely with timeout.

octoprint instance is NOT running on a rasperry pi so bad usb ports i think is not the case here.
It is running in a docker instance on my xeon server.

I was running octoprint on a rasperry pi at first but got tired of all the usb printing stability problems so changed to a real linux server instead with the hope of things working better.

What did you already try to solve it?
posting here for help?

Logs (octoprint.log, serial.log or output on terminal tab, ...)
last time this happen i was trying to print an ecor tower and it stopped with this in the log:

Recv: ok
Send: N2310 G1 E-0.04000 F2100.00000*1
Recv: ok
Recv: ok
Send: N2311 G1 Z18.400 F10200.000*59
Send: N2312 G4 S0*92
Send: N2313 G1 Z18.000 F10200.000*61
Recv: Full RX Buffer
No response from printer after 6 consecutive communication timeouts, considering it dead. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Changing monitoring state from "Printing" to "Offline (Error: Too many consecutive timeouts, printer still connected and alive?)"
Connection closed, closing down monitor

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, ...)
Prusa I3 MK3S with firmware 3.7.1
Octoprint v1.3.11

Actually all of the stability issues with octoprint is a deal breaker and if that cant be resolved i will have to get rid of it.
Also unfortunately SD card printing and/or uploading of gcode files to sd card via octoprint is also not an option due to the stone-age 8.3 filenames.

The receive buffer is on the firmware side, to be honest. Most people who get a full receive buffer flash an updated version of the firmware to their printer's RAMPS board.

You moved this from a Raspberry to a Linux box and you still have the problem. So you might rule out the PC/host side of this as the problem. And btw, Raspbian is a real flavor of Linux since it's Debian.

any idea what the default buffer size is in the stock prusa firmware?

yes and that's why i moved it.

with printer connected to my raspberrypi i had all kinds of stability problems in the communication, mostly the pi failed with something similar to "unable to set dtr" in dmesg and then only way of fixing it was to completely power off the pi (shutdown and remove power) and printer.
putting a usb hub between pi and printer appeared to help a lot but it did not fix all the problems.

i figured if i move it then i can exclude power and crappy usb interface on the pi.

True, but i was mostly thinking of the server hardware itself and not the distribution.

i can't be the only one running in to serial communication issues but i suspect many might get stuck with pi problems.

I wouldn't know what ships with the Prusa but there are others on here who have that one.

I was a contractor for Robo 3D and they shipped out half a million printers in 2017 and a full million in 2018. Every single one of those had a Raspberry Pi 3B in it and used OctoPrint.

The 3B is a great little computer. It has four cores and the Raspbian operating system works quite well. At 1GB of memory it's usually enough to do OctoPrint without any problems.

The weak link is often:

  1. the serial cable needs to be short, internally-shield or include a ferrite core

  2. the power adapter for the Raspi (needs to be 5V @ 2.5A and it's best to plug this into a UPS). In some cases, the microUSB connector on the Pi was a little loose, leading to intermittent power.

  3. these darned 8-bit controller boards and especially Delta-styled printers with all those extra calculations

    The Pi Zero with one core and 512MB RAM just isn't up to the challenge
    in my humble opinion and certainly not soldered on as recommended by Prusa.

Read that link I provided earlier. That's an entire thread of people who were complaining about the "stuttering effect". A number of solutions were suggested. One strategy which I promoted was to simply adjust the firmware so that it had an adequate receive buffer. Another strategy promoted by others was to change the slicer's options so that circular paths didn't have so many tiny segments in them.

usb cable i use is the one that came with the printer from prusa, it seems to be of good quality thick cable with what i believe is a ferrite core (larger cylindrical area on the cable)

but what is interesting is that i got same issue now for the first time as i had on the pi but this time on my real server.
same behavior but with one exception.

when it is in the failed state, trying to reconnect via octoprint on the pi in the past did nothing.
but if i try now on my real server printer gets reset but then communication still fails.

the error shows up in dmesg and starts with:

cdc_acm 3-8:1.0: failed to set dtr/rts
above error shows up every time you try to connect via octoprint

removing and inserting usb cable in same port does nothing and triggers a lot of:

usb 3-8: USB disconnect, device number 8
usb 3-8: new full-speed USB device number 9 using xhci_hcd
usb 3-8: Device not responding to setup address.
usb 3-8: Device not responding to setup address.
usb 3-8: device not accepting address 9, error -71
usb 3-8: new full-speed USB device number 10 using xhci_hcd
usb 3-8: device descriptor read/64, error -71
usb 3-8: device descriptor read/64, error -71
usb usb3-port8: attempt power cycle
usb 3-8: new full-speed USB device number 11 using xhci_hcd
usb 3-8: Device not responding to setup address.
usb 3-8: Device not responding to setup address.
usb 3-8: device not accepting address 11, error -71
usb 3-8: new full-speed USB device number 12 using xhci_hcd
usb 3-8: Device not responding to setup address.
usb 3-8: Device not responding to setup address.
usb 3-8: device not accepting address 12, error -71
usb usb3-port8: unable to enumerate USB device

but if i change usb port it connects and device gets enumerated.

so i guess it might be a printer issue anyway but i'm not sure what to try next other than skip octoprint completely and copy the gcode files over to sd card manually.
but i do like octoprint and would have liked to continue to use it.

Did you do one of those preventive things like 1) add tape to one of the pins of the USB serial cable or 2) use an inline adapter to remove that 5V line in a similar way? If so, then this might explain things. The 5V pin on the USB connection seems to do two things: it allows the device drivers to come up successfully when the cable is inserted but it also seems to sink power over to the printer board. As a result of this, many people try to cheat that pin by applying tape. But in many cases that causes communications to work sporadically.

The cable you've described physically sounds like it's the right type.

Anytime the serial connection is reset the print job is lost, for what it's worth.

As for the error you're seeing, it's not just OctoPrint which might see this. Here's a thread where people on the Repetier forum are also seeing it.

"User: If I remove and reinsert the usb devices in the pi they don't re-enumerate it requires a reboot to get the server to enumerate the printers again."

"Repetier Support: You also need to unpower the printer if you unplug usb to get a new port. That is why I think that it is the usb converter on arduino board that crashes. Seems like that chip is ot as stable as the main AVR.

...With hub it is important to use a ctive one (with power) also with good Pi power I can use it without hub as well. Problem is that some usb cables that power pi are too thin dropping voltage or 5V units do not send full 5V. So if you can measure voltage on pi without anything else connected. Pi is also very sensitive on voltage. If you use original pi image you would often see the rainbow on hdmi output to indicate low voltage (our image has this disabled)."

From their suggestion, make absolutely sure that the server itself has a full 5V after everything is connected up. (They're starting to sell 5.2V power adapters now because everyone's having so many problems with overloaded power adapters.)

Continuing to read various things from the Internet regarding that particular error, I found this post which seems interesting to me.

Since the default Prusa configuration seems to be via-GPIO you might want to verify that the jumper is set so that it will use USB instead. (I don't know much about the Prusa, to be honest.)

FYI i worked around this whole issue by connecting an ftdi adapter to the tx, rx and gnd pins in the raspberry pi port on the printers controller.
has worked very reliably for many months now.

but will have to retest the built in usb port again since controller is now different (RMA).