Anycubic Chiron Getting disconnected at random

What is the problem?
My Anycubic Chiron and octoprint will loose connection to each other randomly during a print. I'm running stock firmware on the Chrion 1.3.0 with a Pi4 and octoprint 1.4.0. This typically occurs on longer prints but, haven't been able to nail down any specific % or timing around this.
The print head just stops and everything remains heated until I am able to manually override the printer.
probalby worth noting once the disconnect occurs I am unable to reconnect without rebooting the printer and/or octoprint, sometimes it's both other times it's just the printer.

What did you already try to solve it?
I use to be running on a Cu-box i4 with armbian and octoprint installed. I still had the same end result IE failed prints in the middle (I did not capture logs at the time). This has since been replace with a pi 4b due to it being a more common hardware used for octoprint. I've reinstalled octoprint a few times on both devices and the problem still persisted. Multiple SD cards have been used ranging from 8GB to 32GB.
USB cable to printer has been flexed and moved to see if there where any disconnects. No disconnects occurred.
New .gcode, as well as testing same .gcode on SD directly in the printer.
Multiple slicers S3D and CURA have been used to produce .gcode with failed prints both which work on the SD card
Tried different baud rates 115200 and 250000

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

I've captures octoprint.log in DEBUG as well as serial.log and dmesg from the raspberry pi, and terminal output from octopi which all can be found here:
https://drive.google.com/drive/folders/1j0fE2OVDivhjeaJ4z6zgD40LkRNMizd3?usp=sharing

If other logs are needed please let me know which ones and I can set up another print as it'll inevitably fail.

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible)
At the time of failing this is/was the configuration:

  • Octopirint 1.4.0
  • Octopi 0.17.0, running on Raspberry Pi 4 Model B Rev 1.1 (with 5V 3A power supply, I have not seen any power message issues, dmesg have been included)
  • Anycubic Chiron stock firmware version 1.3.0
  • Stock Anycubic Chiron USB A to USB B
  • USB A to USB A shielded running to a Wyze v2 camera on web cam firmware plugged into the Pi
  • Chrome browser, was not open at time of failure
  • files sliced with CURA on a MAC running 10.15.4, same .gcode works fine on the SD card.
  • Currently install plugins can be found on the goole drive in octoprint-installed-plugins.txt
  • Connection is set to automatic and typically settles on a buad rate of 250000
  • USB cable to printer has the power pin blocked plugged into the pi. However it was not blocked while hooked up to the cu-box i4 though.
1 Like

I have had this happen 3 times so far. There was nothing in the logs to indicate why. Only that the connection was lost, and that it retried to connect a number of times and then gave up.

New amazon basic USB cable came in. https://www.amazon.com/gp/product/B00NH13DV2/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8&psc=1
Immediately I noticed this cable worked without the USB power block off. I will however still be using it to keep as many things consistent as possible.

Firing off a test print shortly.

Connection lasted longer than expected however it still did eventually loose the connection and the print failed mid print still.
octoprint.log, terminal output, serial.log, and dmesg are all supplied here:
https://drive.google.com/drive/folders/1qAV8VP12GwXqjQkQGCFiGhtWO6dBueTS?usp=sharing

Fired up a repetier-server on a second SD card I had and everything is working great been able to complete multiple prints with the current set up, no disconnects or failed prints.
This means:
A) There is some configuration on octoprint that is not set right (no idea what). Would a misconfiguration cause random disconnects? I would suspect more consistent failures if there was a configuration issue.
B) There is a software issue in octoprint.