Buffer full and checksum mismatch

Warren_Schultz · February 14, 2019, 7:31pm

What is the problem?
Running into pausing/failure issues with a 0.10 height print. (Benchy)

What did you already try to solve it?
Initially, I was printing via USB as per usual (which works fine on standard-res prints), but the printer was frequently pausing shortly into the print. Terminal showed Full RX buffer and resend.

Tried uploading to the SD card via OctoPrint, but was taking forever. Did some reading online, and tweaked the Pi to not load the GUI, and disabled BT, then tested uploading again. The upload moved much faster this time, but then ran out of buffer again eventually.

Watching the console, this is an example sequence:

Recv: Full RX Buffer
Send: N30575 G1 X98.893 Y97.099 E0.00133*106
Send: N30571 G1 X98.278 Y97.480 E0.00274*109
Recv: Error:No Line Number with checksum, Last Line: 30575
Recv: Resend: 30576
Recv: ok
Send: N30572 G1 X98.366 Y97.382 E0.00120*103
Send: N30573 G1 X98.544 Y97.241 E0.00208*103
Recv: Error:Line Number is not Last Line Number+1, Last Line: 30575
Send: N30571 G1 X98.278 Y97.480 E0.00274*109
Recv: Resend: 30576
Recv: ok
Send: N30572 G1 X98.366 Y97.382 E0.00120*103
Recv: Error:No Line Number with checksum, Last Line: 30575
Send: N30573 G1 X98.544 Y97.241 E0.00208*103
Recv: Resend: 30576
Recv: ok
Send: N30574 G1 X98.754 Y97.139 E0.00213*101
Send: N30575 G1 X98.893 Y97.099 E0.00133*106
Recv: Error:Line Number is not Last Line Number+1, Last Line: 30575
Recv: Resend: 30576
Recv: ok
Send: N30571 G1 X98.278 Y97.480 E0.00274*109
Recv: Error:Line Number is not Last Line Number+1, Last Line: 30575
Recv: Resend: 30576
Send: N30572 G1 X98.366 Y97.382 E0.00120*103
Recv: ok
Send: N30573 G1 X98.544 Y97.241 E0.00208*103
Recv: Error:No Line Number with checksum, Last Line: 30575
Send: N30574 G1 X98.754 Y97.139 E0.00213*101
Recv: Resend: 30576
Recv: ok
Send: N30575 G1 X98.893 Y97.099 E0.00133*106
Recv: Error:No Line Number with checksum, Last Line: 30575
Recv: Resend: 30576
Recv: ok
Send: N30576 G1 X123.383 Y94.958 E0.22448*92
Send: N30577 G1 X124.283 Y94.906 E0.00823*81
Recv: Error:Line Number is not Last Line Number+1, Last Line: 30575
Send: N30578 G1 X125.157 Y94.894 E0.00798*80
Recv: Resend: 30576
Recv: ok
Send: N30571 G1 X98.278 Y97.480 E0.00274*109
Recv: Error:No Line Number with checksum, Last Line: 30575
Send: N30572 G1 X98.366 Y97.382 E0.00120*103
Recv: Resend: 30576
Recv: ok

Looking at this, I'm not sure I understand what the logic is here. Is OctoPrint pushing commands blindly, or responding to the resend requests. If responding to the resends, why is it sending the wrong lines?

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, octoprint.log, serial.log or output on terminal tab, ...)
OctoPrint version : 1.3.10
OctoPi version : 0.15.1
Prusa i3 Mk3, FW 3.5.2

I normally use Auto detection

Changing monitoring state from "Offline" to "Detecting serial port"
Serial port list: ['/dev/ttyACM0']
Connecting to: /dev/ttyACM0
Changing monitoring state from "Detecting serial port" to "Opening serial port"
Connected to: Serial<id=0x667403f0, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Starting baud rate detection...
Changing monitoring state from "Opening serial port" to "Detecting baudrate"
Trying baudrate: 115200
Send: N0 M110 N0*125
Recv: start
Changing monitoring state from "Detecting baudrate" to "Operational"
Send: N0 M110 N0*125
Recv: echo: 3.5.2-1999
Recv: echo: Last Updated: Feb 12 2019 11:36:02 | Author: (none, default config)
Recv: Compiled: Feb 12 2019
Recv: echo: Free Memory: 2042  PlannerBufferBytes: 1392
Recv: echo:Stored settings retrieved
Recv: adc_init
Recv: CrashDetect DISABLED
Recv: PAT9125_RES_X=0
Recv: PAT9125_RES_Y=240
Recv: PAT9125_init:1
Recv: PAT9125_RES_X=0
Recv: PAT9125_RES_Y=240
Recv: PAT9125_init:1
Recv: FSensor ENABLED
Recv: echo:SD card ok
Recv: Error:No Line Number with checksum, Last Line: 0
Recv: Resend: 1
Recv: ok
Send: N1 M115*39
Send: N2 M21*18
Send: N3 M1234*20
Recv: FIRMWARE_NAME:Prusa-Firmware 3.5.2 based on Marlin FIRMWARE_URL:https://github.com/prusa3d/Prusa-Firmware PROTOCOL_VERSION:1.0 MACHINE_TYPE:Prusa i3 MK3 EXTRUDER_COUNT:1 UUID:00000000-0000-0000-0000-000000000000
Recv: ok
Send: M20
Recv: echo:SD card ok
Recv: ok
Recv: Unknown M code: $3 M1234
Recv: ok

Thanks for your help!

OutsourcedGuru · February 14, 2019, 7:52pm

If this is a Prusa and given the symptoms, I could guess that this might be a soldered-on Raspberry Pi Zero W. The console-over-serial feature can also use the good UART so it's suggested that you toggle this off in sudo raspi-config.

Prior comments/suggestions

Short version: Although others have had success with a single-core Raspberry for this printer, the four-core Raspberry Pi 3B seems to have the processing power to make everything work better in a variety of situations.

Warren_Schultz · February 14, 2019, 7:53pm

Sorry, i forgot to specify. It is a 3B+. Streaming is handled by a second Pi running MotionEye.

OutsourcedGuru · February 14, 2019, 7:54pm

Assuming then that the Prusa is attached via USB then it's probably not necessary to disable Bluetooth, for what it's worth. But that's the accepted wisdom of everyone. I personally still entertain doubts. You might try temporarily toggling off the console-over-terminal as suggested to see if anything improves; you could always just put those back after troubleshooting.

Warren_Schultz · February 14, 2019, 7:55pm

Thanks. I wouldn't have thought so, but I figured it was worth simplifying things, reducing 2.4GHz emissions, and reducing current draw if nothing else. Oddly, the changes DID improve upload performance, but I don't know what to think about that.

OutsourcedGuru · February 14, 2019, 7:58pm

I'm like the Chicken Little of the Raspberry Pi and its UART duality. I'm always crying that "the sky is falling" with respect to the possibility that serial-based problems could be that lurking cheap UART which is suddenly in use.

Logic would suggest that it shouldn't be used in the case where you're plugging something into the USB port. As you've just seen, it made a change in the SD upload speed.

OutsourcedGuru · February 14, 2019, 8:05pm

Recv: Full RX Buffer
Send: N30575 G1 X98.893 Y97.099 E0.00133*106
Send: N30571 G1 X98.278 Y97.480 E0.00274*109

What's telling—to me anyway—is that second Send which is trying to resend 30571 when the printer has acknowledged 30575 already. One might conclude that 1) your firmware didn't acknowledge 30571 with an "ok" or 2) OctoPrint didn't somehow recognize it within this timeframe.

Perhaps if the RX Buffer in the firmware fills up, it just starts acting up.

If you're good with configuring your firmware, you might want to increase the size of the RX Buffer.

Warren_Schultz · February 14, 2019, 8:17pm

Agreed.
Unfortunately, getting set up to compile firmware is still on my To-Do list, otherwise I would.

OutsourcedGuru · February 14, 2019, 8:21pm

Back to basics:

verify that the Raspberry Pi 3B+ isn't in an undervoltage condition (5V 2.5A or better adapter)
verify that the serial cable is short and either has internal metallic shielding or a ferrite core

Warren_Schultz · February 14, 2019, 8:29pm

6" "high-speed" USB2 cable, 5V/2.4A max-per-port 60W Anker multi-port USB charger, but I did previously have this issue with a 2.5A CanaKit RPi kit adapter also. No ferrite core.

Core
temp=44.0'C
Core
volt=1.3375V

OutsourcedGuru · February 14, 2019, 8:35pm

Grab the serial cable with thumb/index finger of both hands about an inch apart, hold it up to your ear and bend it about 45 degrees back and forth. If there's a metallic shield inside then you should be able to hear it or feel it under your fingertips.

If not, then this can fix it up.

Warren_Schultz · February 14, 2019, 9:01pm

I should have a spare ferrite core floating around at home, I'll have to dig.

I did see this also with the stock Prusa cable previously, but hadn't been printing high resolution recently. I'm looking through the code a bit, but I'm new to Python, and having to wrap my brain around it.

Warren_Schultz · February 14, 2019, 10:15pm

I went through my settings to see what was different than default that I could remember changing.

I had Simulate ok for resend requests set to Always.
Switching it to If detected as necessary, it still is hitting the Full RX Buffer, but it is no longer resending lines in the incorrect order. It's struggling to upload the 10MB file to the SD still, but it hasn't given up yet.

We'll see if that fixes it, but that sounds like a parse error in OctoPrint (maybe). I haven't had time to go find that section of code to see if I can understand how it works.

OutsourcedGuru · February 14, 2019, 11:41pm

Search the forum for avrdude and you'll end up with posts like this one which talk about firmware tweaking.

It wouldn't hurt to have a backup of your board's firmware so you could play with downloading that from the board with that program.