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
RE: M112 error when sending gcode from Octoprint to MK3.5S but prints fine from USB stick
I just discovered that there is a setting in Prusa Slicer to suppress the "identify objects" M486 gcode, which causes the above crash when the object has a too-long filename. For single object files, M486 seems unnecessary. The default is as shown below -- ie: "Firmware-specific" sets the action to write M486. If you choose "Disabled" instead, M486 is no longer generated in the resulting gcode file.
RE: M112 error when sending gcode from Octoprint to MK3.5S but prints fine from USB stick
I have this setting on "OctoPrint comments", because it is used/needed by the Cancel Objects plugin. Long filenames can also mess up the web interface in OctoPrint. The top status bar with all current values will have a space overflow and the interface tabs below for the different views will be squished and become difficult to access. Better to keep filenames as short as possible.
RE:
I have this setting on "OctoPrint comments", because it is used/needed by the Cancel Objects plugin. Long filenames can also mess up the web interface in OctoPrint. The top status bar with all current values will have a space overflow and the interface tabs below for the different views will be squished and become difficult to access. Better to keep filenames as short as possible.
Hi Walter -- thanks again. I guess it would make sense to change the Label objects switch to "OctoPrint comments" if you have more than one object in your print job, and I'll do that since I see that that option also avoids the M486 gcode. As for long filenames, I personally like to use file names as long as the system allows, since I use the filename to differentiate aspects of similar models (dimensions of boxes/containers, nozzle and filaments sizes/types, etc.). OctoPrint seems good at allowing to hover over a filename and get the whole thing popping up. It's messy, agree, but has benefits I like.
I would rather get Prusa to fix what is obviously a firmware bug since my long filenames don't bother my old MK3S or my MINI when using OctoPrint. This is Prusa's issue, afterall, not ours.
RE: M112 error when sending gcode from Octoprint to MK3.5S but prints fine from USB stick
You can have the best of both worlds if you keep the names of the stl files short(er) and put all the necessary info into the filenames of your PrusaSlicer project. The problem here is caused by long names of stl files that are embedded in the gcode file. What is displayed in the file browser in OctoPrint are the filenames of the project. Info about nozzle sizes, layer height and filament type is included by PrusaSlicer already via the standard template for the output filename format. The length of project filenames seems to be not a problem so far.
RE: M112 error when sending gcode from Octoprint to MK3.5S but prints fine from USB stick
[....] The length of project filenames seems to be not a problem so far.
That's a useful insight, thank you. I've only used the Prusa Project option (extension *.3mf) when I've had to capture modifiers, etc.
But I still think that Prusa should fix this problem of long filenames so that we don't have to juggle different scenarios depending on extension types and printer models.