Wrong line resent after resend request without ok #2285
Comments
|
Your firmware has a specific bug leading to an ok after the resend request missing. While that still shouldn't cause this line to be sent, it is what makes this issue manifest in the first place. You should set Settings > Serial communication > Advanced options > Simulate an additional ok for resend requests to work around that firmware bug. |
|
Thanks! I'll watch out for any other odd behavior after enabling it, but it sounds like you're familiar with this particular issue. I came across a lot of similar cases while searching but I hadn't seen any where the line number was off by one. Closing the issue, and maybe this'll pop up in the search results and help someone else who has a similar problem in the future. :) |
|
FWIW, I've opened a ticket at prusa3d/Prusa-Firmware#331 about this. |
|
Reopening. I'll have to take a look in January if I can somehow get OctoPrint to not send the wrong line when that happens (but it might not be possible to differ between this firmware bug and something like an actual communication timeout during a resend). |
foosel
added
improvement
foosel
changed the title
|
@foosel I've updated the prusa issue with a note about this, but as I read and understand the log, the firmware is also reporting the incorrect
This is probably caused by the same root bug, but if the fix it in the wrong way the numbering will still be incorrect. |
|
I have exact the same problem since 1.3.6 only. Have printed dozens of STL's for 6 months in the same setup, no new plugins, no recent firmware upgrades to my printer. The one giving problems is connected to my MK2S. First print after 1.3.6 upgrade gave me these problems. Again I did not change printer firmware, I did however upgrade Octoprint just before the first failure. I can fix it though when I notice the error. Just force an acknowledgement in de advanced terminal view. You can see the communication is stuck somehow. Error in terminal After I fake the acknowledgement the print finishes just fine as far as I currently tested on 4 prints. |
|
I think I'm suffering from the same issue (Prusa MK2s and latest version of Octoprint). Had a couple of failed prints, here's the output from the last one:
|
|
Because of this issue where OctoPrint/my printer becomes useless (4 out of 5 prints get stuck), I just downgraded Octoprint to 1.3.5. These were all the same files btw (two different ones), only spool swap in between. Now printing my second print on 1.3.5, which is stil holding on... Will keep you posted when it fails. If so, I will also be downgrading Prusa firmware, just to be 100% sure since Prusa did change some stuff in 3.1.0 for Octoprint support. |
|
That's interesting - I can't help answer that question as I just installed Octoprint for the first time w/this version and this version of Prusa firmware - never used it on this printer before now, so nothing to compare to. |
|
Ok, stuck again, same issue. So downgrading OP 1.3.6 > 1.3.5. does not solve the issue for me. Will downgrade firmware when this print ends, not sure if I will be able to print something right after since I don't want this issue happening when I'm not around (heatbed and nozzle are both still on while it 'crashes'!!) |
|
Just a heads-up, after 5 more prints I came to the same conclusion as @foosel. Tested on both Octoprint 1.3.5 and 1.3.6 to make sure that has nothing to do with it. Using Prusa firmware 3.1.0, 4 out of 5 prints get stuck, waiting for an OK. All tests were performed on a Prusa i3 MK2(S) which has never had any issues before. Happy New Year! (that's what I was printing for anyways 🤣 ) |
|
3.1.1 RC4 B143 firmware was just released for Mk3 a couple days ago (https://www.prusa3d.com/drivers/). I haven't verified whether or not it has the same issue, although "Better OctoPrint Reliability" is mentioned in the release notes. EDIT: Don't upgrade to RC4... it has a serious serial communication issue. You can download the previous firmware at http://prusa3d.com/downloads/firmware/prusa3d_fw_3_1_1_rc3_b138.zip (the Prusa site doesn't link to previous RC firmwares directly). You can go back by flashing RC3 over RC4 and nothing appears to break, although YMMV. |
|
I'd try it but I don't have a MK3, just 2S. |
|
Same issue here - prints stop since a I've upgraded from my Prusa i3 MK2S to i3 MK2S MMU (multi color option). This means that I had to update the Prusa FW to 3.1.0 Gina - So I should do this here as you suggest above? |
|
I will say that I tried it and it didn't fix the issue for me (MK2s MM).
…On Wed, Jan 3, 2018 at 8:26 PM, Johncoffee2017 ***@***.***> wrote:
Same issue here - prints stop since a I've upgraded from my Prusa i3 MK2S
to i3 MK2S MMU (multi color option). This means that I had to update the
Prusa FW to 3.1.0
Gina - So I should do this here as you suggest above?
-->"You should set Settings > Serial communication > Advanced options >
Simulate an additional ok for resend requests to work around that firmware
bug."
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2285 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABaAf6xpxuqK9n48h6lf2hADnTKlPv63ks5tHG79gaJpZM4RBlOx>
.
|
|
@Johncoffee2017 just downgrade the firmware to 3.0.12 it is compatible with MMU. All my tests were on the mmu :) |
|
Nah, I really like linear advance. Just using the SD card until this gets
sorted. Think the bug is more on Prusa's end than Octoprint.
…On Wed, Jan 3, 2018 at 9:56 PM, rnldnkp ***@***.***> wrote:
@Johncoffee2017 <https://github.com/johncoffee2017> just downgrade the
firmware to 3.0.12 it is compatible with MMU. All my tests were on the mmu
:)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2285 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABaAf-kifF13TY3Okw3QLiad3-jECVKvks5tHIQsgaJpZM4RBlOx>
.
|
|
Not liking to downgrade is different than not working at all after a downgrade ;) By downgrading you loose the new features but you gain Octoprint support. |
|
Thanks for your replies Firebug24k & rnldnkp. |
|
There must also be a hardware flaw because there really shouldn't be any
retries.
…On 4 Jan 2018 10:30 p.m., "Johncoffee2017" ***@***.***> wrote:
Thanks for your replies Firebug24k & rnldnkp.
Wondering what Prusa changed on FW 3.1 that this specific part of the code
doesn't behave the same any longer...
I will probably try first to work via the SD card.
..and I need to check what the linear advance really improves.. haven't
tried it.
Firebug24k - you seem to like it. Where are the improvements for you?
Thanks for elaborating a bit!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2285 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAijhShanxqv863iP8sM9thW15J9aOjVks5tHLZbgaJpZM4RBlOx>
.
|
|
Probably interference from the USB cable causes a bit to get dropped here
and there. I've printed hundreds of hours from the SD card w/no issues.
Don't want to drag this off topic, but linear advance in the newer firmware
has let me speed up single-color prints by quite a bit and keep the same
print quality. It's not a major inconvenience w/using the onboard SD
reader for me at least. I'm happy to assist w/troubleshooting if anyone
has thoughts of things to try.
…On Thu, Jan 4, 2018 at 1:28 PM, Chris ***@***.***> wrote:
There must also be a hardware flaw because there really shouldn't be any
retries.
On 4 Jan 2018 10:30 p.m., "Johncoffee2017" ***@***.***>
wrote:
> Thanks for your replies Firebug24k & rnldnkp.
> Wondering what Prusa changed on FW 3.1 that this specific part of the
code
> doesn't behave the same any longer...
> I will probably try first to work via the SD card.
> ..and I need to check what the linear advance really improves.. haven't
> tried it.
> Firebug24k - you seem to like it. Where are the improvements for you?
> Thanks for elaborating a bit!
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <#2285 (comment)
>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/
AAijhShanxqv863iP8sM9thW15J9aOjVks5tHLZbgaJpZM4RBlOx>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2285 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABaAf_I06Ov0IvzgFSfxP5N4r4qTVQAMks5tHV6YgaJpZM4RBlOx>
.
|
|
Ok, as promised I pulled and compiled, haven't tried it out yet but here's the FW (no changes other than that patch). |
|
I should say this is for Rambo 1.3a, 1.75mm MK2 with multimaterial. |
|
I'm getting a verification error when trying to flash your FW Firebug24k. Failed twice. Standard Prusa FW3.1 flashes without issues. Did you succeed? |
|
I got the same error, I think it's because I compiled in the bootloader.
It worked though. I will post another one w/out the bootloader.
It does seem to have fixed the problem, I haven't had an error yet, but
only printed a few hours.
…On Mon, Jan 8, 2018 at 7:29 AM, Johncoffee2017 ***@***.***> wrote:
I'm getting a verification error when trying to flash your FW Firebug24k.
Failed twice. Standard Prusa FW3.1 flashes without issues.
Interesting fact: your version is 692kB, where the standard FW has 660kB
only.
Did you succeed?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2285 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABaAf_UulM6dUbRrdMKxeqKTZ9r8I5qLks5tIlBlgaJpZM4RBlOx>
.
|
|
Ok, thanks for posting a new version. Will try again after my current print has finished. Need to print new Spool holders, the current Prusa version is not good at all. I don't like the approach - and I got the new black molded version. |
|
Ok, uploaded your new FW build and now testing a 6.5h print. Let's see how it turns out. |
|
It didn't work! Found my Printer this morning sitting and waiting on the part without any movement, hotend and bed were still hot, Octoprint unresponsive. Here are some log data's: | Recv: Resend: 689 Going back to FW 3.1 again! |
|
Aargh. Well, that wasn't the solution then. I'm an OK coder but not a
lot of free time, I'll play around with it some more when I get some time.
…On Mon, Jan 8, 2018 at 8:01 PM, Johncoffee2017 ***@***.***> wrote:
It didn't work! Found my Printer this morning sitting and waiting on the
part without any movement, hotend and bed were still hot, Octoprint
unresponsive.
Here are some log data's:
| Recv: Resend: 689
2018-01-07 23:05:32,733 - octoprint.util.comm - INFO - Got a resend
request from the printer: requested line = 721, current line = 723
| Last lines in terminal:
| Recv: ok
| Send: N714 G1 X117.323 Y116.573 E0.01682
*111 | Recv: ok | Send: N715 G1 X99.335 Y98.584 E0.79996*100
| Recv: ok
| Send: N716 G1 X99.981 Y98.696 E0.02063
*109 | Recv: ok | Send: N717 G1 X117.858 Y116.573 E0.79499*108
| Recv: ok
| Send: N718 G1 X118.393 Y116.573 E0.01682
*103 | Recv: ok | Send: N719 G1 X100.508 Y98.688 E0.79534*90
| Recv: ok
| Send: N720 G1 X101.006 Y98.651 E0.01571
*80 | Recv: ok | Send: N721 G1 X118.928 Y116.573 E0.79696*109
| Recv: ok
| Send: N722 G1 X119.463 Y116.573 E0.01682
*103 | Recv: Error:checksum mismatch, Last Line: 720 | Recv: Resend: 721
2018-01-07 23:05:32,744 - octoprint.util.comm - INFO - Ignoring resend
request for line 721, that still originates from lines we sent before we
got the first resend request 2018-01-07 23:05:32,762 - octoprint.util.comm
- INFO - Got a resend request from the printer: requested line = 721,
current line = 724 | Last lines in terminal: | Recv: ok | Send: N718 G1
X118.393 Y116.573 E0.01682*103
| Recv: ok
| Send: N719 G1 X100.508 Y98.688 E0.79534
*90 | Recv: ok | Send: N720 G1 X101.006 Y98.651 E0.01571*80
| Recv: ok
| Send: N721 G1 X118.928 Y116.573 E0.79696
*109 | Recv: ok | Send: N722 G1 X119.463 Y116.573 E0.01682*103
| Recv: Error:checksum mismatch, Last Line: 720
| Recv: Resend: 721
| Send: N721 G1 X118.928 Y116.573 E0.79696
*109 | Recv: Error:Line Number is not Last Line Number+1, Last Line: 720 |
Recv: Resend: 721 | Send: N722 G1 X119.463 Y116.573 E0.01682*103
| Recv: Error:No Line Number with checksum, Last Line: 720
| Send: N723 G1 X101.426 Y98.536 E0.80208*87
| Recv: Error:Line Number is not Last Line Number+1, Last Line: 720
| Recv: Resend: 721
2018-01-07 23:07:09,596 - octoprint.util.comm - INFO - Got a resend
request from the printer: requested line = 1605, current line = 1606
| Last lines in terminal:
Going back to FW 3.1 again!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2285 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABaAf8SmChdgibzNeZKnSJR8VhvvPFrWks5tIwDWgaJpZM4RBlOx>
.
|
|
Firebug24k - Can you give me your private email address? |
|
The reason I’m asking is that i’d like to share some more information with you! |
|
Just wanted to throw this in here: https://shop.prusa3d.com/forum/original-prusa-i3-mk3-f30/octoprint-issues-and-tips-t13156.html Firmware 143e (on the forum but not yet on the main page) removes a couple features because they were apparently overloading the board and causing serial issues. I haven't yet tried it but I'll give it a shot when I have the time. |
|
Soo... First day back from a much needed vacation. Happy new year everyone. @justinmrkva Thanks for the link to this thread. Just from the increase in communication issues and also the fact that someone somewhere reported the printer making funny moves, before I clicked on that thread it sounded suspiciously like a similar issue I had with another vendor firmware on a printer here where they did too much in a interrupt handler, causing the serial connection to get out of sync and causing loads of garbled communication as a result, which made me think this might be a similar case. After reading the thread it sounds like my hunch was pretty much spot on ;) @Firebug24k You said "Settings > Serial communication > Advanced options > Simulate an additional ok for resend requests" didn't solve this for you. Did you reconnect to the printer after enabling that checkbox? Because this definitely worked when I simulated the problem here against the virtual printer. |
|
So referring to Marlin's considerations to linear advance (http://marlinfw.org/docs/features/lin_advance.html#considerations-before-using-linear-advance), I would try 57600 baud, but the Prusa firmware denies the connection at that speed. |
|
Hi， @rnldnkp . |
|
There is no way to force anything. The issue seems to be in the firmware/rambo board because of not enough time to handle the serial input (as far as I understood). |
|
1.3.7 introduces a dynamic workaround for this by starting a timer after a resend request is received. If no |
|
Closing as 1.3.7 was just released. |
What were you doing?
The issue occurred during a print after starting/heating/leveling and during the actual printing phase.
What did you expect to happen?
The print should have continued normally.
What happened instead?
The print head suddenly stopped. Extrusion stopped but the heated bed and hotend remained on. The OctoPrint web interface became partially unresponsive; canceling did nothing, and the temperature graph did not update.
In one case, the print failed after only a couple layers. In the second case it failed after roughly 60 layers.
It looks like OctoPrint may have been re-sending the wrong line. Note that in the Terminal log (pasted below) lines up to 66557 were sent and the last line was 66555. Although the logs say "Resend: 66556", the actual line that is resent contains "N66555" which was already received.
In both cases, I reset the Pi and started the print again using the exact same gcode, without reuploading it or changing any settings. In the first case, the print continued and finished successfully. In the second case, the print is in progress and has printed past the point of initial failure.
Did the same happen when running OctoPrint in safe mode?
I have not tried safe mode. Since the issue is intermittent it is difficult to reliably reproduce.
Version of OctoPrint
OctoPrint 1.3.5 (master branch)
Operating System running OctoPrint
OctoPi 0.14.0
Printer model & used firmware incl. version
Prusa i3 MK3, latest firmware as shipped (currently beta, the latest version on the site is older).
Browser and Version of Browser, Operating System running Browser
N/A
Link to octoprint.log
Excerpt log: https://gist.github.com/justinmrkva/22288e9b5e7df2e0999e6c229f9fe960
Link to contents of terminal tab or serial.log
Terminal tab: https://gist.github.com/justinmrkva/03f869d34e85691c59195ca5258b70c2
Excerpt provided here for clarity:
Link to contents of Javascript console in the browser
N/A
Screenshot(s)/video(s) showing the problem:
N/A
The text was updated successfully, but these errors were encountered: