M112 after no checksum errors

Get Help
1

What is the problem?

I have had two failed prints now in a row where the Prusa is showing M112, Emergency Stop.
Same .gcode file and both stopped at the same spot after about 7-8hours of printing. Have been printing similar files for the last 2 weeks with no issues.

On reviewing the Octoprint.log both times before the M112 was called the printer and octoprint looped with the following. (3 sets with 5 times of each occurrence)

Recv: ok
| Send: N1021019 G1 X180.377 Y199.780 E0. 430 Y198.503 E0.02618*124
| Recv: Error:No Checksum with line number, Last Line: 1021018
| Recv: Resend: 1021019
| Recv: ok

2021-09-26 22:35:20,131 - octoprint.util.comm - WARNING - Printer keeps requesting line 1021019 again and again, communication stuck
2021-09-26 22:35:20,131 - octoprint.util.comm - INFO - Changing monitoring state from "Printing" to "Error"
2021-09-26 22:35:20,139 - octoprint.util.comm - INFO - Force-sending M112 to the printer

This is the section of the GCode being referenced

1021003: ;WIPE_END
1021004: G1 E-0.04000 F2100.000
1021005: G1 Z3.600 F10800.000
1021006: G1 X109.458 Y23.240
1021007: G1 Z3.200
1021008: G1 E0.80000 F2100.000
1021009: M204 S800
1021010: G1 F1500.000
1021011: G1 X109.279 Y23.214 E0.00472
1021012: G1 X109.103 Y23.135 E0.00504
1021013: G1 X108.938 Y23.028 E0.00511
1021014: G1 X108.783 Y22.834 E0.00646
1021015: G1 X108.657 Y22.616 E0.00657
1021016: G1 X108.579 Y22.371 E0.00670
1021017: G1 X108.527 Y22.100 E0.00718
1021018: G1 X108.504 Y21.739 E0.00944
1021019: G1 X108.551 Y21.392 E0.00912
1021020: G1 X108.619 Y21.211 E0.00502
1021021: G1 X108.809 Y20.960 E0.00821
1021022: G1 X108.958 Y20.855 E0.00475
1021023: G1 X109.184 Y20.776 E0.00624
1021024: G1 X109.208 Y21.083 E0.00803
1021025: G1 X109.037 Y21.139 E0.00470
1021026: G1 X108.901 Y21.253 E0.00461
1021027: G1 X108.821 Y21.365 E0.00358
1021028: G1 X108.738 Y21.625 E0.00712

I cant see anything myself in the Gcode that stands out, and both failures happened on the same layer.

I am printing now in Safe Mode to see if it prints, if it fails I will reslice the models and print again.

The print is for a bed full of tokens about 35mm diameter and 5mm high. I have printed 100's in the last few week with no issues until this set.

Thought I would ask the community for other options to look at while I wait the 7 hours to see if it fails again or not.

What did you already try to solve it?

Restarted Printer, Restarted Octoprint - Full power down of both.
Started Reviewing logs and Gcode. enabled Serial logging

Trying same Gcode in Safe Mode now - if fails again will try reslicing parts and printing again.
octoprint (1).log (246.1 KB)

Have you tried running in safe mode?

Running print in safe mode now

Did running in safe mode solve the problem?

Waiting for results

Systeminfo Bundle

octoprint-systeminfo-20210927075745.zip (47.6 KB)

You can download this in OctoPrint's System Information dialog ... no bundle, no support!)

WRITE HERE

Additional information about your setup

OctoPrint version: 1.6.1, OctoPi version: 0.18.0, printer: Prusa i3 mk3s+ mmu2s, firmware: 3.10.0-4481, browser: chrome, operating system: windows10pro, Raspberry pi 4

... as much data as possible

WRITE HERE

2

Hello @thepowerman89

First there is this:

|      throttle_state: '0x80000'

Your Pi is getting too hot:

Then you have some issues with the gcode file in line 1021019:

grafik
grafik2131×151 8.58 KB

There are a lot of NUL characters in that line.

You may check that file and line

1 Like
3

Thanks for the reply Ewald_Ikemann

I will look into the Pi getting too hot. I havent seen it go past 60C yet, but will look into it now.

Im not sure if those Null characters are from me copying it across as text, i didnt notice any NULL's when I view the GCode. This is what I see in N++ when viewing the GCode

image
image388×617 12 KB

The print is at 30% now in safe mode. if it does fail, I will re slice and see if that works

4

You may check the file on the Pi. Or you just upload it again.

5

Even without the nulls, the lines in the log don't match your posted GCode. Look at the X & Y values. Are you sure this is the same file? File or serial comms corruption is possible, but one that just happens to shift all the X/Y values the same amount isn't.

Also, if you are running something like OctoLapse or DisplayLayerProgress that is injecting GCode into the print, the line numbers aren't going to match up directly.

6

Sent line number are not necessarily be the same a the line number in the editor.
The editor counts all lines, also the commented ones.
During transmission, only the sent ones get the line number Nxxxxxxxx

1 Like
7

Ah yes TTalkington. you are correct, I am looking at the wrong section of the GCode.
I dug deeper into the GCode and found all the NULLS as stated by Ewald. Looks like the file is definitely corrupt.
Thanks for pointing that out Ewald, makes sense that the lines sent dont match the GCode. The line with the Nulls in the Gcode is actually 1067526.

I checked both the file from PrusaSlicer and the file on OctoPrint, and both have the Nulls at the same position.

Printing a new slice now and see how it runs.
Thanks for all the assistance

3 Likes