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

RC1.3.6rc1 Error:checksum mismatch #2262

Closed
JohnOCFII opened this Issue Dec 4, 2017 · 6 comments

Comments

4 participants
@JohnOCFII

JohnOCFII commented Dec 4, 2017

When reporting a bug do NOT delete ANY lines from the template but
those enclosed in [ and ] - and those please DO delete, they are
only provided for your information and removing them makes your
ticket more readable :)

(Before submitting your ticket, please delete this text up to and
including the line too - it's only here for you, we already know it
by heart ;))


What were you doing?

Printing a 3+ hour print. Print had been in progress for 2+ hours.

What did you expect to happen?

Expected print to complete successfully.

What happened instead?

Print stopped with Error:checksum mismatch error.

Did the same happen when running OctoPrint in safe mode?

Have not tried Safe Mode. Figured that getting the RC issue posted was more important. I've completed at least 4 successful (but less than 2 hour) prints with 1.3.6rc1.

Branch & Commit or Version of OctoPrint

OctoPrint 1.3.6rc1 running on OctoPi 0.13.0

Operating System running OctoPrint

OctoPi 0.13.0

Printer model & used firmware incl. version

Prusa i3 MK2 running firmware 3.0.12 with Linear Advance.

Browser and Version of Browser, Operating System running Browser

Safari 11.0.1 on MacOS 10.13.1

Link to octoprint.log

https://gist.github.com/JohnOCFII/38891203990e0367a58c349764fc9fc3

Link to contents of terminal tab or serial.log

serial.log was empty, and the OctoPrint had been disconnected and reconnected, so Terminal was empty.

Link to contents of Javascript console in the browser

Not Applicable

Screenshot(s)/video(s) showing the problem:

Not Applicable

I have read the FAQ.

@ctgreybeard

This comment has been minimized.

Show comment
Hide comment
@ctgreybeard

ctgreybeard Dec 4, 2017

I have also experienced this and have an octoprint.log that I can provide. It also happened on a very long print about 4.5 hours in.

ctgreybeard commented Dec 4, 2017

I have also experienced this and have an octoprint.log that I can provide. It also happened on a very long print about 4.5 hours in.

@foosel

This comment has been minimized.

Show comment
Hide comment
@foosel

foosel Dec 4, 2017

Owner

So it looks like this got introduced by implementing #2226. I had to change up the communication error handling a bit in order to be able to even differentiate that particular error from others (since it needs different handling), and apparently while Repetier reports wrong checksum on a checksum mismatch, Marlin reports checksum mismatch, and that was no longer caught thanks to the change.

Easy to fix in principle (I just need to add checksum mismatch to the list of recoverable communication errors). Now wondering though if there might be other variants out there... It definitely was easier to be able to just check for checksum but that was also wrong since that led to #2226 to begin with. Then again, the way the handling is implemented now, I might actually still be able to use that.

That it only arose in multi hour prints is a bit odd, but considering that I'm 100% sure what the reason for the error is here I feel fairly confident to think that's actually a coincidence.

Owner

foosel commented Dec 4, 2017

So it looks like this got introduced by implementing #2226. I had to change up the communication error handling a bit in order to be able to even differentiate that particular error from others (since it needs different handling), and apparently while Repetier reports wrong checksum on a checksum mismatch, Marlin reports checksum mismatch, and that was no longer caught thanks to the change.

Easy to fix in principle (I just need to add checksum mismatch to the list of recoverable communication errors). Now wondering though if there might be other variants out there... It definitely was easier to be able to just check for checksum but that was also wrong since that led to #2226 to begin with. Then again, the way the handling is implemented now, I might actually still be able to use that.

That it only arose in multi hour prints is a bit odd, but considering that I'm 100% sure what the reason for the error is here I feel fairly confident to think that's actually a coincidence.

foosel added a commit that referenced this issue Dec 4, 2017

resend_request_communication_errors was too narrow
Didn't match Marlin's "checksum mismatch", only Repetier's "checksum
error". Since the error handler checks against
recoverable_communication_errors before
resend_request_communication_errors, we can just switch back to the more
broader check against "checksum" for the latter.

We could also have added an explicit check for "checksum mismatch"
instead but since we used to check for "checksum" and we don't know what
other varieties for this specific error might be out there in the
thousands of firmware variants (who needs consistency when they can
have a free for all?), we'll err on the side of caution instead.

Fixes #2262

foosel added a commit that referenced this issue Dec 4, 2017

Make error messages in virtual printer configurable
We want to be able to test various firmware variants for stuff like
checksum and line number mismatches...

See also #2262

@foosel foosel added this to the 1.3.6 milestone Dec 4, 2017

@foosel

This comment has been minimized.

Show comment
Hide comment
@foosel

foosel Dec 4, 2017

Owner

Ok, this should be fixed in the next RC (which I'll try to push out tomorrow or Wednesday).

Owner

foosel commented Dec 4, 2017

Ok, this should be fixed in the next RC (which I'll try to push out tomorrow or Wednesday).

@foosel

This comment has been minimized.

Show comment
Hide comment
@foosel

foosel Dec 4, 2017

Owner

As a side note, I also now added a whole bunch of unit tests to the error handling code, so the next time I have to touch that stuff for whatever reason, I'll immediately get slapped by the travis build if some firmware error doesn't get handled the right way anymore.

Owner

foosel commented Dec 4, 2017

As a side note, I also now added a whole bunch of unit tests to the error handling code, so the next time I have to touch that stuff for whatever reason, I'll immediately get slapped by the travis build if some firmware error doesn't get handled the right way anymore.

@foosel

This comment has been minimized.

Show comment
Hide comment
@foosel

foosel Dec 5, 2017

Owner

1.3.6rc2 was released earlier today which should fix this issue.

Owner

foosel commented Dec 5, 2017

1.3.6rc2 was released earlier today which should fix this issue.

@foosel foosel closed this Dec 5, 2017

@Lordxv

This comment has been minimized.

Show comment
Hide comment
@Lordxv

Lordxv Dec 6, 2017

I could also confirm the bug ! Was very worried and check anything.

Lordxv commented Dec 6, 2017

I could also confirm the bug ! Was very worried and check anything.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment