Is there any reason, or objection too I guess, to adding support for M20 L command to OctoPrint? Most printers support this compared to M33, and it returns both the short and long filename vs only the long on the M33 version - and is essentially almost a drop in replacement for the existing M20 command ...
Hello @Neillans !
You may read: Releases · OctoPrint/OctoPrint · GitHub , V 1.5.0, #1600
Also, as for the marlin homepage, the L parameter is just supported from 2.0.9 and on.
The L parameter was new in the latest Prusa firmware, and available in the development version of Marlin. Far from wide support, but it's on the list.
1 Like
True, but versions are identifiable and it's a probably a switchable feature. Additionally, it's wider support when compared with M33 - G-code - RepRap vs G-code - RepRap
Is there a capability report for the support of the L parameter?
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.