This is not any big issue, but it seems like I might be missing a setting somewhere.
Output on the terminal shows the full filename:
Send: M27
Recv: Cool_Slot_Big_Holes_x2_0.3mm_PLA_MK3.gcode
Recv: SD printing byte 5855852/6450245
Recv: 03:19
Recv: ok
In the status block, it displays a 8.3 truncated filename.
File: **cool_s~1.gco** **(SD)**
OctoPrint Version 1.4.0
OctoPi Version 0.15.0, running on Raspberry Pi 3 Model B Rev 1.2
Prusa i3 MK3S over USB
Hello @herg!
This is explained here: Why does OctoPrint display files on the printer's SD so weirdly?
Thanks for the response and the link. That does make sense for displaying the SD card contents. Here, however, it's just the currently printing file. My best guess is that OctoPrint is using a different gcode than M27 to get the filename. I'm going to do some more investigation to see what I can figure out. Really, it's not a big deal, but it seems like it could have an easy fix.
Upon further investigation, it seems that OctoPrint is using the filename reported when the print first starts. This is an 8.3 filename:
Send: M27
Recv: Not SD printing
Recv: ok
Send: M105
Recv: echo:Now fresh file: WPC_MI~2.GCO
Recv: File opened: WPC_MI~2.GCO Size: 3052742
Recv: File selected
Recv: Done printing file
Recv: echo:0 hours 15 minutes
Recv: echo:enqueing "M23 wpc_mi~2.gco"
Recv: echo:enqueing "M24"
Recv: echo:Now fresh file: wpc_mi~2.gco
Recv: File opened: wpc_mi~2.gco Size: 3052742
Recv: File selected
Recv: NORMAL MODE: Percent done: 0; print time remaining in mins: 229
Recv: SILENT MODE: Percent done: 255; print time remaining in mins: -1
Recv: NORMAL MODE: Percent done: 0; print time remaining in mins: 229
Recv: SILENT MODE: Percent done: 0; print time remaining in mins: 231
Recv: T:213.7 E:0 W:?
Later, when doing M27 commands, the response reports the full filename (as shown above), but it doesn't seem to get used. It would be awesome if the filename could be updated using the new information.
The other thing that would be a very welcome improvement would be to have the option to use the progress updates from Prusa firmware rather than having to rely on M27. I believe they're embedded in the gcode by the slicer, and for some models, they're much more accurate than the estimate that can be done with the M27 information. That probably a different thread, though.
Anyway, the current issue seems like it could be fixed either by firmware reporting a long name when the print starts or by OctoPrint using the long names that are reported in a M27 response.
Finally, to wrap this one up, I modified my printer's firmware to report the long filename on this line:
Recv: File opened: WPC_Mini_Rev3_x4_0.2mm_PLA_MK3.gcode Size: 3052742
It now gets displayed in OctoPrint, and as a result, also in OctoSlack.
I also submitted a pull request to fix this in Prusa MK3 firmware: