Better long filenames support

[arekm]

As mentioned in https://github.com/repetier/Repetier-Firmware/issues/103 repetier firmware implements long file name support.

What we miss now is

1)

M20 L

support as in https://reprap.org/wiki/G-code#M20:_List_SD_card + reporting EXTENDED_M20 capability. Octoprint uses that to show long file names to user.

2) Also M23 handling long file names.

3) If that's possible supporting longer file names than 26 characters. Current SdFat library version mentions 255 as limit: https://github.com/greiman/SdFat/blob/master/src/SdFatConfig.h#L187

PrusaSlicer by default issues 30/40+ character filenames.

4) Not sure about displaying long filenames on LCD (if that's implemented currently or not)

5) Something else?

My use case:

• M20 L - so user knows which file is which (if files on sd card have long file names)
• M23 - octoprint using sdcard API can upload long file names to sd card but then it also tries to use M23 which fails:

  2022-08-03 00:55:25,608 - Send: N13 M20*35
  2022-08-03 00:55:25,770 - Recv: Card successfully initialized.
  2022-08-03 00:55:25,774 - Recv: ok 13
  2022-08-03 00:55:25,784 - Recv: Begin file list
  2022-08-03 00:55:25,794 - Send: N14 M23 /banana plug spacer flat_0.3mm_PETG__2m.gcode*60
  2022-08-03 00:55:25,810 - Recv: BANANA~1.GCO 113118
  2022-08-03 00:55:25,821 - Recv: End file list
  2022-08-03 00:55:25,836 - Recv: ok 14
  2022-08-03 00:55:25,875 - Recv: file.open failed

[repetier]

File name length is defined by MAX_VFAT_ENTRIES and that gets multiplied with 13. Defaults are 2 for avr and 3 for due boards. Reason is memory usage as we need to reserve buffers with these length for maximum folder depth. But especially on due you can increase it to 4 or 5 I think. Too long names make no sense as input parsing buffer is limited to 96 chars and it also contains the command, line number, checksum so 255 byte file name would never work even if enabled. Doesn't it actually fall back to 8.3 on longer names so it gets no issues with too long names?

What we actually expect is to receive exactly the name we send on M20 request, so host software just needs to take it 1:1 - if it first in long version we show it in long.

Since we behave differently as marlin the L is not needed and advertising it changes something would be wrong. Also our output format is slightly different - we have filename length. No timestamp no extra second file name. And of course all old printer will never update to get new behaviour. So in your plugin you need to distinguish which firmware you are talking to I fear. I know it sucks a bit from my own host development, but any change always means you need to support the old solution in addition to new solutions.

[arekm]

Yes, gets truncated to 8.3.

For me M20 always shows short filename even if it fits in 26 characters limit.

24characters-fname.gcode -> Recv: 24char~1.gco 408

Thanks for explanation. Closing.

[repetier]

Might be because of the extension not fitting 3 chars. I'm not so confident with the solution as it was an addition form someone else at a time where sdfat did not support long names. On V2 I will double check to work better. Just upgrading it to sdfat 2.2 and rewriting sd handling.