Print failing when resend is requested #166
Comments
|
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. |
|
I stand corrected, it complains about missing linenumbers, not about missing checksums. Still weird though. Which marlin version is that? |
|
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. |
|
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 |
|
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. |
|
OK, gcode and serial log: http://dontshootx.com/print_problem.zip |
|
Ok, I see the issue, after the first resend of 2347 it sends 2350 twice |
|
I have also experience this issue, On Mon, Jun 24, 2013 at 7:35 AM, Gina Häußge notifications@github.comwrote:
|
|
Sorry for the trouble, the resend calculations are pretty mind bending. |
…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.
|
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? |
|
@whyvas could you provide a logfile please? |
|
The terminal output: Recv: Resend:369 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! |
|
First of all, thanks for the compliments :) Secondly, this looks a bit different than the other logs with that issue. I hope that this way I'll be able to see where it exactly it goes south. |
|
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. |
|
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 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. |
|
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... |
|
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 |
|
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. |
|
I could try to load xvnc and pronterface on there, I guess. I just On Sat, Jul 6, 2013 at 4:42 PM, Gina Häußge notifications@github.comwrote:
|
|
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. |
|
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. |
|
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. |
|
I've reflashed my pi from scratch and reinstalled octoprint and it hadn't
|
|
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! |
|
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... |
|
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 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 |
|
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 . |
|
Please update. 1.2.0 was released last week, which includes all the changes mentioned above. |
|
ok thanks! will do that. Will post it here if I encounter any more issues. |
|
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. |
|
@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. |
|
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! |
|
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. |
|
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. |
|
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. |
|
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) Hopefully this may save some evenings of unlucky guys |
|
Any idea what happend? two times on same model at same percentage...
|
|
If it happens at the exact same line I'd check if maybe your GCODE file contains that 0-byte garbage data already. |
|
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.
|
|
It still looks like the file you are trying to print has some garbage data in there. Could you upload and share the file? |
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 |
|
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. |
|
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. |
|
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 |
|
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) |
|
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... |
|
@MiregSan That doesn't appear to be the correct file. The line successfully sent just before the offending line is 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 |
|
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. You do get to learn a lot when facing those problems :) -Mat |
|
The FAQ is part of the wiki, which anyone with a Github account can edit ;) |
|
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. |
|
Hi, i have new information for investigation. Now i try new raspberry pi zero ( temperature and power supply are ok). |
|
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 :) |
and others
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
The text was updated successfully, but these errors were encountered: