^-
To elaborate on this a bit more, OctoPrint expects file lists from the printer like this:
Begin file list
file1[ size1]
file2[ size2]
...
End file list
So, file size is supported, but optional. File name is supposed to be the file name in 8.3 DOS format, so no whitespaces and ASCII characters only (like all of the communication). If a size is included, it's separated by whitespace and an integer value signifying the size in bytes.
The file listing in the excerpt
Send: M20
Recv: Begin file list
Recv: /ENDER-3/TEST-D~1.GCO 16902701
Recv: /ENDER-3/47ACB~1.MOD/TEST/TEST-D~1.GCO 16902701
Recv: /TRASHE~1/501/CCR10_~1.GCO 2814031
Recv: /TRASHE~1/501/CCR10_~2.GCO 2542570
Recv: /TRASHE~1/501/CCR10_~3.GCO 1773076
Recv: HOUSIN~1.GCO 3676934
Recv: /DRUCKA~1/ENDER_~1.GCO 2583557
Recv: /DRUCKA~1/ENDER-~1.GCO 1421749
Recv: DIAL_I~1.GCO 4701906
Recv: VENTRI~1.GCO 2482277
Recv: TOOL_H~1.GCO 5539180
Recv: ZERO_D~1.GCO 6062417
Recv: LI~1.GCO 930320
Recv: EINLAG~1.GCO 898596
Recv: 608ZZP~1.GCO 2066765
Recv: CABLEC~1.GCO 433879
Recv: E3-COV~1.GCO 4409977
Recv: FILAME~1.GCO 684949
Recv: ENDER_~1.GCO 945825
Recv: PIZERO~1.GCO 1921842
Recv: TRAMMI~1.GCO 17631135
Recv: DECKEL~1.GCO 1440948
Recv: End file list
Recv: ok
looks valid, which is why I asked for serial.log
(and ideally also octoprint.log
) since that might give more clues as to why it's not being used to populate the file list.
I just saw the serial.log
a couple posts up there, and what I noticed in there is that OctoPrint sent an M21
but then when it got the message that the SD card was initialized properly it didn't automatically send an M20
. And that makes it feel like for some reason it didn't parse the SD card ok
message properly and hence didn't even detect that the printer has a card.
Easy way to check: when you click the SD card menu on the file list, does it offer to initialize the card, or does it offer to refresh the files or eject it?
If the former, it doesn't properly parse the SD card ok
message. It should actually not be prefixed by an echo:
but just be on its own line (example from the virtual printer):
Changing monitoring state from "Opening serial port" to "Connecting"
Recv: start
Send: N0 M110 N0*125
Recv: Marlin: Virtual Marlin!
Recv: �
Send: N0 M110 N0*125
Recv: SD card ok
Recv: ok N0
Changing monitoring state from "Connecting" to "Operational"
Send: N0 M110 N0*125
Recv: ok N0
Send: N1 M115*39
Recv: ok N0
Send: N2 M20*19
Recv: FIRMWARE_NAME:Virtual Marlin FIRMWARE_URL:https://github.com/prusa3d/Prusa-Firmware PROTOCOL_VERSION:1.0 MACHINE_TYPE:Prusa i3 MK3 EXTRUDER_COUNT:1 UUID:00000000-0000-0000-0000-000000000000
Recv: ok N1
Recv: Begin file list
Recv: 20MM-B~1.GCO
Recv: 20MM-B~2.GCO
Recv: 20MM_C~1.GCO
Recv: CONFIG.TXT
Recv: HEATUP~1.GCO
Recv: ONLY_HOME_TXT.TXT
Recv: ONLY_H~1.GCO
Recv: PRUSAT~1.GCO
Recv: TEST20~1.GCO
Recv: TESTON~1.GCO
Recv: TRISPI~1.GCO
Recv: End file list
Recv: ok N2
The way the parser here works though should still see it regardless, and a quick test (changing the virtual printer to report it with the echo:
prefix) also shows everything works as expected.
In general, things work like this:
- OctoPrint connects to printer
- OctoPrint issues an
M21
(unless the printer has already reported SD card ok
on its own)
- Once
SD card ok
is received OctoPrint issues an M20
- OctoPrint sees
Begin file list
and switches to file list parsing mode
- Unless received line is
End file list
, OctoPrint splits it on whitespace. First (only?) entry is file name. If there's a second it tries to parse that as file size
- OctoPrint sees
End file list
, switches out of file list parsing mode and signals that a new list was received to the system
- The UI refreshes the file list in the frontend