M112 error when sending gcode from Octoprint to MK3.5S but prints fine from USB stick
I just did the upgrade from MK3S to MK3.5S and am having a frustrating problem.
Sending from OctoPrint a gcode file created in Prusa Slicer with the stock MK3.5S profile immediately restarts the printer and then throws up an Emergency Stop/M112 error. There is a very brief display of the OctoPrint logo screen on the printer display, so it gets that far. But then the above sequence happens with the printer restarting and then throwing up an orange error screen with the error message "Emergency stop invoked by G-code (M112)". Here is a screen shot.
As you can see, that screen has a QR code and a web link that looked encouraging, until I tried it -- https://prusa.io/28510 -- and I simply got sent to the Prusa3D homepage 🙄
HOWEVER: The exact same gcode loaded using the USB stick and prints perfectly.
The other strange thing is that sending the same model sliced with an MK3S profile causes no problem when sending it to the printer for printing -- the OctoPrint screen on the printer display comes up and I can print just fine from there.
Everything is at the latest version:
Prusa Slicer = 2.8.1+win64
MK3.5S firmware = 6.1.3+7898
OctoPrint = 1.10.3
OctoPi = Build 2024.05.14.100113 with "webcamd", based on OctoPi 1.0.0, running on Raspberry Pi 3 Model B Rev 1.2
I have no logs other than the above error screen, since I haven't found any clear info on how to log a session like this (maybe someone can advise?).
Has anyone seen this problem and resolved it?
Thanks.
RE: M112 error when sending gcode from Octoprint to MK3.5S but prints fine from USB stick
You can enable the serial logging in OctoPrint, found under Settings > Printer > Serial connection > Enable serial.log (or something like that).
Did you check the temperature curve in OctoPrint for any fluctuations?
RE:
Thanks for your comment. The printer was at room temperature still, since the printer restarted before the gcode got to the nozzle and heatbed temp settings.
I did solve the issue.
Lots of blind allies along the way.
The problem was the reference to an STL filename that seems to be too long.
Comments about what I found along the way:
1) First, there is no serial.log file that I could find by searching the whole RPi SD card, even though I chose logging of serial.log in OctoPrint.
2) The chain of events was instead captured in the daemon.log file, located in the /var/log directory.
3) The daemon.log files flagged an error called "No Checksum with line number, Last Line: 8". Here the "last line" happened to be Line #8, which means the error was in the next line, Line #9. That line contained this code:
N9 M486 AParametric_compartment_box_2x2comp_BOX_only_115x85x65high_2.0mm_wall_for_WALL_TRANSFORMERS_etc.stl*3
Once I shortened this name in the gcode, I could send the gcode to the printer via OctoPrint without errors. (I don't know the secret length that's acceptable since I didn't test various filename edits to see what the max length was before getting the error...).
I have never had this error before with the 8-bit version of this printer (MK3S) using OctoPrint.
However, I do have a Prusa MINI and when I use Prusalink it is sensitive to filename length. But after switching my MINI to OctoPrint using an RPi, the same file sent via OctoPrint did not cause a filename length error.
Stupid issue to have after upgrading from 8-bit to 32-bit controller boards, but at least it's solved.
RE: M112 error when sending gcode from Octoprint to MK3.5S but prints fine from USB stick
I saw the discussion over on the OctoPrint forum. Well, in antediluvial times on Windows 3.1 we had to make do with 8.3 filenames. 🙂
The file serial.log is located inside a hidden directory (with a "." as first character in the name) in the home directory of the OctoPrint user account, e.g. /home/pi/.octoprint/logs/
Perhaps you did not enable the display of hidden files/directories in your file browser?
It is common practice on Linux to put administrative stuff and config files in such hidden folders or in hidden files.
RE:
I saw the discussion over on the OctoPrint forum. Well, in antediluvial times on Windows 3.1 we had to make do with 8.3 filenames. 🙂
The file serial.log is located inside a hidden directory (with a "." as first character in the name) in the home directory of the OctoPrint user account, e.g. /home/pi/.octoprint/logs/
Perhaps you did not enable the display of hidden files/directories in your file browser?
It is common practice on Linux to put administrative stuff and config files in such hidden folders or in hidden files.
Hi, thanks. Yes, I am old enough to remember the 8.3 DOS days, lol. It's so strange but I did enable "Hidden Files" in WinSCP, not feeling like messing with a terminal connection and using the command line. I'm sure I refreshed, etc., but did not see that serial.log file. I tried it again today (after already having solved the problem) and there it is! I'm not sure what happened earlier. Anyway, the offending section of serial.log is pasted below, for reference.
2024-11-28 23:07:09,262 - Changing monitoring state from "Operational" to "Starting"
2024-11-28 23:07:09,300 - Send: N0 M110 N0*125
2024-11-28 23:07:09,326 - Recv: ok
2024-11-28 23:07:09,329 - Changing monitoring state from "Starting" to "Printing"
2024-11-28 23:07:09,414 - Send: N1 M73 P0 R283*29
2024-11-28 23:07:09,419 - Recv: ok
2024-11-28 23:07:09,421 - Send: N2 M73 Q0 S285*24
2024-11-28 23:07:09,433 - Recv: ok
2024-11-28 23:07:09,464 - Send: N3 M201 X4000 Y4000 Z200 E2500*8
2024-11-28 23:07:09,520 - Recv: ok
2024-11-28 23:07:09,548 - Send: N4 M203 X300 Y300 Z12 E120*8
2024-11-28 23:07:09,626 - Recv: ok
2024-11-28 23:07:09,638 - Send: N5 M204 P4000 R1250 T4000*80
2024-11-28 23:07:09,663 - Recv: ok
2024-11-28 23:07:09,666 - Send: N6 M205 X8.00 Y8.00 Z2.00 E5.00*59
2024-11-28 23:07:09,686 - Recv: ok
2024-11-28 23:07:09,688 - Send: N7 M205 S0 T0*36
2024-11-28 23:07:09,712 - Recv: ok
2024-11-28 23:07:09,714 - Send: N8 M486 S0*98
2024-11-28 23:07:09,737 - Recv: ok
2024-11-28 23:07:09,739 - Send: N9 M486 AParametric_compartment_box_2x2comp_BOX_only_115x85x65high_2.0mm_wall_for_WALL_TRANSFORMERS_etc.stl*3
2024-11-28 23:07:09,758 - Recv: Error:No Checksum with line number, Last Line: 8
2024-11-28 23:07:09,759 - Recv: Resend: 9
2024-11-28 23:07:09,763 - Recv: ok
2024-11-28 23:07:09,771 - Send: N9 M486 AParametric_compartment_box_2x2comp_BOX_only_115x85x65high_2.0mm_wall_for_WALL_TRANSFORMERS_etc.stl*3
2024-11-28 23:07:09,812 - Recv: Error:No Checksum with line number, Last Line: 8
2024-11-28 23:07:09,819 - Recv: Resend: 9
2024-11-28 23:07:09,824 - Recv: ok
2024-11-28 23:07:09,840 - Send: N9 M486 AParametric_compartment_box_2x2comp_BOX_only_115x85x65high_2.0mm_wall_for_WALL_TRANSFORMERS_etc.stl*3
2024-11-28 23:07:09,887 - Recv: Error:No Checksum with line number, Last Line: 8
2024-11-28 23:07:09,888 - Recv: Resend: 9
2024-11-28 23:07:09,897 - Recv: ok
2024-11-28 23:07:09,899 - Send: N9 M486 AParametric_compartment_box_2x2comp_BOX_only_115x85x65high_2.0mm_wall_for_WALL_TRANSFORMERS_etc.stl*3
2024-11-28 23:07:09,933 - Recv: Error:No Checksum with line number, Last Line: 8
2024-11-28 23:07:09,934 - Recv: Resend: 9
2024-11-28 23:07:09,938 - Recv: ok
2024-11-28 23:07:09,940 - Send: N9 M486 AParametric_compartment_box_2x2comp_BOX_only_115x85x65high_2.0mm_wall_for_WALL_TRANSFORMERS_etc.stl*3
2024-11-28 23:07:09,970 - Recv: Error:No Checksum with line number, Last Line: 8
2024-11-28 23:07:09,971 - Recv: Resend: 9
2024-11-28 23:07:09,986 - Recv: ok
2024-11-28 23:07:09,988 - Send: N9 M486 AParametric_compartment_box_2x2comp_BOX_only_115x85x65high_2.0mm_wall_for_WALL_TRANSFORMERS_etc.stl*3
2024-11-28 23:07:10,012 - Recv: Error:No Checksum with line number, Last Line: 8
2024-11-28 23:07:10,013 - Recv: Resend: 9
2024-11-28 23:07:10,026 - Recv: ok
2024-11-28 23:07:10,053 - Send: N9 M486 AParametric_compartment_box_2x2comp_BOX_only_115x85x65high_2.0mm_wall_for_WALL_TRANSFORMERS_etc.stl*3
2024-11-28 23:07:10,088 - Recv: Error:No Checksum with line number, Last Line: 8
2024-11-28 23:07:10,089 - Recv: Resend: 9
2024-11-28 23:07:10,108 - Recv: ok
2024-11-28 23:07:10,114 - Send: N9 M486 AParametric_compartment_box_2x2comp_BOX_only_115x85x65high_2.0mm_wall_for_WALL_TRANSFORMERS_etc.stl*3
2024-11-28 23:07:10,156 - Recv: Error:No Checksum with line number, Last Line: 8
2024-11-28 23:07:10,157 - Recv: Resend: 9
2024-11-28 23:07:10,180 - Recv: ok
2024-11-28 23:07:10,181 - Send: N9 M486 AParametric_compartment_box_2x2comp_BOX_only_115x85x65high_2.0mm_wall_for_WALL_TRANSFORMERS_etc.stl*3
2024-11-28 23:07:10,233 - Recv: Error:No Checksum with line number, Last Line: 8
2024-11-28 23:07:10,234 - Recv: Resend: 9
2024-11-28 23:07:10,268 - Recv: ok
2024-11-28 23:07:10,277 - Send: N9 M486 AParametric_compartment_box_2x2comp_BOX_only_115x85x65high_2.0mm_wall_for_WALL_TRANSFORMERS_etc.stl*3
2024-11-28 23:07:10,311 - Recv: Error:No Checksum with line number, Last Line: 8
2024-11-28 23:07:10,311 - Recv: Resend: 9
2024-11-28 23:07:10,331 - Recv: ok
2024-11-28 23:07:10,342 - Send: N9 M486 AParametric_compartment_box_2x2comp_BOX_only_115x85x65high_2.0mm_wall_for_WALL_TRANSFORMERS_etc.stl*3
2024-11-28 23:07:10,363 - Recv: Error:No Checksum with line number, Last Line: 8
2024-11-28 23:07:10,364 - Recv: Resend: 9
2024-11-28 23:07:10,365 - Printer keeps requesting line 9 again and again, communication stuck
2024-11-28 23:07:10,365 - Changing monitoring state from "Printing" to "Error"
2024-11-28 23:07:10,411 - Send: M112
2024-11-28 23:07:10,456 - Send: N10 M112*16
2024-11-28 23:07:10,464 - Send: N11 M104 T0 S0*17
2024-11-28 23:07:10,475 - Send: N12 M140 S0*86
2024-11-28 23:07:10,594 - Changing monitoring state from "Error" to "Offline after error"
2024-11-28 23:07:10,682 - Connection closed, closing down monitor
2024-11-28 23:07:11,221 - Closing down send loop