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
SUMMARY OF WHAT I'VE TRIED
-
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 2.0.7.2 | 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:
05/05:
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.
20/03:
- 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.
25/03:
- Registered a disconnect while printer was idle - same communication error reported in OctoPrint.
27/03:
- 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 - ufile.io
28/03:
- 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...
10/04:
- 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.
3rd,4th:
2021-04-10 octoprint.log (466.8 KB)
11/4:
- Flashed new firmware (Marlin 2.0.7.2) 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.
17/4:
-
I only ran with Marlin 2.0.7.2 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 2.0.7.2. 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.
9/5:
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.
13/5:
After flashing to Marlin 2.0.7.2 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)
