Isn't this the one we did a single file plugin in Discord on to rewrite the M20 command? I don't think we ever heard back if that worked or not.
Nothing specific that I can find, but if there is something specific you are after I'll see what I can hunt down?
It is, that was the competition for smallest plugin...
It should work, when we looked into it at the time it seemed OctoPrint could parse the response but wouldn't send M20 L.
According to the wiki link above, there's Cap:EXTENDED_M20. Not able to confirm if it actually comes through from the firmware.
M20 yes. M20 L no. The wiki doesn't list the support for individual parameters. Without the L, the files are reported in 8.3 format, this is what is widely supported. From the information we know, it's Marlin's bugfix branch (which will be 2.0.9+) and Prusa FW 3.10 (or whatever the latest version is).
Well, here we go then:
Adjusted the virtual printer accordingly, works fine with that, no idea if firmware out there actually matches the format as described on the wiki (side note: even after I documented the response format MYSELF on the wiki, Marlin or whoever added quotes to the long name to make it just enough incompatible to require code adjustments on my end after all - I can't even...). That's for someone with a current Marlin bugfix or Prusa FW build to test, I right now have neither and can't say when I'll get around to changing that.
The current code in Marlin bugfix does not support M20 L nor do I see any pending PRs to add it.
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.
