M112 error when sending gcode from Octoprint to MK3.5S but prints fine from USB stick

[PK1]

What is the problem?

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)".

HOWEVER: The exact same gcode loaded using the USB stick 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.

Have you tried running in safe mode?

Yes

Did running in safe mode solve the problem?

No

Systeminfo Bundle

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.11.05.092907 with "webcamd", based on OctoPi 1.0.0, running on Raspberry Pi 3 Model B Rev 1.2

What did you already do to try to solve it?

I did solve the issue but am not sure why it's an issue.

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, I tried to find the serial.log file on the whole RPi SD card but there was none, 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 maximum 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.

I post this to inform others, and to see if anyone can tell me if this error is the fault of OctoPrint, Prusa MK3.5S firmware, Prusa Slicer, or OctoPi. Again, it does not happen when the same file with the "long" filename reference is loaded from USB stick into the Prusa MK3.5S. Thanks

[Ewald_Ikemann]

FYI: The serial.log is inside the systeminfo bundle that you have been invited to attach to your initial post.

[foosel]

Known issue either in the slicer or the firmware, in any case in Prusa's hands:

[BUG] MK4 with Octoprint - M486 A<long name> crashes the printer

I suggest you remove that line from the slicer if you can. Alternatively we could create a single file plugin that strips it from gcode, or replaces the long lines with something less problematic.

And just for the record, that was a particularly bad experience of interaction with their team.

[PK1]

Thanks, Gina, very helpful as always. I naively searched under MK3.5S instead, and not MK4, and didn't find any reference to M112 and 'long name' problems anywhere. I did notice that the slicer adds the letter "A" to the filename, for whatever reason, maybe for the CRC. Once I found the log file and the recurring call to that line I clued in that it might be the filename. I first thought I had to shorten the actual filename that was being sent but then noticed that the slicer references the STL extension and not the GCODE one, which made no sense to me, and so I figured the only thing left was to shorten the stupid thing in the gcode, which worked.

@foosel

I suggest you remove that line from the slicer if you can. Alternatively we could create a single file plugin that strips it from gcode, or replaces the long lines with something less problematic.

It would be great to have a plugin that does that. But obviously I will be manually stripping it in the meantime if I can't figure out a way to prevent Prusa Slicer from adding it. Thanks again for the help.

[PK1]

@Ewald_Ikemann

FYI: The serial.log is inside the systeminfo bundle that you have been invited to attach to your initial post.

Brilliant, thanks for that headsup -- completely missed that even after 6 years of using OctoPrint

[PK1]

@PK1

Thanks, Gina, very helpful as always. I naively searched under MK3.5S instead, and not MK4, and didn't find any reference to M112 and 'long name' problems anywhere. I did notice that the slicer adds the letter "A" to the filename, for whatever reason, maybe for the CRC. Once I found the log file and the recurring call to that line I clued in that it might be the filename. I first thought I had to shorten the actual filename that was being sent but then noticed that the slicer references the STL extension and not the GCODE one, which made no sense to me, and so I figured the only thing left was to shorten the stupid thing in the gcode, which worked.

@foosel

I suggest you remove that line from the slicer if you can. Alternatively we could create a single file plugin that strips it from gcode, or replaces the long lines with something less problematic.

It would be great to have a plugin that does that. But obviously I will be manually stripping it in the meantime if I can't figure out a way to prevent Prusa Slicer from adding it. Thanks again for the help.

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.