Post-Processing error and Standalone error (Unicode Error)

[another3duser]

Hello,

I've been testing the script with PrusaSlicer 2.7.1 (Python 3.12.1) (numpy 1.26.3, matplotlib 3.8.2, shapely 2.0.2, numpy-hilbert-curve 1.0.1) and I've noticed an issue.

When trying to use it with Geetech printers [A10M (2 extruders) and A10Pro (1 extruder)], it seems to throw a "UnicodeDecodeError" both if used manually (via command prompt) on a gcode generated by PrusaSlide or as code on the Post-Processing options. This leads to a failure to edit or output any gcode, respectively. Oddly enough, when performed with Ultimaker printers (Ultimaker2) it doesn't fail.

I've been checking for similar error situations and all seem to point to an encoding issue and utf-8 but I've not been able to implement the fix. Furthermore, there seems to be no similar issue (closed or open) on the matter.

All default configuration parameters for that printer have not been modified (Print, Filament, Printer) except for those significant to the script (Relative E distances and Bridging speeds). See the attached image for more information on the CMD error log (blurred fields are sensitive information).

Update 1: Tested again with the following parameters changed to that which better fits the script's needs: External perimeters first, Avoid crossing perimeters, Infill before perimeters, Bridge speed, Extrusion widths, and Relative E distances. The error persists.

[another3duser]

Update 2: The inspection of the PrusaSlicer's output G-Code reveals several comment lines that have strange characters (see image below), caused by PrusaSlicer not the script itself. After manually replacing all occurences ["placeholder caracters" removed and "lenticular brackets" by square brackets ], the script did run without mayor issues (it was capable of running to completion). Hence, this problem seems to have a "manual" solution. An automatic replacement or additional decoding might be possible with an additional script in the Slicer or with additional lines at the beginning of the script. I haven't explored either yet.

Another two possible issues have popped up after an inspection of the generated G-Code (in Prusa G-Code Viewer): 1) I am usure on the overlapping between hilbert-curves layers and top-bottom laters (see first image below). Compared to other printers that didn't seem to have the "original issue", they seem to generate less of these "overlap layers" (see first and second image below, notice the faint "Bridge infill" colour, different from the "Top solid infill colour"). In addition, there seem to be 2 hilbert-curve layers overlapping into 1 layer (see second image below). However, due to lack of experience in this methodology, I don't know if this is an problem/issue or if this is the script working as intended.

2) Some possible issues in at least one of the hilbert-curve layers. They seem to both protrude differently within the same model. This has been present in both G-Codes with and without the "original issue" (see images below). Again, due to lack of experience, I don't know if this is an problem/issue or if this is the script working as intended.

[cmadson]

Can you post the actual .gcode file with the weird characters? A regular expression removing all the non standard ascii characters outside the range of x20 to x7F would take one line and make the manual editing go away.

[another3duser]

Sure, here it is. The first occurrence should be at line 64, and applies to each layer (251 layers in total for this test).

On a side note,the file has to be uploaded as .txt because it seems .gcode attachments are not possible. Testpart0b.txt

Edit: I forgot to add that the ocurrences are all on comment lines. Hence, should it happen on a non-comment line I am unsure on how severe it would be or how to address it.

[cmadson]

import re import sys

def clean_comment_lines_gcode(input_file_path, output_file_path): def remove_unwanted_ascii_chars(s):

Regular expression to keep characters in the range 32 to 127 and newlines

    return re.sub(r'[^\x20-\x7E\n]+', '', s)

try:
    with open(input_file_path, 'r') as file:
        lines = file.readlines()
except FileNotFoundError:
    print(f"File not found: {input_file_path}")
    return

cleaned_lines = []
for line in lines:
    # Check if the line starts with a semicolon
    if line.startswith(';'):
        line = remove_unwanted_ascii_chars(line)
    cleaned_lines.append(line)

with open(output_file_path, 'w') as file:
    file.writelines(cleaned_lines)

if name == "main": if len(sys.argv) != 3: print("Usage: python script.py ") else: input_gcode_path = sys.argv[1] output_gcode_path = sys.argv[2] clean_comment_lines_gcode(input_gcode_path, output_gcode_path)

[cmadson]

Do you know how to run .py files?

This is a standalone script that will read in a .gcode file and then look at every line that starts with ;. It will then replace any ascii character that isn't printable, except newlines. It writes the file out as a new file when you are done.

/usr/bin/python3 CleanGCODE.py infile.gcode outfile.gcode is how I run it on my UNIX flavored machine.

[cmadson]

On a related note, I updated my python and pyenv to 3.9.18 (latest version for macOS). This resolved my logged error and I can your original file including the weird character with no problem! Thanks for YOUR help!

[another3duser]

Thank you so much for the code and suggestion cmadson. It is indeed a potential fix. However, for implementation, I think I found a significantly simpler and practical solution: open the file with encoding = "UTF-8".(See image below).

As the code only has the "open" function 3 times, it seems feasible to implement but I am no expert on Python, so I can't really say what impact it may have on compatibility or on future-orientation. Still, I have applied it and I can confirm it solves the issue and doesn't seem to impact the functionality. I hope nicolai can come to weight in towards closing this issue.

[cmadson]

You're welcome! I am glad it worked. I didn't intend it as a permanent fix, just a stopgap to verify that the problem you think you were having was actually the problem and if so, to get you on your feet again. Happy Printing!

[Wasupmacuz]

I tested this fix on GCODE sliced for an Ender 3 and it did not affect functionality, alluding to this solution being viable to roll out without any changes. Maybe someone with a printer from another company other than Creality or Geetech could weigh in? By my understanding, the read function uses the default encoding based on the environment (given by locale.getpreferredencoding()), and specifying that it should use UTF-8 should not affect anyone's functionality.