[FR] format the gcode to ascii only

[sprior]

What happened?

I tried to slice the knomi v2 Stealthburner files in SS, when I sent the gcode to the printer I got a pause notification. klippy.log shows: Starting SD card print (position 0) virtual_sdcard read Traceback (most recent call last): File "/home/pi/klipper/klippy/extras/virtual_sdcard.py", line 237, in work_handler data = self.current_file.read(8192) File "/home/pi/klippy-env/lib/python2.7/codecs.py", line 314, in decode (result, consumed) = self._buffer_decode(data, self.errors, final) UnicodeDecodeError: 'utf8' codec can't decode byte 0xe5 in position 4019: invalid continuation byte Exiting SD card print (position 32688)

I suspect the issue is related to unicode characters in the STL filenames. I tried this in Orca slicer and it worked fine.

Project file & How to reproduce

project.zip

Attached is a zip with the klippy.log, 3mf, and gcode files

Version

2.5.59.6

Operating system

Windows 11

Printer model

voron 2.4 with Stealthburner

[supermerill]

A problem with with the utf name, yes.

; object:{"name":"KNOMI 2 Mounting Plate固定卡环","id":"KNOMI 2 Mounting Plate固定卡环.stl id:0 copy 0","object_center":[209.792381,172.939887,0.000000],"boundingbox_center":[209.792381,172.939887,2.600000],"boundingbox_size":[39.666000,40.982002,5.200000]}
EXCLUDE_OBJECT_DEFINE NAME=KNOMI_2_Mounting_Plate基埚埧Ž_stl_id_0_copy_0 CENTER=209.792381,172.939887 POLYGON=[[189.96,173.90],[189.97,173.46],[189.98,173.06],[

as you can see, the second one is botched. Fixed in next nightly.

btw, you have an error in your filament profile compatible_prints_conditions: printer_model=~/.*Voron.*/ (printer_model is only available for compatible_printers_condition, obviously)

[sprior]

Since I name my print profiles with the printer name would it be correct in the compatible_prints_conditions to have: print_settings_id=~/.Voron./

I'm a little surprised what I had before worked and didn't mess things up if it wasn't correct.

[supermerill]

Since I name my print profiles with the printer name would it be correct in the compatible_prints_conditions to have: print_settings_id=~/.Voron./

I think so.

I'm a little surprised what I had before worked and didn't mess things up if it wasn't correct.

It just ignore it if it's not applicable. To see the errors, you can open the _console.exe in a cmd prompt.

[sprior]

I downloaded the latest nightly for win64 and tried it again with the same filenames. It still crashed Klipper though the error message changed so I guess that's progress :-)

[supermerill]

mmm It seems like your app try to parse the gcode as an ascii file, and the superslicer creates an utf-8 one. Any special character won't be able to be read by this app. I can add a setting to remove any no-ascii character?

it's weird. in your first message, it says it uses an utf-8 'codec', and now it says it suses an 'ascii' one... not the same app?

[sprior]

I'm not totally sure what you're referring to as "my app" here. SS is reading the STL files and sending it directly to my Voron running Fluidd/Moonraker/Klipper - is "my app" you're mentioning Fluidd/Moonraker/Klipper?

The only thing I changed from my first message to the second was switching to the latest nightly of Super Slicer and applying the github updates to Fluidd/Moonraker/Klipper, I have not made any config changes to my system at all.

Since Super Slicer is just outputting the gcode file to send to the printer I am ok with SS making any required filename changes that would make the result acceptable to Fluidd/Moonraker/Klipper. I assume this is what Orca Slicer does because that worked with the same input STL files and the printer had no issues printing the resulting gcode file.

I'll also mention that I am not the person creating the files with the UTF characters in the filenames, in this case I was simply downloading the STL files as is from the Knomi 2 github page. So I wouldn't even bother making it a setting to remove any non-ascii character because it's not something the user necessarily thinks they are doing, feel free to just go ahead and do it if that is necessary to make it acceptable to Klipper.

[supermerill]

yes, I was talking about your Fluidd/Moonraker/Klipper chain.

Seems like klipper is okay with utf-8 gcode. But fluidd is not.

[sprior]

Should I start a discussion on the Fluidd side (you may know the maintainer better than I do)?