OSX: UTF decode error on Umlaut characters

[krizleebear]

Hi, I just tried your tool and I really appreciate it. Unfortunately when Fusion360 is configured to German locale settings, PostProcessAll crashes for flat end mills ("Schaftfräser" in German).

The same happens for English locale when any special (multi-byte) character is in an operation name, see attached screenshot.

Edit: I use Fusion on OSX and Eding CNC as postprocessor and it seems, multi-byte characters are already written defect to the original gcode file. The same happens for GRBL postprocessor as well.

Best regards Christian

[TimPaterson]

What I am understanding is that the regular Fusion 360 post process function is putting garbage in the output when it encounters multi-byte characters. This file then becomes input to PostProcessAll, which chokes on that garbage. I can't think of a way to work around this problem with Fusion 360 except not using multi-byte characters. I'd be interested to know exactly what character code is being put into the file.

[krizleebear]

Thanks for your quick response. I absolutely agree to your interpretation of the problem. I can only guess that other tools ignore these errors in gcode comments, because the issue only appears there. Eding CNC for example shows the characters slightly scrambled, but the rest of the file is OK:

To answer your question: The written bytes for my example "äöü" is: E4 A4 F6 B6 FC BC

This doesn't look right in any encoding I've checked: CP1252, UTF-8, Latin-1, ...

But when I open the file interpreted as "Windows Latin-1" I end up with the same slightly scrambled output as Eding CNC. So I guess all you could do is catch the error, fall back to latin-1 encoding. But I really understand if you just close the issue as 'won't do'.

In the meantime I switched to Windows. Where by the way Fusion is not correctly writing the umlaut characters, but normalizing multi-byte characters to their base characters. E.g. "äöü" to "aou". Or "Schaftfräser" to "Schaftfraser". Really strange.

[TimPaterson]

You could try out different encodings in PostProcessAll to see if it helps. You would need to change line 898 to have a second argument to the open() function, For example, fileOp = open(opPath, encoding="latin_1"). I'm not really a Python expert and have never done this, but that seems to be the way it's done. You can find the names of other Python encodings with an online search. If you make a change to the code, you have to stop and restart the add-in.

[krizleebear]

Thanks for the hint! I've did a bit of online search as well and came to a working fix suggestion for line 898:

fileOp = open(opPath, errors='replace')

Quote from python docs: "'replace' causes a replacement marker (such as '?') to be inserted where there is malformed data." This is in detail described here: https://docs.python.org/3/library/functions.html#open

I've raised a pull request with the suggested fix.

BR Christian

[TimPaterson]

Excellent! It's nice get some help.

[krizleebear]

You're very welcome. And thank you very much for the great work you did on this project! Yesterday I milled several projects with gcode post-processed by your plugin on my Sorotec/EdingCNC mill. It worked flawlessly. I'll raise another PR to update your table :)