I’m reporting this for some of my users who are having problems printing some files based on the file name. It appears to be a broad klipper issue, not focused on a specific printer.
Describe your issue:
Klipper gets angry about files with # in the name of the gcode. # is a legit character on windows, mac and linux for a filename. I recognize it’s somewhat unusual, but my project (OpenForge) has thousands and thousands of files, so I’ve used a number of different delimiters in file names to split between different pieces of information, and # has only thus far broken on klipper machines.
I recognize this is almost certainly being parsed as a comment, so my hope here is that klipper would at least recognize that the file name will break, and do a character replace on the # or error.
This is a general problem with the parsing of extended g-code commands, not specific to filename handling. One way to avoid it is to use standard codes (e.g. M23) instead.
While this might be true, I guess everyone old enough to know what a traditional 8.3 filename is gets cold shivers just thinking about it. Not everything that is legitimate needs to be used. Nuclear weapons are kind of legitimate too …
But I agree; it should either work or be mentioned that it does not.
Hard to fill out the template when it’s a bug for a printer that isn’t yours. I get the frustration, I’m in tech as well, but all I had from them was the screenshot I posted
Unfortunately, further follow-up is only possible with the log showing the issue. As mentioned by @flowerysong, the bug might already be fixed, and all the user needs to do is update their Klipper version.
Hi guys. My version was v1.2.3.1. I hadn’t thought to do another update, so apologies for that. I updated to 1.2.3.4 and the current UI as well. Files with # still not working. Printer freezes at the “preparing to print” screen and another console error.
I’ve requested his klippy.log and I’ll update the issue when I get it, but he did screenshot the failure, so I’m attaching that
I answered this. I’m not the machine owner, I run an stl patreon, and it’s failing on one of my files. I’ve asked the patron to provide a klippy log, and will add it when he gets back to me.
I note from his first comment that it’s an Elegoo Neptune 4 Max, so that’s probably their version number. I’ll pass on the version it was fixed in on the klipper side. And hopefully get him to furnish a klippy.log. He may need to file a ticket downstream to them to get them to update.
Elegoo ship a customized version of Klipper and do not appear to track their changes publicly, but looking at the most recent major version of the firmware for this machine it appears it may be based on a version of Klipper from 2021. Your user should contact Elegoo for support.
oh, totally, as soon as I got the information that it was an Elegoo printer, I more or less told the patron that he has to take it up with them.
I have a second patron who uses a voron (I myself have a trident), and knowing that his klipper wasn’t up to date fixed it for him. I appreciate the help, knowing that there even was a fix and that it’s on Elegoo let me close out the ticket on my side.
I have, as noted, he hasn’t responded with one. Learning that it was Elegoo and that they are shipping with a customized Klipper version let me pass that information on to him and close the issue out on my side.
