M20 command cuts file names down to 8.3 format

[bortek]

God bless MS-DOS but we do not want it here. :)

If you issues M20 command to list the files on the SD card , the returned list contain names which are cut down the length of 8 characters for filename and 3 characters to file extension. Here is an example

Send: M20
Recv: Begin file list
Recv: QUADCO~1.GCO
Recv: LAMPSK~1.GCO
Recv: GERLIT~1.GCO
Recv: End file list
Recv: ok

So was in older Windows versions when dir command issues in command prompt truncated long file names.

Can this be fixed in this project so we can upstream fix it in the Ultimaker2 firmware?

[boelle]

its beeing worked on... cant remember the issue no of my head but can look for it

[bortek]

would be great if you can look it up for me. Thanks!

[boelle]

could not find anything direct, the most close is this one:

https://github.com/ErikZalm/Marlin/issues/1232

but hmm dont know why a bell is ringing in my head.... i total agree that long filenames should be added at some point

[bortek]

Well, maybe this point has already come and it is time to go from legacy 8.3 names to long file names, don't you agree ? ;)

There is another project on GitHub called Octoprint. It is a web application to manage printer jobs. It uses M20 command to list files and display then in the GUI. It looks really creepy, no way to distinguish what file am I printing especially in files are named like this, if you understand what I mean.

SomefileName
SomefileNameVer2
SomefileName1Edited

How can we make this fix happen ?

[boelle]

well, i'm not a code writer, more like a manager.... trying to keep things going and not stall :-)

what we need are more code writers that have time to spare...

currently we are bug fixing thou, we want a clean and stable marlin before we add features..

[bkubicek]

If it is intendet to have long filenames at a m20 display, it is obligatory
to have this also at M23.
Additionally, compativility with nearly all existing host software has to
be checked, as they might assume special filename patterns.

Then also, M32 /path/filename#", or "M32 S !filename#" need
to be adopted to cope with unfdefined memory lengths.

Long filenames are horrible as we try to work on a very very memory limited
platform, and assumptions about string lengths is essential to have
pre-determined memory usage.

I would prefer to leave this untouched, as it can easily break
compatibility and might lead to patent problems ....

Bernhard

On Mon, Dec 29, 2014 at 1:51 PM, Bo Herrmannsen notifications@github.com
wrote:

well, i'm not a code writer, more like a manager.... trying to keep things
going and not stall :-)

what we need are more code writers that have time to spare...

currently we are bug fixing thou, we want a clean and stable marlin before
we add features..

—
Reply to this email directly or view it on GitHub
https://github.com/ErikZalm/Marlin/issues/1263#issuecomment-68254844.

[boelle]

if not mistaken in issue 1232 somesone said that the germans are safe

i assume that in germany there are no patent issues then... and since marlin firmware resides within the EU that means we dont have a patent problem...

[boelle]

but yes.... if this is implemented we have to be very carefull not to break anything

[bortek]

I could not foresee that such an harmful feature could create so many problems :) Anyhow it is up to you to decide when and if to implement it, but it would be "really good" to have it done.

How about implementing new command that would do the job and list the files using long names? That way you would not break anything ?

[galexander1]

The AVR processor at the core of most Marlin installations has less
memory than the MS-DOS machine you probably had circa 1990. That's why
it uses the DOS "FAT" filesystem, which has 8.3 filenames and is very
easy to decode.

The longer filenames are stored in a separate name translation file.
That separate file can potentially be quite large, so practically
speaking, Marlin can't read the whole thing into memory for easy
reference. So in order to decode a long filename, it has to start over
at the beginning of the translation file and look at all of the entries
in there until it finds the one it needs to display. Then it would have
to repeat all of that work for each subsequent filename. On large
directories, it would be palpably slow.

A number of hacks can speed it up, but they make the code even more
complicated and delicate, and no hack can actually be efficient for large
directories. It's very tempting to go with one of these hacks, but then
the first time someone has a directory with 100 files in it, the hack
falls all over itself, that's why I call it a hack.

This is a recurrent philosophical question in Marlin development,
especially because there are more powerful ARM-based boards beginning to
proliferate.

But on the AVR boards, Marlin really has to act like an embedded system.
Almost all of the stuff for user convenience (like long filenames, sorted
filename lists, total extrusion length computations, etc) should really
be done on the host PC. The robot translates a G-code file into physical
motions and that is all. It doesn't have capacity to push around
thousands of bytes at a time like every other computer in your life can.
The AVR is much less than your cellphone, or even a modern car stereo.

[boelle]

we learn every day :-D dont take that negative, i'm really positive here

and i think @ErikZalm told me that one of the goals was to be able to still run marlin on a 644 based board with basic stuff like 1 extruder etc

so the only way i can see this done is to add a raspberry pi to the mix and print from that one and store the gcode files on it.... of course then the LCD is reduced to just a local monitoring thing...

but off topic on the LCD, maybe someone have figured out to connect the LCD to the pi with octoprint and use it to select stuff local?

[nophead]

The longer filenames are stored in a separate name translation file. That separate file can potentially be quite large

No they aren't. They are stored in small chunks in the directory as hidden volume id records, in reverse order IIRC. You need a buffer long enough to reconstruct one long name and a buffer for the directory records, but you need that anyway as they are the same size as the 8.3 entries.

[galexander1]

Wow, you're right. They're even defined to be interleaved -- hidden
files occur right before the short file in the directory entry. I'm not
100% sure but there probably is a decent hack that will allow the
reasonable use of vfat long filenames with only one filename in memory at
a time.

I was wrong. :)

I don't have SD so I am not a good choice for this development, but I
kind of expect Scott to speak up at any moment....?

[scotty1024]

8.3 file names are what are used in FAT file systems. The long file names are an extended attribute added (via a kludge) to the file but it's true file name is still the 8.3 name.

These MS-DOS 8.3 names are great for today's Atmel AVR CPU's as they generally have less memory than even a first generation IBM PC.

When you have 8K of memory: God bless 8.3 file names.

On Dec 29, 2014, at 4:13 AM, bortek notifications@github.com wrote:

God bless MS-DOS but we do not want it here. :)

If you issues M20 command to list the files on the SD card , the returned list contain names which are cut down the length of 8 characters for filename and 3 characters to file extension. Here is an example

Send: M20
Recv: Begin file list
Recv: QUADCO1.GCO
Recv: LAMPSK1.GCO
Recv: GERLIT~1.GCO
Recv: End file list
Recv: ok

So was in older Windows versions when dir command issues in command prompt truncated long file names.

Can this be fixed in this project so we can upstream fix it in the Ultimaker2 firmware?

—
Reply to this email directly or view it on GitHub.

[bortek]

Considering how much dependency has this change involves and what I understood from the discussion above it is best to not implement this, at least not right now. Therefore I will close the bug for now. Thanks for your input.

[HedronUser]

Wish I could see what commit/code change fixed the SD filename truncation issue. This or something related is causing M23 to fail/work on my Melzi 1284.

[thinkyhead]

@HedronUser It would be hard to track down exactly one change, as there have been several to the SD card code since this issue was originally posted. But we can start from where the code is now and try to solve your problem. Do you want to post a new issue about it?

[GrueMaster]

Just found this thread and I am puzzled. I have two printers (Hictop 3DP-17 and CR-10S), both have different firmware (Hictop has Marlin 1.1.0-RC8 - haven't updated to 1.1.5 yet, and CR-10S has stock firmware). Both have no problem displaying long names on the display (truncated to 40 character display width). Since the displays are going through the Arduino boards to read the SD, there must be something there you can use.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.