Maker Ultimate 2 stopping mid-print when connected through USB

Get Help
1

What is the problem?

When trying to print through the USB connection from OctoPrint everything will seemingly work (i.e. print starts without issues) until, at some "random" point during the print it will stop and the printer will just show a "KILLED" message in its display.

Logs seem to indicate that everything is fine until the printer starts complaining about checksum mismatch over and over on the same line. It's worth noting that not a single checksum error is reported before this point.

2020-10-21 00:16:00,632 - octoprint.util.comm - INFO - Got a resend request from the printer: requested line = 38125, current line = 38126
| Last lines in terminal:
| Recv: ok
| Send: N38123 G1 X109.834 Y97.76818
| Recv: ok
| Send: N38124 G0 F7200 X109.36 Y98.42572
| Recv: ok
| Send: N38125 G1 F6000 X112.739 Y101.804 E1013.3237256
| Recv: Error:checksum mismatch, Last Line: 38124
| Recv: Resend: 38125
| Recv: ok
| Send: N38125 G1 F6000 X112.739 Y101.804 E1013.3237256
| Recv: Error:checksum mismatch, Last Line: 38124
| Recv: Resend: 38125
| Recv: ok
| Send: N38125 G1 F6000 X112.739 Y101.804 E1013.3237256
| Recv: Error:checksum mismatch, Last Line: 38124
| Recv: Resend: 38125
| Recv: ok
| Send: N38125 G1 F6000 X112.739 Y101.804 E1013.3237256
| Recv: Error:checksum mismatch, Last Line: 38124
| Recv: Resend: 38125
2020-10-21 00:16:00,653 - octoprint.util.comm - INFO - Got a resend request from the printer: requested line = 38125, current line = 38126
| Last lines in terminal:
| Recv: ok
| Send: N38125 G1 F6000 X112.739 Y101.804 E1013.3237256
| Recv: Error:checksum mismatch, Last Line: 38124
| Recv: Resend: 38125
| Recv: ok
| Send: N38125 G1 F6000 X112.739 Y101.804 E1013.3237256
| Recv: Error:checksum mismatch, Last Line: 38124
| Recv: Resend: 38125
| Recv: ok
| Send: N38125 G1 F6000 X112.739 Y101.804 E1013.3237256
| Recv: Error:checksum mismatch, Last Line: 38124
| Recv: Resend: 38125
| Recv: ok
| Send: N38125 G1 F6000 X112.739 Y101.804 E1013.3237256
| Recv: Error:checksum mismatch, Last Line: 38124
| Recv: Resend: 38125
| Recv: ok
| Send: N38125 G1 F6000 X112.739 Y101.804 E1013.32372*56
| Recv: Error:checksum mismatch, Last Line: 38124
| Recv: Resend: 38125
2020-10-21 00:16:00,760 - octoprint.util.comm - WARNING - Printer keeps requesting line 38125 again and again, communication stuck
2020-10-21 00:16:00,761 - octoprint.util.comm - INFO - Changing monitoring state from "Printing" to "Error: Printer keeps requesting line 38125 again and again, communication stuck"

I compared it to the logs of a previous failed print and found an interesting similarity. Both times the line in which the print failed it was the bigger (in terms of number of characters) line that had been attempted on that print job.

On this particular job, print failed on this line: "N38125 G1 F6000 X112.739 Y101.804 E1013.3237256"
On a previous job, print failed on this line: "N10565 G1 F3600 X104.547 Y132.661 E1257.0129261"

Both lines are exactly 48 characters long, and all other lines up to that point had been 47 characters long or less.

I don't know if that might point to some buffering issues or some problem with the firmware, but it's worth noting that the exact same gcode files print just fine from the SD.

Logs are also spammed with thousands of occurrences of this exception right before the checksum errors show up but I feel like that's unrelated because they're not present during an earlier print failure.

2020-10-21 00:15:26,450 - tornado.application - ERROR - Future exception was never retrieved: Traceback (most recent call last):
File "/home/pi/.local/lib/python2.7/site-packages/tornado/gen.py", line 1141, in run
yielded = self.gen.throw(*exc_info)
File "/home/pi/.local/lib/python2.7/site-packages/tornado/websocket.py", line 876, in wrapper
raise WebSocketClosedError()
WebSocketClosedError

What did you already try to solve it?

Replaced USB cable, tried a different port on the Raspberry Pi. Also tried different models in case there was something wrong with the slicing.

Have you tried running in safe mode and if so did it solve the issue?

I haven't tried safe mode.

Complete Logs

Octoprint.log: https://pastebin.com/bL3jJU35

Additional information about your setup

The printer is a Monoprice Maker Ultimate 2 running stock 1.6 firmware. It's connected to a Raspberry Pi 4 running OctoPrint 1.4.2

1 Like
2

Hello !

Just to be sure, have you tried this ?

1 Like
3

Hi there!

I hadn't! But I just tried it with yet another different print and got the same result.

Once again, print failed on the first line that reached 48 characters. In this case it was:
Send: N133971 G1 F1800 X107.561 Y78.286 E1000.25659*56
Recv: Error:checksum mismatch, Last Line: 133970
Recv: Resend: 133971

Did some quick grepping on serial.log to confirm only two commands over the last two print attempts have ever reached 48 characters (both of which resulted in the print failing):

pi@raspberrypi:~/.octoprint/logs $ cat serial.log | grep Send | cut -f 4 -d ':' | sed s@^\ @@ | awk '{print length($0) " " $0}' | sort -n | uniq | tail -n 5
47 N38099 G1 F6000 X112.739 Y92.754 E1012.8115913
47 N38101 G1 F6000 X112.739 Y93.885 E1012.8338110
47 N38111 G1 F6000 X112.739 Y97.279 E1012.9560710
48 N133971 G1 F1800 X107.561 Y78.286 E1000.2565956
48 N38125 G1 F6000 X112.739 Y101.804 E1013.32372*56

4

Another datapoint. Just tried printing the exact same gcode file through Cura (USB-connected to my laptop) and it prints fine.

5

Hi @FranGM,

You laptop is way less impacted by Electromagnetic issues than what a raspberry will ever be.

The logs you're seeing (serial.log) is what Octoprint sends and receive. The end of the lines (*46 as an example) is the checksum. They seem fine, but this is from an octoprint point of view. High are the chances that something wrong is happening between the send by a Raspi and the receiving by your printer. Especially because EMI.

I had this issue recently. USB cables were good, GCODE was good, the printer is good, the raspberry works fine. Just, all together, it does'nt work because of EMI (and so, checksum errors). Taping the cable and finding a good power source unit for my raspberry fixed the issue.

K.

1 Like
6

Something you could try (apart from ruling out EMI, and actually only once you rule out EMI as we are going to nuke error correction capabilities) is to disable line numbers and checksums in OctoPrint. That will shorten the lines significantly. If it then runs through, it looks like a buffer is overflowing somewhere in the firmware.

2 Likes
7

Cheers, those are both good suggestions.

While I was procuring a new power source for the pi I installed octoprint on my laptop and gave it a go. Prints also fail from my laptop when printing from octoprint which would seem to exonerate the pi. Same laptop with same cable seems to be able to print just fine from Cura.

Worth pointing out that I also got a failure after disabling checksums, but the terminal output was still showing line numbers and checksums as if those were being sent, so maybe that change wasn't fully applied (or the logging includes line numbers even if they're not being sent, I haven't checked the code yet)

Since the printer was running a somewhat old version of the official firmware I've decided to update it before attempting any more involved troubleshooting. I'm currently running a test print with the new firmware so I guess we'll see how that goes!

1 Like
8

So another update here! After updating the firmware on my printer to the latest available version (v. 2.2.8) I can confirm that the problem is gone! I've had no more failures when printing from my laptop or the pi even with lines exceeding that previous 48-byte limit, so it seems like somewhere along the line either the USB buffer size was increased or some other change was made.

Thanks for your help!