Communication Issues (E5+ & RPi4)

STATUS: Unresolved

  • The issue continues to occure frequently
  • When printing from SD-card the issue still occurs, but the print is not affected
  • Verified with hundreds of hours of printing


  • Replaced USB-cable between RasPi4 and Printer (also added ferrit bead) | No effect

  • Installed origianl RasPi powersupply | No effect

  • Installed USB-hub w/powersupply to power WebCam separatly | No effect

  • Replaced SD-card in RasPi4 with a brand new 16GB Sandisk class 10 | No effect

  • Reinstall fresh version of Octoprint | No effect

  • Flashed to Marlin | No effect

  • Upgraded to Creality Silent Board v2.2 | No effect

  • Replace RasPi4 | Not tested

  • Not an attempt to solve the issue but I've installed a Phateus Dragon Hotend and BMG in Direct Drive, new fans and thermistor. Same BLT and heating cartridge.

I've logged my progression below in case someone have some suggestions, and hopefully eventually to help someone else down the road.

What is the problem?

Print stops after consecutive communication timeouts. It occures occationally on apparently random times. On shorter prints, longer prints, hours or a week in between. It's been going on for a couple of months - since installing Octoprint I suppose.

My troubleshooting log:

I started loggin print from SD vs through Octoprint. I had 124h printing from SD without issues and 67h printing from Octoprint when it stopped again. I have since probably printed twice this amount in both modes and get consistent results;

Print never fails when started from SD card. Octoprint will still occationally stop, but this won't affect the print (unless I attempt to recconect OP to the printer while the print is still going. Octoprint only disconnects now that I have re-enabeled the timeout thresholds, before it only froze and a reboot was required, which I perform after the print is complete)

The issue is clearly related to the RaspberryPi and/or OctoPi/Print.


  • Checked that cables are firmly in place
  • Moved USB to usb3 port on RasPi
  • Removed microSD card from E5+ slot (doubt that this has any relevance, but thought id remove it still)

octoprint (2).log (70.8 KB)
I've activated serial.log, since this last incident.


  • Registered a disconnect while printer was idle - same communication error reported in OctoPrint.


  • 2nd occurance (during a 2h benchy) after 7 days with many successful prints.

2021-03-27 octoprint.log (666.1 KB)
2021-03-27 Serial: Upload files for free - 2021-03-27 serial.log -


  • I added a 5010 5V fan to the rPi4 - Pi temps are now at rom temperature, but started trigering low voltage warnings.
  • taped 5v pin between Pi and E5+ - had no improvements while E5+ was powered on.
  • Swapped my beefy 1.5m long usb cable for a 1.0m thinner cable. Low voltage warnigns went away, however the first print stopped after just a few minutes.(communication error)
  • Tried two other power supply (5V 2.4A/2.0A) - low voltage warnings persisted. (both measured 4.98V which I also read is a bit low for a rPi4)
  • Changed to a medium thick usb c cable 1.0m and back to the initial power supply; 5.2V/3.4A. - Low voltage warnings are gone, and have had a few small successfull prints. (measured 5.15V)
  • Hopefully also my connection issues was related to the voltage issue and that the shorter cable bumps the end voltage enough to make it stable...


  • Seemed to be stable for a good week, then undervoltages warnings showed up about 3 days ago. They went away and stayed gone after rebooting octoprint so I was hoping they were only related to when I had powered off/on the systems.
  • A couple of days ago I had a benchy fail, and today the print stopped again while I was watching it; 14h into a 21h print.
  • I also wish there was a easy way of resuming the print, or for octoprint to attempt to reconnect and resume automatically. I can connect back to octoprint immediatly after it has disconnected.
  • I've disabled "Max. consecutive timeouts" for all three modes - thinking; that if it's only Octoprint overreacintg, this could avoid stopping the print. I'm not aware of what other risk I may be taking on by doing this though...
  • Changed to a Samsung 5V 2.1A "quick charger" (cellphone charger). Reading 5.17V before the 1m cable. This gave me several undervoltage warnings. Changed back to a "TOTU" 5.1V 3A powersupply. This measures 5.27V at the same point, and no undervoltage.
  • Installed the "Creality Temperature Fix" plugin as suggested in posted link below. Although not tested on the E5+, I'm giving it a try.

2021-04-10 octoprint.log (466.8 KB)


  • Flashed new firmware (Marlin as suggested by Charlie_Powell. This crashed the touchscreen, but the printer is operational through Octoprint. (Got myself some new issues to work out =) - more details below).
  • Still have Octoprints consecutive timeouts tresholds deactivated.


  • I only ran with Marlin on the stock Creality 8-bit board for a couple of days. Besides the touchscreen i didnt have any issues.

  • A few days ago i installed a Creality v2.2 silent board. Made a testprint with the preinstalled drivers which went ok, before I flashed it with Marlin After a short while the extruder stopped a couple of min into the print. Sometimes cliking a short while before stopping, other times just stopping. This keept happening on every print following print-attempt. Not slicer related, and I could see the gcode continued to send extruding commands.
    The extruder motor was not even warm, but I checked the extruder stepper driver voltage (1.390V), tested abit higher and lower with no improvements. I checked the cabeling multiple times without finding anything loose. I swapped the stock 3010 fan for the board with a better 3020 one and rearranged the cabeling to improve airflow to the board. I must have configured about 15 different firmwares before almost giving up on running Marlin 2.0 on a 8-bit board. To jump to the "solution"; I disabeled LIN_ADVANCE and everything is back to normal. I'm sure there is a better solution, but right now I'm just tired and glad to have a working printer again.
    The reason I had this enabeled int he first place, besides beeing the default config, is the error message when attempting to build the preconfigured M2.0.7.2; "s-curve accelleration and lin_advance does not work well together, activate exp_s-curve". This seemed counter intuitive to me the first time, but beeing my first time inside the firmware I went with it. Also this solution seemed to work for the stock 8-bit board and for the first benchy on the silent board. In the end ignoring this suggestion however and disabeling LIN_ADV seemed to fix it for me.

  • For the touch screen I've tried plenty there too. In my case I could never find a matching firmware and DWIN_SET. After having given up I stubled over a DWIN_SET that is working somewhat - and that'll do for now.

I've had a Phateus Dragon hotend and a BMG extruder custom DD assembly lying around for a month or two waiting for the last fan. I'm not sure how long I will be running the current setup and be testing against my original issue. Although I've messed around with alot of things the last week, I havent noticed any othe "communication timeouts". The last few days of firmware-fiddling will prove usefull when attacking the hotend upgrade.

Current plan is to monitor for the connectivity issues for a few weeks, while I try work out the kinks with the new firmware. Should it seem stable over time, I will reactivate the timout trehshods and to see if the issue return.

Print stopped 7h in. This time there was no errors reported in octoprint (Bed and nozzle temperaturs was kept hot - the print head had just stopped mid-print. I pressed "pause print" in octoprint - got stuck on "pausing print"

First listing in the log is only 3 min before i attempt to pause the print in octoprint (PS! timeout tresholds is deactivated). The serial log seem to show the same timeline - so it seem that as I happened to discover this probably only secounds after it stopped.

210509 octoprint.log (29.6 KB)
"2021-05-09 22:05:50,742 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer."

Starts at line 5028356.

After flashing to Marlin and disabling timeout thresholds in Octoprint I had no stopped prints for a month. Just when I thought it was solved - I had a new print stop, then another one a couple of days later.

Before the above actions Octoprint gave "connection timeout" warning, aborted the print and disconnected. This made the heated bed cool down and resuming print not possible.

Now the print just stops, all temperatures are kept active and octoprint show no warnings, does not disconnect. Attempting to pause or cancel print resutls in an never-ending loop.

Stopped on a Benchy.
Took the oportunity to succesfully resume the print by manyally editing the G-code and an improviced z-homing tactic.
I'll list the log-files for this last stop as well.
2021-05-13 octoprint.log (67.4 KB)

Have you tried running in safe mode?

  • No, it can be weeks in between each incident.

Additional information about your setup (from before I started the thread)

  • I run Octopi on a PasPi4 connected to my E5+ by USB (30cm).
  • The RasPi4 is powered seperatly with a 3.4A source. (Earlier i had undervoltage issues due to a long weak cable. This issue was solved a month ago). Communicating with Pi over wifi.
  • The Pi is in a printed case without heat-zink or active cooling (ordered). Temps are normally between 50-60C, sometimes close to 70C. I havent noticed thermal/throtteling warnigns though.
  • I have a web-cam (Logitic C920) connected (ony used for monitoring, when issue occured)
  • I had a microSD card inserted in the E5+ when this occured (not in use). I believe this was the case last time I had the same issue.
  • This issue has occured 2-3 times over the last month (twice the lase few days). Each time on prints longer than 2 hours. Octoprint disconnects when this happenes; I have never seen the printer disconnect while idle. - So to me it appears somewhat intermittent pattern.
  • For reference I've printed plenty of 1-7h prints over the last weeks with not issues.
  • I got a modified firmware from Kersey Fabrications (to better adjust ABL-pattern)

Somehow, this post has slipped through anyone answering for a while, so sorry about that! I guess no one had any ideas for a while...

Communication timeouts, usually as a result of some firmware bugs. Looking at your serial log, it exhibits a stock Creality firmware issue, as identified here:

OctoPrint doesn't show a temperature graph for my Creality printer with stock firmware - Get Help / FAQ - OctoPrint Community Forum

2021-03-27 19:35:13,828 - Recv:  == T:199.74 /200.00 == B:59.38 /59.00 @:79 B@:127

It's quite widely well known that Creality firmware is not the best for behaving itself, with a huge number of issues, for example with SD card in or out of the printer causing issues. I can recommend running a more recent, up to date copy of Marlin Firmware, rather than Creality's versions. I then read that you had a different version of the firmware, however it still appears to have a similar issue, so I don't entirely trust it is not the firmware.

In the serial log posted above, the printer just stops responding. It doesn't respond to several follow-up commands either. The octoprint logs don't tell much at all, other than the 'Detailed Progress' plugin letting us know that there is a message, quite a lot.

Try and update your firmware, maybe to the latest stable version of Marlin (, to be sure it is not a bug in your firmware. That's what it seems to me.


Hi, thanks for taking the time to look into my issue.

The firmware I've flashed is merely changing the postions of ABL routine. Otherwise it should be stock Creality firmware as you say. I've come across similar statemenst about Crealitys firmware, and experienced some irradic behavior myself that could be related to this.

I will look into updating the firmware (I'm awaiting a 32-bit silen board soon, and was planning on taking a dive into firmware then - I may look into it sooner then). Still just a couple of months into the 3D printing world and still got a fair portion to familiarize myself with.

As you may have seen in my notes above, I've disabled all the timout checks. I'm not sure what potential negative effects this could have. Please let me know if this is just flat out a poor idea.

PS! Following your link, I realise that refering to my pritner as "E5P" may be misleading. I got a Ender 5 Pluss, not a Pro. Updated my post accordingly.

I'll revert back when I've made som progress.

I followed this guide in flashing the firmware:

I've managed to flash the firmware to Marlin, using the config files for the E5+ found on github. I had to manually enable "EXPERIMENTAL_SCURVE" to make the firmware build successfully. Now both this and "LIN_ADVANCE_K" is active in the firmware - which I suspect could be an issue. Left it as this for now though...

Marlin Config (75.4 KB)

The cofingurations was not a simple copy pase-operation in my case. Allthough not a posihed result, it's up and running thourg Octoprint. I can already notice some of the advantages from the new firmware in general. Whater this will solve my initial issue may take some weeks to confirm.

A new issue is that the touchscreen is completely out of wack. A few buttons can be clicked, but otherwise completely non-functional. Does it need a firmware flash og it's own to mache the changes?

As a tip - don't upgrade to Marlin 2.0.8 for now, if you got the solution keep it stable :slightly_smiling_face:
They're still working through some bugs and a few of them are definitely serial connection related.

I'm not sure if I want to load my 8-bit card with more code anyway.
I'll limit my variable as much as possible till I got a fully stable system.

And... I might have been a bit premature on declearing Issue solved... ref. the updated main-post.