Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UnicodeDecodeError on files with BOMs #1077

Closed
xflowx opened this issue Oct 1, 2015 · 8 comments
Closed

UnicodeDecodeError on files with BOMs #1077

xflowx opened this issue Oct 1, 2015 · 8 comments

Comments

@xflowx
Copy link

xflowx commented Oct 1, 2015

After upgrading to version 1.2.6., everytime i start a print i get the following error:

UnicodeDecodeError: ''ascii' codec can't decode byte 0xef in position 0: ordinal not in range(128)' @ comm.py:startPrint:600

seems to have something to do with the encoding.
with the old version(>1.2) these gcode files worked.
Also, new uploaded files wont work, everytime the same error

@GitIssueBot
Copy link

Hi @xflowx,

It looks like there is some information missing from your ticket that will be needed in order to process it properly. Please take a look at the Contribution Guidelines and the page How to file a bug report on the project wiki, which will tell you exactly what your ticket has to contain in order to be processable.

If you did not intend to report a bug, please take special note of the title format to use as described in the Contribution Guidelines.

I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next two weeks (until 2015-10-15 20:50) I'll close this ticket so it doesn't clutter the bug tracker. This is nothing personal, so please just be considerate and help the maintainers solve this problem quickly by following the guidelines linked above. Thank you!

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being, so don't expect any replies from me :) Your ticket is read by humans too, I'm just not one of them.

@xflowx
Copy link
Author

xflowx commented Oct 1, 2015

Printer: K8200

<script src="https://gist.github.com/xflowx/743f6076430822fc61ae.js">Terminal</script>

Log says nothing about this error

@xflowx
Copy link
Author

xflowx commented Oct 1, 2015

terminal output:

Send: M105
Recv: ok T:22.0 /0.0 B:21.0 /0.0 @:0 B@:0
Send: M105
Recv: ok T:22.0 /0.0 B:21.0 /0.0 @:0 B@:0
Send: M105
Recv: ok T:22.0 /0.0 B:21.0 /0.0 @:0 B@:0
Send: M105
Recv: ok T:22.0 /0.0 B:21.0 /0.0 @:0 B@:0
Send: M105
Recv: ok T:22.0 /0.0 B:21.0 /0.0 @:0 B@:0
Send: M105
Recv: ok T:22.0 /0.0 B:21.0 /0.0 @:0 B@:0
Send: M105
Recv: ok T:22.0 /0.0 B:21.0 /0.0 @:0 B@:0
Changing monitoring state from 'Operational' to 'Printing'
Changing monitoring state from 'Printing' to 'Error: UnicodeDecodeError: ''ascii' codec can't decode byte 0xef in position 0: ordinal not in range(128)' @ comm.py:startPrint:600'

@foosel
Copy link
Member

foosel commented Oct 2, 2015

Please provide an example GCODE file with which that can be reproduced. Not copy pasted, really upload the exact file and link it here.

Also always provide the log. There is more information about your setup in there, not just about the error, and it also happened in the past that people didn't provide it, told me there was nothing in it, then when they finally did provide it it turned out there was a hint in there they didn't recognize as such. There is a reason the bug reporting template asks for this, untruncated.

@xflowx
Copy link
Author

xflowx commented Oct 2, 2015

here is the log file:
http://outerspace-astronomy.de/octoprint/octoprint.log
and here one example gcode
http://outerspace-astronomy.de/octoprint/top_raspi_logo.gcode

this file printed well before upgrading!

@foosel
Copy link
Member

foosel commented Oct 2, 2015

this file printed well before upgrading!

Yes, you already said that, no need to get agitated :)

You also stated that you had upgraded from a version ">1.2" when in fact the log shows that the last version before 1.2.6 was 1.1.1, so in fact "<1.2", which is very important information when trying to figure out why it started to produce errors after you upgraded...

The error is caused by UTF-8 BOMs in your files. They all start with a magic number basically. Your old version of OctoPrint still had a bug that basically sent all lines as is from the file, without sanitizing them first. The printer communication protocol actually states that only ASCII encoding is allowed, so this was wrong and got fixed in 1.2. It however hiccups hard on a BOM which it should just ignore (although a BOM shouldn't be in that file in the first place, it should not be encoded in UTF-8...). I will fix that in the code, you should however definitely try to figure out why your slicer is producing BOMed files - I have not seen this in the wild so far, certainly not during my own excessive testing across operating systems, so something is off here in your workflow.

@foosel foosel changed the title UnicodeDecodeError UnicodeDecodeError on files with BOMs Oct 2, 2015
@xflowx
Copy link
Author

xflowx commented Oct 2, 2015

I also already thought that it has something to do with BOM's, i also fell a few times over them.. ;-)

The gcode comes out directly from Repetier using Slicer, with the "save gcode" icon used....

I'll find out where the BOM's come from and will keep you informed!
Thanks for the quick answer on that!

Oh, and sorry for that wrong sign before the version number, i definitely should not drink beer while working;-)

foosel added a commit that referenced this issue Oct 5, 2015
Also detect files that contain a BOM and strip it.
Internal handling of GCODE file contents switched to unicode.

 Should take care of #1077
@foosel
Copy link
Member

foosel commented Oct 5, 2015

Fixed in devel and maintenance, will be part of 1.2.7 release

@foosel foosel closed this as completed Oct 5, 2015
@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants