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

Print failing when resend is requested #166

Closed
jgoldshlag opened this issue Jun 24, 2013 · 164 comments

Comments

Projects
None yet
@jgoldshlag
Copy link

commented Jun 24, 2013

I just updated to the latest master code, and my prints are now failing as soon as my printer (Prusa i3 with Marlin) requests a resend. It looks like maybe bbad030 is the reason for the failure. I will try rolling back those changes and see if that fixes anything.

My terminal log: (I missed the first error, but this keeps repeating forever)

Recv: ok
Send: N4976G1 X108.029 Y99.790 E9.34505_76
Recv: Error:No Line Number with checksum, Last Line: 4974
Recv: Error:Line Number is not Last Line Number+1, Last Line: 4974
Recv: Resend: 4975
Send: N4975G1 X107.734 Y100.022 E9.33912_121
Recv: ok
Send: N4976G1 X108.029 Y99.790 E9.34505_76
Recv: Error:No Line Number with checksum, Last Line: 4974
Recv: Error:Line Number is not Last Line Number+1, Last Line: 4974
Recv: Resend: 4975
Send: N4975G1 X107.734 Y100.022 E9.33912_121
Recv: ok
Send: N4976G1 X108.029 Y99.790 E9.34505_76
Recv: Error:No Line Number with checksum, Last Line: 4974
Recv: Error:Line Number is not Last Line Number+1, Last Line: 4974
Recv: Resend: 4975
Send: N4975G1 X107.734 Y100.022 E9.33912_121
Recv: ok
Send: N4976G1 X108.029 Y99.790 E9.34505_76
Recv: Error:No Line Number with checksum, Last Line: 4974
Recv: Error:Line Number is not Last Line Number+1, Last Line: 4974
Recv: Resend: 4975
Send: N4975G1 X107.734 Y100.022 E9.33912_121
Recv: ok
Send: N4976G1 X108.029 Y99.790 E9.34505_76
Recv: Error:Line Number is not Last Line Number+1, Last Line: 4974
Recv: Resend: 4975
Send: N4975G1 X107.734 Y100.022 E9.33912_121
Recv: ok
Send: N4976G1 X108.029 Y99.790 E9.34505_76
Recv: Error:Line Number is not Last Line Number+1, Last Line: 4974
Recv: Resend: 4975
Send: N4975G1 X107.734 Y100.022 E9.33912_121
Recv: ok
Send: N4976G1 X108.029 Y99.790 E9.34505_76
Recv: Error:Line Number is not Last Line Number+1, Last Line: 4974
Recv: Resend: 4975
Send: N4975G1 X107.734 Y100.022 E9.33912_121
Recv: ok
Send: N4976G1 X108.029 Y99.790 E9.34505_76
Recv: Error:Line Number is not Last Line Number+1, Last Line: 4974
Recv: Resend: 4975
Send: N4975G1 X107.734 Y100.022 E9.33912_121
Recv: ok
Send: N4976G1 X108.029 Y99.790 E9.34505_76
Recv: Error:No Line Number with checksum, Last Line: 4974
Recv: Error:Line Number is not Last Line Number+1, Last Line: 4974
Recv: Resend: 4975
Send: N4975G1 X107.734 Y100.022 E9.33912_121
Recv: ok
Send: N4976G1 X108.029 Y99.790 E9.34505_76
Recv: Error:Line Number is not Last Line Number+1, Last Line: 4974
Recv: Resend: 4975
Send: N4975G1 X107.734 Y100.022 E9.33912_121
Recv: ok

@foosel

This comment has been minimized.

Copy link
Owner

commented Jun 24, 2013

Hm, something more seems to be amiss here... It complains about missing checksums, although they are definitely there. The lines that are sent look ok judging only from the line number, the printer is constantly requesting to get 4974 again (although it seems to respond to the resend of 4975 with an ok.

@foosel

This comment has been minimized.

Copy link
Owner

commented Jun 24, 2013

I stand corrected, it complains about missing linenumbers, not about missing checksums. Still weird though. Which marlin version is that?

@jgoldshlag

This comment has been minimized.

Copy link
Author

commented Jun 24, 2013

I'm about to restart the print. The 2 times it has failed have both been at different spots in the print. I will try to catch the first error message next time (but would be nice if there was a way to log terminal output to a file so I don't need to watch it so closely).

The Marlin version is whatever makerfarm.com ships with their prusa i3 kits. From the dates, it looks like it is from April 25 of this year.

@foosel

This comment has been minimized.

Copy link
Owner

commented Jun 24, 2013

When starting the OctoPrint server, supply --debug on the commandline. This will (among other things) create a logfile of the serial communication at ~/.octoprint/logs/serial.log

@foosel

This comment has been minimized.

Copy link
Owner

commented Jun 24, 2013

Ah, could you also upload the gcode file you are tying to print somewhere, ideally the version that's located in OctoPrint's upload folder? I would like to make sure that the line number it is sending there match the contents.

@jgoldshlag

This comment has been minimized.

Copy link
Author

commented Jun 24, 2013

OK, gcode and serial log: http://dontshootx.com/print_problem.zip

@foosel

This comment has been minimized.

Copy link
Owner

commented Jun 24, 2013

Ok, I see the issue, after the first resend of 2347 it sends 2350 twice
(different lines though), so there's an off by one error (again, grr) when
resuming regular sending. I'm currently at work, so I can't properly look
into this (and am actually not supposed to ;)), but I'll see that I can
take a look at it and hopefully get it fixed when I return home in 2 or 3
hours.

@MrBalonio

This comment has been minimized.

Copy link

commented Jun 24, 2013

I have also experience this issue,

On Mon, Jun 24, 2013 at 7:35 AM, Gina Häußge notifications@github.comwrote:

Ok, I see the issue, after the first resend of 2347 it sends 2350 twice
(different lines though), so there's an off by one error (again, grr) when
resuming regular sending. I'm currently at work, so I can't properly look
into this (and am actually not supposed to ;)), but I'll see that I can
take a look at it and hopefully get it fixed when I return home in 2 or 3
hours.


Reply to this email directly or view it on GitHubhttps://github.com//issues/166#issuecomment-19906898
.

@foosel foosel closed this in e5389d0 Jun 24, 2013

@foosel

This comment has been minimized.

Copy link
Owner

commented Jun 24, 2013

Sorry for the trouble, the resend calculations are pretty mind bending.

foosel added a commit that referenced this issue Jun 24, 2013

Fixing #166 showed a deeper rooted issue with line number handling in…
…troduced with repetier/sdcard/gcodestreaming

 Something like three wrongs led to one right. Core issue (not starting with line 0 but line 1 and not using the current line but the current line from the gcode file being sent, regardless of reset by M110) should now be rooted out.
@whyvas

This comment has been minimized.

Copy link

commented Jun 26, 2013

So I am running into this same issue with a MakerGear M2, I did a git checkout devel, git pull and restarted the server and I am getting the same issue, is there anything I am doing wrong?

@foosel

This comment has been minimized.

Copy link
Owner

commented Jun 27, 2013

@whyvas could you provide a logfile please?

@foosel foosel reopened this Jun 27, 2013

@whyvas

This comment has been minimized.

Copy link

commented Jun 27, 2013

The terminal output:

Recv: Resend:369
Send: N369 G1 X142.423 Y181.727 E2.67103_103
Recv: ok
Send: N370 G1 X143.000 Y181.677 E2.70459_99
Recv: Error:Line Number is not Last Line Number+1, Last Line:368
Recv: Resend:369
Send: N369 G1 X142.423 Y181.727 E2.67103_103
Recv: ok
Send: N370 G1 X143.000 Y181.677 E2.70459_99
Recv: Error:Line Number is not Last Line Number+1, Last Line:368
Recv: Resend:369
Send: N369 G1 X142.423 Y181.727 E2.67103_103
Recv: ok
Send: N370 G1 X143.000 Y181.677 E2.70459_99
Recv: Error:Line Number is not Last Line Number+1, Last Line:368
Recv: Resend:369
Send: N369 G1 X142.423 Y181.727 E2.67103_103
Recv: ok
Send: N370 G1 X143.000 Y181.677 E2.70459_99
Recv: Error:Line Number is not Last Line Number+1, Last Line:368
Recv: Resend:369
Send: N369 G1 X142.423 Y181.727 E2.67103_103
Recv: ok
Send: N370 G1 X143.000 Y181.677 E2.70459_99
Recv: ok
Send: N371 G1 X143.577 Y181.727 E2.73814_101
Recv: ok
Send: N372 G1 X144.137 Y181.877 E2.77170_100
Recv: Error:Line Number is not Last Line Number+1, Last Line:370
Recv: Resend:371
Send: N371 G1 X143.577 Y181.727 E2.73814_101
Recv: ok
Send: N372 G1 X144.137 Y181.877 E2.77170_100
Recv: Error:Line Number is not Last Line Number+1, Last Line:370
Recv: Resend:371
Send: N371 G1 X143.577 Y181.727 E2.73814_101
Recv: ok
Send: N372 G1 X144.137 Y181.877 E2.77170_100
Recv: Error:Line Number is not Last Line Number+1, Last Line:370
Recv: Resend:371
Send: N371 G1 X143.577 Y181.727 E2.73814_101
Recv: ok
Send: N372 G1 X144.137 Y181.877 E2.77170_100
Recv: echo:Unknown command:"99"
Recv: ok
Send: N373 G1 X144.662 Y182.122 E2.80526_103
Recv: Error:Line Number is not Last Line Number+1, Last Line:370
Recv: Resend:371
Send: N371 G1 X143.577 Y181.727 E2.73814_101
Recv: ok
Send: N372 G1 X144.137 Y181.877 E2.77170_100
Recv: Error:Line Number is not Last Line Number+1, Last Line:370
Recv: Resend:371
Send: N371 G1 X143.577 Y181.727 E2.73814_101
Recv: ok
Send: N372 G1 X144.137 Y181.877 E2.77170_100
Recv: Error:Line Number is not Last Line Number+1, Last Line:370
Recv: Resend:371
Send: N371 G1 X143.577 Y181.727 E2.73814_101
Recv: ok
Send: N372 G1 X144.137 Y181.877 E2.77170_100
Recv: Error:Line Number is not Last Line Number+1, Last Line:370
Recv: Resend:371
Send: N371 G1 X143.577 Y181.727 E2.73814_101
Recv: ok
Send: N372 G1 X144.137 Y181.877 E2.77170_100
Recv: Error:Line Number is not Last Line Number+1, Last Line:370
Recv: Resend:371
Send: N371 G1 X143.577 Y181.727 E2.73814_101
Recv: ok
Send: N372 G1 X144.137 Y181.877 E2.77170_100
Recv: Error:Line Number is not Last Line Number+1, Last Line:370
Recv: Resend:371
Send: N371 G1 X143.577 Y181.727 E2.73814_101
Recv: ok
Send: N372 G1 X144.137 Y181.877 E2.77170_100
Recv: Error:Line Number is not Last Line Number+1, Last Line:370
Recv: Resend:371
Send: N371 G1 X143.577 Y181.727 E2.73814_101
Recv: ok
Send: N372 G1 X144.137 Y181.877 E2.77170_100
Recv: Error:Line Number is not Last Line Number+1, Last Line:370
Recv: Resend:371
Send: N371 G1 X143.577 Y181.727 E2.73814_101
Recv: ok
Send: N372 G1 X144.137 Y181.877 E2.77170_100
Recv: Error:Line Number is not Last Line Number+1, Last Line:370
Recv: Resend:371
Send: N371 G1 X143.577 Y181.727 E2.73814_101
Recv: ok
Send: N372 G1 X144.137 Y181.877 E2.77170_100
Recv: Error:Line Number is not Last Line Number+1, Last Line:370
Recv: Resend:371
Send: N371 G1 X143.577 Y181.727 E2.73814_101
Recv: ok
Send: N372 G1 X144.137 Y181.877 E2.77170_100
Recv: Error:Line Number is not Last Line Number+1, Last Line:370
Recv: Resend:371
Send: N371 G1 X143.577 Y181.727 E2.73814_101
Recv: ok
Send: N372 G1 X144.137 Y181.877 E2.77170_100
Recv: Error:Line Number is not Last Line Number+1, Last Line:370
Recv: Resend:371
Send: N371 G1 X143.577 Y181.727 E2.73814_101
Recv: ok
Send: N372 G1 X144.137 Y181.877 E2.77170_100
Recv: ok
Send: N373 G1 X144.662 Y182.122 E2.80526_103
Recv: ok
Send: M105
Recv: Error:Line Number is not Last Line Number+1, Last Line:372
Recv: Resend:373
Send: N373 G1 X144.662 Y182.122 E2.80526_103
Recv: ok
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: Error:Line Number is not Last Line Number+1, Last Line:372
Recv: Resend:373
Send: N373 G1 X144.662 Y182.122 E2.80526_103
Recv: ok
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: Error:Line Number is not Last Line Number+1, Last Line:372
Recv: Resend:373
Send: N373 G1 X144.662 Y182.122 E2.80526_103
Recv: ok
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: Error:Line Number is not Last Line Number+1, Last Line:372
Recv: Resend:373
Send: N373 G1 X144.662 Y182.122 E2.80526_103
Recv: ok
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: Error:Line Number is not Last Line Number+1, Last Line:372
Recv: Resend:373
Send: N373 G1 X144.662 Y182.122 E2.80526_103
Recv: ok
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: Error:Line Number is not Last Line Number+1, Last Line:372
Recv: Resend:373
Send: N373 G1 X144.662 Y182.122 E2.80526_103
Recv: ok
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: ok
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: Error:Line Number is not Last Line Number+1, Last Line:373
Recv: Resend:374
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: ok
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: Error:Line Number is not Last Line Number+1, Last Line:373
Recv: Resend:374
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: ok
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: Error:Line Number is not Last Line Number+1, Last Line:373
Recv: Resend:374
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: ok
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: Error:Line Number is not Last Line Number+1, Last Line:373
Recv: Resend:374
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: ok
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: Error:Line Number is not Last Line Number+1, Last Line:373
Recv: Resend:374
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: ok
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: Error:Line Number is not Last Line Number+1, Last Line:373
Recv: Resend:374
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: ok
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: Error:Line Number is not Last Line Number+1, Last Line:373
Recv: Resend:374
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: ok
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: Error:Line Number is not Last Line Number+1, Last Line:373
Recv: Resend:374
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: ok
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: Error:Line Number is not Last Line Number+1, Last Line:373
Recv: Resend:374
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: ok
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: Error:Line Number is not Last Line Number+1, Last Line:373
Recv: Resend:374
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: ok
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: Error:Line Number is not Last Line Number+1, Last Line:373
Recv: Resend:374
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: ok
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: Error:Line Number is not Last Line Number+1, Last Line:373
Recv: Resend:374
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: ok
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: Error:Line Number is not Last Line Number+1, Last Line:373
Recv: Resend:374
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: ok
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: Error:No Line Number with checksum, Last Line:373
Recv: Error:Line Number is not Last Line Number+1, Last Line:373
Recv: Resend:374
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: ok
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: Error:No Line Number with checksum, Last Line:373
Recv: Error:Line Number is not Last Line Number+1, Last Line:373
Recv: Resend:374
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: ok
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: Error:Line Number is not Last Line Number+1, Last Line:373
Recv: Resend:374
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: ok
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: Error:Line Number is not Last Line Number+1, Last Line:373
Recv: Resend:374
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: ok
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: Error:Line Number is not Last Line Number+1, Last Line:373
Recv: Resend:374
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: ok
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: echo:Unknown command:"100"
Recv: ok
Send: N376 G1 X145.878 Y183.338 E2.90592_96
Recv: Error:Line Number is not Last Line Number+1, Last Line:373
Recv: Resend:374
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: ok
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: Error:Line Number is not Last Line Number+1, Last Line:373
Recv: Resend:374
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: ok
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: Error:Line Number is not Last Line Number+1, Last Line:373
Recv: Resend:374
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: ok
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: ok T:192.1 /195.0 B:75.6 /75.0 @:29
Send: N376 G1 X145.878 Y183.338 E2.90592_96
Recv: Error:Line Number is not Last Line Number+1, Last Line:373
Recv: Resend:374
Send: N374 G1 X145.136 Y182.454 E2.83881_96
Recv: ok
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: ok
Send: N376 G1 X145.878 Y183.338 E2.90592_96
Recv: Error:Line Number is not Last Line Number+1, Last Line:374
Recv: Resend:375
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: ok
Send: N376 G1 X145.878 Y183.338 E2.90592_96
Recv: Error:Line Number is not Last Line Number+1, Last Line:374
Recv: Resend:375
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: ok
Send: N376 G1 X145.878 Y183.338 E2.90592_96
Recv: Error:Line Number is not Last Line Number+1, Last Line:374
Recv: Resend:375
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: ok
Send: N376 G1 X145.878 Y183.338 E2.90592_96
Recv: Error:Line Number is not Last Line Number+1, Last Line:374
Recv: Resend:375
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: ok
Send: N376 G1 X145.878 Y183.338 E2.90592_96
Recv: Error:Line Number is not Last Line Number+1, Last Line:374
Recv: Resend:375
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Recv: ok
Send: N376 G1 X145.878 Y183.338 E2.90592_96
Recv: Error:Line Number is not Last Line Number+1, Last Line:374
Recv: Resend:375
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Changing monitoring state from 'Printing' to 'Operational'
Recv: ok
Send: M84
Recv: Error:Line Number is not Last Line Number+1, Last Line:374
Recv: Resend:375
Send: M104 S0
Send: M140 S0
Send: N375 G1 X145.546 Y182.864 E2.87237_110
Unexpected error while writing serial port: SerialException: 'write failed: [Errno 5] Input/output error' @ comm.py:_doSendWithoutChecksum:990
Changing monitoring state from 'Operational' to 'Error: SerialException: 'wr...'
Connection closed, closing down monitor

I unplugged the machine at the end where the SerialException happened. It's a Makergear M2 running Marlin 1.0.0 RC2,I've been running OctoPrint since day 1 and this is the first time this issue came up (last update).

Something I thought I might mention, other posts mention mjpeg-streamer using a lot of CPU, when using it with a cheap ebay camera. I have one and I had to enable YUV mode because the camera didn't support MJPEG which seems to chew up all free CPU cycles which slows everything down.

I think you're extremely talented and very much appreciate your work and use it on a daily basis, thank you!

@foosel

This comment has been minimized.

Copy link
Owner

commented Jun 27, 2013

First of all, thanks for the compliments :)

Secondly, this looks a bit different than the other logs with that issue.
I'd love to get a full dump of the whole printer communication from
connection up until failure. Could you try the following: Start octoprint
with --debug, e.g. ./run.py --debug --daemon restart. Then connect to
your printer, try a (small) print job, hopefully the problem should occur.
When it does, abort the print job, paste the contents from
~/.octoprint/logs/serial.log to pastebin.com and paste the URL here.

I hope that this way I'll be able to see where it exactly it goes south.
From the log above it looks like that for whatever reason the printer
accepts some of the lines, but hiccups on every third or so line, totally
weird. There must be a cause of this, but it probably happened earliert
than the excerpt above.

@whyvas

This comment has been minimized.

Copy link

commented Jun 28, 2013

Well of course now with the --debug it seems to be printing just fine but I'll leave it on for a while in case it happens again. Has anyone thought about doing an Android app for OctoPrint? I'd love to see something like texting or even email, I saw you had events so we could probably just run command line emails to send status updates, even attach screenshots of the finished print. I will keep you posted.

@devzero

This comment has been minimized.

Copy link

commented Jul 5, 2013

I was having this same problem consistently about 2 hours into a 3 hour print I've been trying to do. I did a git pull on master to commit 407c61c... and that appeared to work for one print. Once I tried to do it again with the included fix, I got the same error repeating in the terminal:

Recv: ok
Send: N65595 G1 X108.685 Y130.044 E6.43797_96
Recv: Error: No Line Number with checksum, Last Line:65593
Recv: Serial Error: Line Number is not Last Line Number+1, Last Line:65593
Recv: Resend:65594
Send: N65594 G1 X108.897 Y130.481 E6.42446_111
Recv: ok
Send: N65595 G1 X108.685 Y130.044 E6.43797*96
Recv: Error: No Line Number with checksum, Last Line:65593
Recv: ok T:184 @:91 B:56
Send: M105

All 3 times I've had it fail, it appears to have started failing around 65536, I can't help but think that there's some byte size or checksum bug related to that that wouldn't show up in a smaller print, but it did succeed once. Any thoughts on that?

Anything I can do to help? You want the gcode? Should I turn on logging? I'm running on a raspberry pi connected to RAMPS 1.4 with Sprinter downloaded a few months ago via a 2ft USB cable running a 115200.

@foosel

This comment has been minimized.

Copy link
Owner

commented Jul 5, 2013

Hm... yeah, I think turning on logging and providing both the gcode file and the serial.log might shed some insight into this problem. For you it's only "No Line Number with checksum"? That's bloody weird...

@devzero

This comment has been minimized.

Copy link

commented Jul 6, 2013

Wow, I just added --debug and it locked up on the first layer (I was tailing serial.log over ssh while it happened - maybe that affected it?). Here are urls for serial.log https://dl.dropboxusercontent.com/u/22199522/serial.log and the gcode file https://dl.dropboxusercontent.com/u/22199522/Z_top_extra_x_travel_1013%20%281%29.gcode

Thanks for your help - this is an awesome program

@foosel

This comment has been minimized.

Copy link
Owner

commented Jul 6, 2013

Hm... Honestly I have no idea. OctoPrint seems to do everything correctly here, it's just that your firmware keeps re-requesting lines it already received O_O I don't see duplicated lines or linenumbers, missing checksums or something like this, OctoPrint is sending exactly what is in the gcode file, but the firmware just refuses to accept every second line. Previous iterations of such loops always had some fault in the sending code, e.g. the problems stated above, but I see none of this here.

Do you have the possibility to test printing with the same printer, printer host system (Raspberry Pi?) and USB cable, but a different host software? I'd like to know if that problem is only happening with OctoPrint.

@devzero

This comment has been minimized.

Copy link

commented Jul 6, 2013

I could try to load xvnc and pronterface on there, I guess. I just
completed a successful print of that gcode file from a different computer
over the same USB to the same printer (there were two times where it seemed
like it paused unnecessarily for a few seconds, but the computer was also
under heavy I/O load during both those times).

On Sat, Jul 6, 2013 at 4:42 PM, Gina Häußge notifications@github.comwrote:

Hm... Honestly I have no idea. OctoPrint seems to do everything correctly
here, it's just that your firmware keeps re-requesting lines it already
received O_O I don't see duplicated lines or linenumbers, missing checksums
or something like this, OctoPrint is sending exactly what is in the gcode
file, but the firmware just refuses to accept every second line. Previous
iterations of such loops always had some fault in the sending code, e.g.
the problems stated above, but I see none of this here.

Do you have the possibility to test printing with the same printer,
printer host system (Raspberry Pi?) and USB cable, but a different host
software? I'd like to know if that problem is only happening with OctoPrint.


Reply to this email directly or view it on GitHubhttps://github.com//issues/166#issuecomment-20560686
.

@garyjohnson

This comment has been minimized.

Copy link

commented Jul 29, 2013

I just had a similar issue with a Prusa i2, using the Marlin firmware from makerfarm.com. I'm going to update to the latest Marlin firmware and see if the issue goes away. I've been using Pronterface and that's been working fine so far.

@garyjohnson

This comment has been minimized.

Copy link

commented Jul 29, 2013

It looks like I was able to get around this issue by updating to the latest Marlin firmware. Still not sure if the problem was with that version of Marlin or with OctoPrint.

@foosel

This comment has been minimized.

Copy link
Owner

commented Aug 1, 2013

Leaving this open for now as long as its not certain what's causing this, and the issue still pops up from time to time for some... Really would love to get to the bottom of this.

@whyvas

This comment has been minimized.

Copy link

commented Aug 1, 2013

I've reflashed my pi from scratch and reinstalled octoprint and it hadn't
been back so far.
On 2013-08-01 3:44 PM, "Gina Häußge" notifications@github.com wrote:

Leaving this open for now as long as its not certain what's causing this,
and the issue still pops up from time to time for some... Really would love
to get to the bottom of this.


Reply to this email directly or view it on GitHubhttps://github.com//issues/166#issuecomment-21964318
.

@beeekey

This comment has been minimized.

Copy link

commented Sep 29, 2013

I had the same problem, with resending the line. I made now two changes, the first one was, to enable the option "Send a checksum with every command Repetier" in octoprint, i did it for though i run sprinter as firmware.

The second one was, that I removed the header lines in the gcode file which slic3r usually generates. Now there are only gcode lines in the file. Since then it is running!

@foosel

This comment has been minimized.

Copy link
Owner

commented Sep 30, 2013

Could you send me one of your Slic3r files with the offending lines still included? I want to see what commands (or comments) could have caused such an issue.

It's also pretty interesting that the issues disappeared when you made it send checksums with every line. If you take a look into the logfile, do you still see any resends at all? Kinda weird...

@foosel

This comment has been minimized.

Copy link
Owner

commented May 6, 2015

@foosel

This comment has been minimized.

Copy link
Owner

commented Jun 3, 2015

Considering this closed for now due to the quite extreme refactoring that took place in the commit mentioned above which switched to a ping-pong based approach of communication (which while not optimal should have solved the problem) and due to the fact that I did not get any feedback telling me that this is nevertheless still happening with current devel.

New terminal tab offers to fake acknowledgements in case they get lost, new polling for temperature and sd printing status no longer flood the printer during long running commands (which also no longer trigger a timeout and are also configurable through the settings), and a lot of other improvements have been backported from commRefactoring too.

@foosel foosel closed this Jun 3, 2015

@lobermann

This comment has been minimized.

Copy link

commented Jun 30, 2015

Hi. I just ran into this exact issue. Using latest Marlin from 3 days ago (32cec5c3cc15645d4c853aeb0bdb8ff32c39be81) and Octoprint (Octopi) Version 1.1.1-30-g4fede5a. I pasted the log here http://pastebin.com/pd39CZrk . You can also see my fork that I use here https://github.com/lobermann/Marlin/tree/PrusaI3Hephestos_update .

I am now going ahead and restart that print and see if it fails again or continues. If I encounter it again I will put octoprint in debug and see what I can get.

If I can test anything else please let me know.

Update: I just recognized when looking at the logs again, that the ok's that are sent, are sent twice when this is happening. Uploaded another log with some lines before that here http://pastebin.com/Td4FR430 .

@foosel

This comment has been minimized.

Copy link
Owner

commented Jun 30, 2015

Please update. 1.2.0 was released last week, which includes all the changes mentioned above.

@lobermann

This comment has been minimized.

Copy link

commented Jun 30, 2015

ok thanks! will do that. Will post it here if I encounter any more issues.

@ChrisAllenIsAwesome

This comment has been minimized.

Copy link

commented Jun 30, 2015

I just started having the same problems. Was running Octopi 1.2.0 RC3 (I believe) and everything was working great. Just upgraded to 1.2.1 and upon my first print I received the "Print failing when resend" error. Restarted the Printrbot and Pi2, printed and it ran great for about 1 hour then just locked up/stopped. I couldn't even get to the Pi2 web server for octoprint. Printing now using Cura and it's been ok.

@foosel

This comment has been minimized.

Copy link
Owner

commented Jun 30, 2015

@krang00 Full serial log please, diagnosis if this is even an actual issue is otherwise impossible - those error messages from the firmware can in fact also be just a normal cause of a serial transmission error. And the fact that you couldn't even reach the web server anymore sounds in fact more like a full crash, and I've had people report in the past that they solved both that and their communication issues by getting a proper power supply for the pi, which can be quite finicky when it comes to power. Doesn't mean that's the reason here, but since you experiences both a communication error and what sounds like a crash I'd actually rule that out as a possible cause if it was my setup.

@ChrisAllenIsAwesome

This comment has been minimized.

Copy link

commented Jul 1, 2015

Well, so far I've been able to run two full long prints with no issues and Serial debugging on. I'm attributing that one failed print to a Pi2 or other issue. I'll let you know if it happens again and get logs. thanks for your awesome work on this!

@armamut

This comment has been minimized.

Copy link

commented Aug 5, 2015

Hello, I had the same issue at the first print. I have latest marlin on prusa i3 clone, and latest octoprint on an odroid-w (a raspberry pi clone). I have a lousy cable connection to ramps D0/D1 pins to rpi rx-tx pins, with a level converter in between. So a lot of things, especially bad grounding and voltage spikes may have caused this I think... I'm sorry I've lost the error log and cannot paste here.

Then, I've checked "Send a checksum with every command Repetier" and added "G0, G1," to "long commands" settings in the serial configuration settings tab. I had a large (about 20 cm) part to print. I think the problem is over now.

I'll renew the connection cables as soon as I can.

By the way, thank you @foosel, It's a very nice and neat software.

@foosel

This comment has been minimized.

Copy link
Owner

commented Aug 5, 2015

Again, seeing a resend request in the log is nothing unusual, only if the request loops and purely electrical reasons and firmware bugs can be ruled out as a cause for that does it make sense to look further.

I also advise against adding G0 and G1 to long running command - by their very definition they are not (the firmware acknowledges them when they enter the movement planner, not when they are actually executed), and since they make up most of the communication during a print having then toggle the "long running flag" constantly will probably only negatively impact performance and do nothing else.

@armamut

This comment has been minimized.

Copy link

commented Aug 5, 2015

Yes, I think you are right. I've removed G0, G1 from long running command, and its the same, there is no problem now. Thanks.

@PulgaFeroz

This comment has been minimized.

Copy link

commented Jul 25, 2016

Here's my 2 cents (and an evening of troubleshooting)

My octoprint is setup in a raspberry pi model 1 B (yes one of the first ones with all it's hw quirks) with a solidoodle 2 (pre may 2013, sanguinolu)
It worked fine for a while, only noticeable thing was that the 'connect' doesn't always work as i send a G28 right after connect and some OK is sometimes missing, usually the 1st connect failed
Other than that i was able to print for several days with no problems
Later, during one of the typical hotend clogs i damaged it irreparably, so i upgraded it to an e3d v6, reflashes the firmware with marlin 1.0 and few touches
Then it start failing with this very problem of losing the sync between where it was printing and so, exactly as described.
After banging my head several times over i found out that the culprit was the usb hub (wich powers a small usb fan, a wifi dongle and connects to solidoodle 2, nothing more)
Other problems were rare download failures and funny enough it was also hitting a bug in my adsl modem ocasionally it will kick out of the wifi all my machines at home :/
I strongly suggest to who may still suffer this problem is to check http://elinux.org/RPi_Powered_USB_Hubs where there is more info about the usb hub messyness w raspberry pi, among with isolated tests of the usb hub in itself

Hopefully this may save some evenings of unlucky guys

@MiregSan

This comment has been minimized.

Copy link

commented Nov 14, 2017

Any idea what happend? two times on same model at same percentage...

bez nazvu

@foosel

This comment has been minimized.

Copy link
Owner

commented Nov 15, 2017

If it happens at the exact same line I'd check if maybe your GCODE file contains that 0-byte garbage data already.

@MiregSan

This comment has been minimized.

Copy link

commented Nov 15, 2017

execuse me, how can i check this? every time it is stop at line about 217 000. i actualy try reslice and print again. same error at 220 000.
here is the log file... https://drive.google.com/open?id=1U6YllrvMqt9akYc0XszdnV5oZbT2Jx51

2017-11-15 11:50:02,828 - octoprint.util.comm - INFO - Got a resend request from the printer: requested line = 224092, current line = 224093 | Last lines in terminal: | Recv: ok | Send: N224092 G1 X166.995 Y126.429 ?H ?H ?H ?H ?H I ?G ,H <H ?G �H *90 | Recv: Error:No Checksum with line number, Last Line: 224091 | Recv: Resend: 224092 | Recv: ok
now i am printing from sd card. everythings works well...

@foosel

This comment has been minimized.

Copy link
Owner

commented Nov 15, 2017

It still looks like the file you are trying to print has some garbage data in there. Could you upload and share the file?

@MiregSan

This comment has been minimized.

Copy link

commented Nov 15, 2017

@PulgaFeroz

This comment has been minimized.

Copy link

commented Nov 15, 2017

now i am printing from sd card. everythings works well...

If the same file success when in SD card and fails when using the usb cable then it can be a hardware issue during I/O, try other usb port or another usb hub with the same failing file to discard your usb port / hub

@MiregSan

This comment has been minimized.

Copy link

commented Nov 15, 2017

It is possible low memory or high cpu usage? i use raspberry pi 1b. maybe pi 2 or pi 3 will be better? i have USB cable connected directly to pi without any hub. and i have installed no-ip on it.

@MiregSan

This comment has been minimized.

Copy link

commented Nov 15, 2017

And additional info for investigation - few day ago i was printing gcode around 3,5MB size and everything works well. Gcode which make error is 14MB size.

@PulgaFeroz

This comment has been minimized.

Copy link

commented Nov 15, 2017

my old rasp pi b model 1 did not work well directly connected to the printer + 1 wifi dongle, I then used a usb hub and had many problems until I realized that many usb hubs are NOT compatible with raspberry pi (specially the early models) check http://elinux.org/RPi_Powered_USB_Hubs
It is quite slow, my other printer runs in model b version 3 as is way way faster
I'd love to try the pi zero w (is only 10€ and has wifi built in!) and im sure it beats my old b rev 1

@PulgaFeroz

This comment has been minimized.

Copy link

commented Nov 15, 2017

if my memory serves me well, there are power issues with the PI in itself, I think back in the early days of PI it was recommended to use a powered usb hub to use a wifi dongle to alleviate the limitations of it, you're feeding the printer board thru the usb (in my case both the dongle and the printer)
also check the power source you're using with the PI (I think 2 amps was the recommended?)
To me your problem is quite similar to the one I had (an electric one, not a software one)

@MiregSan

This comment has been minimized.

Copy link

commented Nov 15, 2017

Ok, thanks for your help. I will try meassure power supply (2A), connect all USB via powered USB hub and then print again my gcode. I will post result here but propably during weekend. One more, thanks for your help and thanks mr.foosel for octoprint...

@foosel

This comment has been minimized.

Copy link
Owner

commented Nov 17, 2017

@MiregSan That doesn't appear to be the correct file. The line successfully sent just before the offending line is G1 X139.78 Y65.376 E20052.55491 and that doesn't exist in the GCODE file that you shared. The comments in the header also state that it was sliced on 2017-11-14 19:48 and your log indicates an error with a file roughly 9 hours before that. If you don't share the exact file that produces the issue, it's impossible to determine if that file is at fault or not ;)

In general though, your printer communication is riddled with resend requests over and over again, hinting at some serious noise on transmission. As already stated by @PulgaFeroz, that screams either power issues or connectivity issues caused by bad cables or wonky USB hubs. See also the FAQ

@PulgaFeroz

This comment has been minimized.

Copy link

commented Nov 17, 2017

May be a good idea to put a generic topic: Raspberry PI and Octoprint common issues, perhaps in the FAQ or so, this issue is rather popular and many of us fall prey to it.

It can be summed up like: powering the WIFI and/or your 3D printer directly from the PI instead of a powered usb hub can cause communication and/or printing issues.
Many usb hubs are NOT compatible with PI (see http://elinux.org/RPi_Powered_USB_Hubs)
Having long cables between the PI / printer / wifi dongle can cause problems
Not having adecuated power for your PI can also cause random printing problems (i/e http://www.aoakley.com/articles/2014-02-25-raspberry-pi-power-wifi.php)

You do get to learn a lot when facing those problems :)

-Mat

@foosel

This comment has been minimized.

Copy link
Owner

commented Nov 17, 2017

The FAQ is part of the wiki, which anyone with a Github account can edit ;)

@MiregSan

This comment has been minimized.

Copy link

commented Nov 20, 2017

I'm sorry, Mr Foosel. it's my fault, I uploaded a bad file. However, I know the new faults. My raspberry pi 1B now uses a 1.5A (1,09A consumption) power supply and the CPU temperature is over 90 ° C. as the first step I will deal with cooling, then I will return to the octoprint error. The temperature is, perhaps, the cause of the error.

@MiregSan

This comment has been minimized.

Copy link

commented Nov 27, 2017

Hi, i have new information for investigation. Now i try new raspberry pi zero ( temperature and power supply are ok).
Gcode around 3MB still print ok, but 12MB+, printer was stopped around 60%. I try to find answers and i think, my problem is same as issue 444. When i dissable gcode visualizer, my octoprint work like a charm...

#444

@foosel

This comment has been minimized.

Copy link
Owner

commented Nov 28, 2017

No, you probably do not have the same issue as #444 since that was reported as client-side only with completely different symptoms and your communication errors arise in the backend. The GCODE viewer downloads the full file to the frontend and then operates strictly inside your browser. I don't see how that could be causing resend errors in your backend.

If you disable the GCODE viewer and your printer communication starts working flawlessly, that's either coincidence, or caused by some weird resource consumption leading to brown-outs. E.g. you running the GCODE viewer on the same machine that OctoPrint itself is running on.

If you want help with this, I suggest you provide an exact file (ideally outright downloaded from your OctoPrint instance) you are having issues with, together with a serial.log of the issues you are having.

PS: And in the future, please don't drag up ancient tickets but instead first ask for help on the established support channels. This is not a support forum but an issue tracker :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.