It could be under planning - it was added to the docs a few days ago, and may be related to this post:
I guess we'll see what happens.
M20 L support is now in Marlin bugfix-2.0.x and the fix has been merged into the 2.0.x branch, so it should be in 2.0.9.2 when that's released.
I enabled this and it works for files written to the SD by a PC but not those written by Marlin. Presumably a Marlin problem, but Octoprint then displays ??? for the filename. Shouldn't it display the 8.3 filename if it gets ??? from M20 L?
We would have to see the full communication from a serial.log to work out what is going on there. From OctoPrint's perspective, I guess it looks like the printer has told it the filename is ????, it may not know this is not the actual filename.
Send: M20 L
Recv: Begin file list
Recv: TOPCAP_E.G 1099868 ???
Recv: USB_CA~1.GCO 511242 ???
Recv: LOWERB~1.G 3668226 lowerbrkt_export.g
Recv: End file list
Recv: ok
Yes, Marlin doesn't seem to know the long name so presumably it can only read long names and not write them. But OctoPrint should display the 8.3 name if it gets ??? as the long name from marlin.
This is what it displays:
Looks like Marlin will write long filename in the bug fix branch.
Good to know that it works properly in bugfix.
The thing with
Is that there is no standard way of saying that it can't read the filename. To a machine, it doesn't know that that is not the intended result. We could add a special case for three question marks, but what if someone names their file like that? Or the next version of the firmware sends out 'ERROR' or something.
I don't think a file can be named ???, but even if it was it wouldn't have a short name of USB_CA~1.GCO preceding it. The two names have to be equivalent for a valid long name.
I updated my firmware to the latest Marlin bugfix branch which has the capability to write long filenames:
Recv: Cap:LONG_FILENAME:1
Recv: Cap:LFN_WRITE:1
However, Octoprint seems to send an 8.3 filename when writing, so it still doesn't work.
Send: M28 /usb_ca~1.gco
Recv: echo:Now fresh file: /usb_ca~1.gco
Recv: Writing to file: usb_ca~1.gco
Changing monitoring state from "Operational" to "Sending file to SD"
Instead of sending ??? this version of Marlin repeats the 8.3 name, so that is better.
Send: M20 L
Recv: Begin file list
Recv: TOPCAP_E.G 1099868 TOPCAP_E.G
Recv: USB_CA~1.GCO 511242 USB_CA~1.GCO
Recv: LOWERB~1.G 3668226 lowerbrkt_export.g
Recv: End file list
Another OctoPrint problem I noticed is the first time it sends M20 it doesn't pass the L flag, so it produces an 8.3 list. I have to refresh the file list to get it to send M20 L and list the long names.
I'm wondering if the capabilities report here changed in Marlin. I thought it is was EXTENDED_M20, not LONG_FILENAME, and assuming the new LFN_WRITE is not being accounted for by OctoPrint when sending the file since that is new.
Yes looking at comms.py: OctoPrint is looking for EXTENDED_M20 to decide whether to send the L. Marlin also sends that.
Recv: Cap:EXTENDED_M20:1
It seems Cap:LONG_FILENAME means M33 is supported and OctoPrint ignores it.
The LFN_WRITE capability was merged into the bugfix-2.0.x branch of Marlin in January this year, so it does seem to be new.
I have haven't updated OctoPrint or Marlin for many years until now. I don't understand how a Marlin bugfix branch would have new features in it compared to the last release.
Looking at the code in comms.py my best guess as to why the first M20 doesn't include an L is because the commands are queued, so perhaps the M20 command is built and added to the queue before the preceding M115 results have been parsed and the capability set.
M20 and M33 do not the same.
M20 throws out a file list, M33 gives a long filename for one file or a folder:
https://reprap.org/wiki/G-code#M20:_List_SD_card
https://reprap.org/wiki/G-code#M33:_Get_the_long_name_for_an_SD_card_file_or_folder
If you have M20 L, why would you need to use M33?
As far as I can see Cap:LONG_FILENAME:1 indicates M33 can be used but I don't think OctoPrint looks for that capability and I don't think it uses M33.
Because they are not the same (as mentioned above).
- M33 is only supported by Marlin
- Using of M33 is more complicated:
-
- Getting the SD file list
-
- Going through the list and request every long file name from the firmware
If M20 L sends the list of files with both the short and long names, why do you need M33? You have all the loing names. The only comments I can find for M33 is @foosel saying it doesn't scale as you have to call it for every file.
My only issues are that the first M20 after connection is missing the L parameter and when writing files OctoPrint sends the short name regardless of Recv: Cap:LFN_WRITE:1 which indicates Marlin will accept long names for writes.
Who said you have to use it?
I use neither M20 nor M33. I print, as it is intended, directly from OctoPrint.
On my LulzBot TAZ 6 (with LulzBot's Marlin 2.0.9.0.13 firmware), M20 and M20 L return only the 8.3 filenames but M33 returns the long file name. LulzBot probably doesn't have the right options selected.
1 Like
But does Octoprint display long files name by running all the 8.3 results from L20 though M33?
No, OctoPrint doesn't do anything with M33.