What is the problem?
Ok. So I stopped connecting to my printer with octoprint on a stock Cr-10 mini. Figured it might be the usb port so I upgraded the board to the v.4.2.7 which should be a no brainer upgrade to have better prints... Well connecting is now fine but it pauses and I have discovered that I can do Fake Acknowledgement to get passed the pauses but that's ridiculous on a 24 hour+ print. Especially with pauses frequently happening. I have tried nearly every possible solution I have found anywhere.
What did you already try to solve it?
Increased buffer size on firmware, tried multiple and a brand new high quality cable, turned off resume after pause, you name it - I think I've tried it. Also tried slicer fixes in Cura. Still getting pauses frequently.
Have you tried running in safe mode?
Yes multiple times
Did running in safe mode solve the problem?
Nope.
Systeminfo Bundle
You can download this in OctoPrint's System Information dialog ... no bundle, no support!)
I think this is what the most recent pause looked like:
Send: N763 G3 X167.545 Y64.040 I0.756 J22.617 E237.26075*103
Recv: T:199.97 /200.00 B:50.22 /50.00 @:65 B@:0
Recv: T:200.10 /200.00 B:50.13 /50.00 @:61 B@:0
Recv: T:200.00 /200.00 B:50.04 /50.00 @:66 B@:0
Recv: T:199.96 /200.00 B:49.88 /50.00 @:67 B@:127
Recv: T:200.12 /200.00 B:50.19 /50.00 @:59 B@:0
Recv: T:200.09 /200.00 B:50.12 /50.00 @:62 B@:0
Recv: T:199.90 /200.00 B:50.02 /50.00 @:70 B@:0
Recv: T:199.99 /20
Additional information about your setup
OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible
Octopi v1.61 cr-10 mini with v4.2.7, th3d, chrome, raspberry pi 4, ezabl installed.
browser.user_agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
connectivity.connection_check: 1.1.1.1:53
connectivity.connection_ok: true
connectivity.enabled: true
connectivity.online: true
connectivity.resolution_check: octoprint.org
connectivity.resolution_ok: true
env.hardware.cores: 4
env.hardware.freq: 1500
env.hardware.ram: 1903308800
env.os.bits: 32
env.os.id: linux
env.os.platform: linux
env.plugins.pi_support.model: Raspberry Pi 4 Model B Rev 1.4
env.plugins.pi_support.octopi_version: 0.18.0
env.plugins.pi_support.throttle_state: 0x0
env.python.pip: 20.3.3
env.python.version: 3.7.3
env.python.virtualenv: true
octoprint.safe_mode: false
octoprint.version: 1.6.1
systeminfo.generator: systemapi
Hello Chad,
reading and wondering what exactly goes back and forth between octoPrint and your printer. That's what the serial.log captures.
You need to enable it first as serial logging may consume some serious sd space over time so it's disabled normally. Enable it (click on the wrench, Serial connection is on the top, scroll down to the last section, check the checkBox Log communication to ...
Then please do a print until the problem appears.
The easiest way to post the serial.log is uploading a Systeminfo Bundle.
You can (and should) safely disable Serial Logging thereafter.
I will try next time I am ready to start a new print. Currently printing from the SD card.
This is an arc command. Have you tried printing with just regular straight-line gcode?
Arcs are more difficult for firmware to work with, and sometimes they can choke on them because (a) they're arcs, and special, (b) the length of the command can go over the limit for the firmware to successfully parse
I have tried it both with arc and without. Same result honestly. I couldn't tell a difference in frequency of the pauses at all between the two types of gcode.