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
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 22.214.171.124 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
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.
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:
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.