Octoprint: Error:Line Number is not Last Line Number+1, Last Line: ...

[brandstaetter]

What were you doing?

OctoPrint installed via OctoPi image on a raspi zero w

1. start print
2. randomly, the printer just stops, in the communication log the following appears:

Send: N8696 M117 2.92p  complete*91
Recv: ok
Send: N8697 G1 X118.911 Y83.238 E0.69483*97
Recv: ok
Send: N8698 G1 X119.491 Y83.238 E0.01979*108
Recv: ok
Send: N8699 G1 X103.945 Y98.784 E0.75006*104
Recv: ok
Send: N8700 M204 S1000*104
Recv: Error:No Checksum with line number, Last Line: 8698
Recv: Resend: 8699
Recv: Error:Line Number is not Last Line Number+1, Last Line: 8698
Recv: Resend: 8699

What did you expect to happen?

print successful

What happened instead?

print had to be aborted; pause/unpause did not help, neither did resending the requested line

Did the same happen when running OctoPrint in safe mode?

as it is only happening randomly, it's not easy to reproduce. I can try safe mod if absolutely required

Version of OctoPrint

OctoPrint 1.3.6 auf OctoPi 0.14.0

Operating System running OctoPrint

OctoPi 0.14.0

Printer model & used firmware incl. version

Original Prusa MK2 MM Fw: 3.1.0

Browser and Version of Browser, Operating System running Browser

Windows, Chrome Version 63.0.3239.84 (Offizieller Build) (64-Bit)

Link to octoprint.log

https://gist.github.com/brandstaetter/06ef4053cc3db891c14bd3d5bd034004

Link to contents of terminal tab or serial.log

n/a

Link to contents of Javascript console in the browser

n/a

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

n/a

I have read the FAQ.

[brandstaetter]

Probably related: https://github.com/MarlinFirmware/Marlin/issues/3680 - seems to be a firmware issue, not OctoPrint

[Crowlord]

Can confirm same issue on Original Prusa I3 Mk2 Firmware 3.1.0 octopi 0.13.0

[tgunr]

I am having the exact same issue and the same config as described in the bug.

Send: N20234 G1 X136.034 Y106.382 E0.01543*107
Recv: ok
Send: N20235 G1 X130.029 Y112.386 E0.22157*97
Recv: ok
Send: N20236 G1 X130.184 Y112.822 E0.01208*105
Recv: Error:checksum mismatch, Last Line: 20234
Recv: Resend: 20235
Recv: Error:Line Number is not Last Line Number+1, Last Line: 20234
Recv: Resend: 20235
Changing monitoring state from 'Printing' to 'Operational'
Communication timeout during an active resend, resending same line again to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: N20234 G1 X136.034 Y106.382 E0.01543*107
Recv: Error:Line Number is not Last Line Number+1, Last Line: 20234
Recv: Resend: 20235

How is this a firmware issue if the firmware is requesting resend of 20235 and Octoprint is sending 20234?

If I use the exact same gcode file and send it via another means. Slic3r, Simplify3D, etc it does not fail. Only Octoprint is exhibiting this behavior.

This is with OP 1.3.6

[foosel]

Duplicate of #2285 and in fact caused by a bug in the Prusa fork of Marlin as reported by me in prusa3d/Prusa-Firmware#331

And judging by the flood of comments on #2285, that appears to not be the only problem that the current versions of Prusa's firmware seems to have sadly.

As mentioned in my firmware ticket, this:

Note: There does exist a workaround in OctoPrint for this (since it's happened in the past with other firmware variants), users can tell OctoPrint to "simulate" an ok after resends by enabling Settings > Serial communication > Advanced options > Simulate an additional ok for resend requests, but that has to be done manually.

should work, but it's tricky to test.

[tgunr]

I will dig into the Prusa code and try to find this. Super annoying and I can't trust Octoprint to finish the job. As I said, this only happens with Octoprint (so far) which is why I strongly suspected Octoprint code.

On Jan 10, 2018, at 11:16 PM, Gina Häußge [e-mail] wrote:

Duplicate of #2285 https://github.com/foosel/OctoPrint/issues/2285 and in fact caused by a bug in the Prusa fork of Marlin as reported by me in prusa3d/Prusa-Firmware#331 https://github.com/prusa3d/Prusa-Firmware/issues/331
And judging by the flood of comments on #2285 https://github.com/foosel/OctoPrint/issues/2285, that appears to not be the only problem that the current versions of Prusa's firmware seems to have sadly.

As mentioned in my firmware ticket, this:

Note: There does exist a workaround in OctoPrint for this (since it's happened in the past with other firmware variants), users can tell OctoPrint to "simulate" an ok after resends by enabling Settings > Serial communication > Advanced options > Simulate an additional ok for resend requests, but that has to be done manually.

should work, but it's tricky to test.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/foosel/OctoPrint/issues/2342#issuecomment-356873302, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEIjP1RnGWZEfbx5deV2yPgyeYpN93Iks5tJdFwgaJpZM4RVS6e.

[foosel]

Contrary to other hosts, OctoPrint strictly adheres to the ping-pong protocol in place. Read: Any command it sends must be acknowledged by an ok from the firmware that signals it may send more. It used to be more lenient here, similar to other hosts, but that caused enormous problems with various printers on the market whose serial buffers were easily overwhelmed with lines send without an ok, causing them to crash or process incomplete commands.

The underlying issue here is a missing ok at the end of the resend request, which is mandatory to be there. Normally you probably never would notice this, but in Prusa Marlin 3.1.x there's a much higher likelihood of resend requests to be triggered in the first place due to issues inside the firmware as confirmed in this thread:

So we have been able to replicate the issues in the office and probably point down the issue into the poor AVR serial buffer coupled with the massive overhead of all the features. LinearAdvance is causing the serial timing problems, it will probably need to be rewritten in assembler.

[diybuc]

Probably a bit late but i have the same issue with prints just randomly stopping mid print. I have only now seen the errors popping up with using the Slic3r interface directly connected to various PC's with different USB cables.

I'm in the process of getting my new printer setup and have been fighting mid print pauses and occasional step skipping from both Octoprint and AstroPrint. Also 2 failures on Repetier Host. Step Skips were not mechanical it skipped on Z at 10mm that send me on a wild goose chase on fade hight.

I notice a lot of these guys on Slic3r (Probably just a protocol issue with Slic3r but glad i found this post)
Error:Line Number is not Last Line Number+1, Last Line: 1 ......
That lead me to this post.

My setup

1. bugfix-1.1.x Downloaded in Dec 2018
2. Tried 115200 and 250000 (roughly same amount of errors)
3. Not sure of the overhead but TMCdrivers installed on x and y
4. Disabled all debugging except Debug memory M100 - result below.
   23:53:12.963 : start of free space : 0x185D
   23:53:12.963 : Stack Pointer : 0x2124
   23:53:12.964 : Initializing free memory block.
   23:53:12.967 : 1997 bytes of memory initialized.
5. Tried hardware and software flow control on Windows COM port with no change.

If there is any testing that needs to be done please let me know. I will try my best to assist.
P.S. Thanks for all the hard work everyone, wish my programming skills did not suck so hard else i would have been helping.

[mj1911]

Hmm. I've been using Cura and Slic3r to send jobs over serial (USB), and up until today (maybe a few dozen prints), no errors. In Slic3r, noticed the "Line Number is not Last Line Number+1" message in the serial text, but it would only display it once, and seemed to work fine after that. Never failed mid-print yet. So researching this error, it seemed like a big potential problem, so decided to build and upload the latest 1.1.9 Marlin bugfix fw. Now getting an endless supply of "Line Number is not Last Line Number+1" and it refuses to print in Slic3r. Printed fine in Cura though.