Long names issue (limit with Marlin FW)

[Jordan87]

Hi

From one of Marlin firmware modders i received information that Marlin FW is limited to 96 characters. Are we able to limit names or show some notification that we exceeded 96 characters?

In my case :
PrinterMount PLA 0.2mm 20% 190.0C 50C Liczba obiektow 2 Czas 014011 Podpory 1234.gcode was not able to start printing,
after removing one digit on the end there was no problem with printing
PrinterMount PLA 0.2mm 20% 190.0C 50C Liczba obiektow 2 Czas 014011 Podpory 123.gcode

Discussion where i was asking about this issue :)
mriscoc/Ender3V2S1#163

Thank You!

[rgomezjnr]

Hi Jordan,

I'm realizing this is becoming a more common issue since people are creating more detailed and lengthy filenames and hitting their printer's gcode filename length limitations. I will work on restricting the generated filename length by limiting unnecessary characters like trailing zeros .0, and possibly implementing a max character length restriction which simply cuts off extra chars.

[Jordan87]

Maybe limitation is only needed for printing via octoprint, same name from SD was working. ;)

[rgomezjnr]

Maybe limitation is only needed for printing via octoprint, same name from SD was working. ;)

That is strange and counter to what @mriscoc described in mriscoc/Ender3V2S1#163

@mriscoc does the gcode filename actually need to be a few characters less than 96 considering additional gcode commands that are sent to the printer?

@Jordan87 Can you try reprinting the initial long filename using Octoprint and setting the Ignore warning option as described in https://github.com/mriscoc/Marlin_Ender3v2/wiki/Octoprint#error-handling

Maybe what you are seeing is a Marlin firmware bug, that's reported by Octoprint as a checksum mismatch.
This is described in https://community.octoprint.org/docs?search=filename&topic=240#headline--cannot-select-sd-file and MarlinFirmware/Marlin@2d22902
@foosel is this relevant here or not?

All in all it's probably still a good idea to restrict the filename length generated by GFF+ to a reasonable maximum.

[mriscoc]

Hi, the limit is in the buffer that receive the command trough the serial interface:

[Jordan87]

@Jordan87 Can you try reprinting the initial long filename using Octoprint and setting the Ignore warning option as described in https://github.com/mriscoc/Marlin_Ender3v2/wiki/Octoprint#error-handling

As I understand this will only prevent from M112 error (Emergency stop) but error on serial port will be still present.
But if you really want me to do this I will check it :)

[rgomezjnr]

Ok so the 96 char buffer limit only applies to the serial interface, which is why @Jordan87 is able to print the same original long filename via SD card but not using Octoprint?

@mriscoc what would be a reasonable max filename length, considering a portion of the serial command buffer needs to be preserved for Gcode commands when using Octoprint? I'll do some research. Would it be around 80-86 chars considering "N1 M75 PrinterMount PLA 0.2mm 20% 190.0C 50C Liczba obiektow 2 Czas 014011 Podpory 1234.gcode*100"?

[mriscoc]

Ok so the 96 char buffer limit only applies to the serial interface, which is why @Jordan87 is able to print the same original long filename via SD card but not using Octoprint?

@mriscoc what would be a reasonable max filename length, considering a portion of the serial command buffer needs to be preserved for Gcode commands when using Octoprint? I'll do some research. Would it be around 80-86 chars considering "N1 M75 PrinterMount PLA 0.2mm 20% 190.0C 50C Liczba obiektow 2 Czas 014011 Podpory 1234.gcode*100"?

To be safe consider 80 chars as maximum size.

[rgomezjnr]

@mriscoc Ok thank you for the input I will implement a way to allow users of GFF+ to limit the generated gcode filename to 80 chars.

[rgomezjnr]

@Jordan87 Here's what I have working now, showing the spinbox with tooltip on mouse hover. I set the maximum value of the spinbox to 255 based on discussion in https://stackoverflow.com/questions/265769/maximum-filename-length-in-ntfs-windows-xp-and-windows-vista. Let me know if you have any feedback before I release this.

[Jordan87]

Hi

Sorry for late response.
This should be enough :)

The best would be to have some notification during sending file to octopi with button "Print with OctoPrint" but im sure its more complicated to do this.

Thank You

[rgomezjnr]

Thanks for the feedback.

The best would be to have some notification during sending file to octopi with button "Print with OctoPrint" but im sure its more complicated to do this.

Do you mean in lieu of or in addition to the Filename length limit? I don't think it would be that much more work to show a notification but I'm trying to understand why you would want a notification (which might just be nice to know) if the filename needs to be truncated anyways, otherwise the print won't work. Would you want to modify the filename format if the limit is exceeded?

You might be interested in the Octoprint plugin OctoPrint-IFTTT which I think can also create notifications.

https://github.com/tjjfvi/OctoPrint-IFTTT/wiki

To customize things like the notification text, you can use values.

https://docs.octoprint.org/en/master/events/index.html#file-handling

File handling
Upload
A file has been uploaded through the REST API.

Payload:
name: the file’s name

[Jordan87]

Notification about exceeded name limit in your plugin will make us aware that we will lost some info from file name. Notification and possibility to modify [base_name] would be ideal solution I think :)

[rgomezjnr]

I'll look into adding a notification, shouldn't be too difficult. Changing the filename format or job name after the slicing has been performed is more difficult since this involves updating the format or job name using a signal which I haven't added yet. This is an issue in the current version of GFF+. The only way around it currently is to change the format or job name, then manually re-slice the object.

[rgomezjnr]

Jordan what do you think of this notification? The message shows once the Slice button is clicked. Currently debugging an issue that's causing too many messages to spawn.