Unsure on what the Resend Ratio is referring to? Is it network related in regards to packets to the Pi? Or is it referring to and from Pi to the Printer?
On my last print, a simple tower test, I recieved over 30k resend rate. Is this bad?
What did you already try to solve it?
I have re-installed my OctoPrint via the OctoPi Image and changed the cable from my printer to my Pi with still the same results. Only a small variation in quality between printing from the SD from printing via Octoprint.
Have you tried running in safe mode?
No
Did running in safe mode solve the problem?
N/A
Additional information about your setup
OctoPrint version: 1.5.2
OctoPi version: 0.17.0
Printer:Ender 3 Pro
Main Board: BigTreeTex SKR Mini 3 v1.2
Firmware: Marlin 2.0
Browser: Safari
Operating system: OSX Big Sur
It is between OctoPrint and the printer. 30k is quite high, but then it would be better to look at the percentage. Also check 30k was not the total number of lines sent, resend ratio is like this
Thank you for the crazy quick response! Proving once again the 3D print community is the friendliest on the web.
Okay that makes a bit more sense. I believe then I mis-read it, it showed 0/32k 0%.
So as you explained that would mean that there was no re-sends and there is a good connection between printer and Pi.
I believe I am experiencing similar issues. This is my first print after upgrading to OctoPrint 1.5.2 last night. I'm not as savvy as most on here, but I'll try to provide the information I think is pertinent. I have a 0% resend ratio but I can't recognize any communication issues. I can send gcode commands and receive the expected responses. My print failed last night after what appears to be a timeout (the error message asked if my printer was still alive). I power-cycled my octopi and printer and edited my gcode to pick up where it left off. It restarted printing and then the printer stalled later after another communication style time out (still 0% resend). I've disconnected octopi and am printing caveman style from an SD card.
I am using a stock Creality CR-10 from ~5 years ago
Version 0.17.0, running on Raspberry Pi 3 Model B Rev 1.2
Things that have changed since the last time I used the printer:
I upgraded octopi to 1.5.2 ( I don't know what I was on previous to this, it's been almost a year since I've used my printer)
I am using the "TSD" App: Access Anywhere - The Spaghetti Detective : 1.4.7
If you have 0%, this means you have no issue, not a similar one
It is a percentage of total lines, showing how many are bad vs how many succeeded. 0% bad commands works. New feature in 1.5.x to display communication issues that might have been hidden. If you've got timeout issues, they are completely unrelated to resend requests.
At least I lead in with "not being savvy".
Thanks for the quick response. I'll dig deeper and start a separate topic when I have more information. Sorry for the derail.
I was able to get my resend ratio down to 4% by replacing the basic power strip that both my Ender 3 Pro and my Rasberry Pi power supply were plugged into, by a more expensive one that has surge protection and more importantly an EMI filter.
Before that, I was constantly above 15% and Octoprint was basically unusable for me. I hope to get resend ratio down still from 4% to 0% as I am currently using a basic USB cable and have a shielded one with ferrite cores on order.
That should hopefully take care of the last little issues because my prints are no longer crashing but the printer still seems to sometimes pause for no reason so I get little blobs of filament there.
Update, even though I did get resend ratio down to below 1% with the filtered extension socket and shielded USB cable with ferrite cores for the serial connection, I am still getting a lot of print artifacts and even failed prints.
Some further investigation showed me I am experiencing the same kind of issues that @koreth reported in https://community.octoprint.org/t/ender-3-v2-pi3b-or-pi4-lot-of-unknown-commmand-and-utf8-chars-electro-magnetic-interferences/24633/4 and I can trigger the garbled send/receive to occur in the same way by sending M17 / M18 commands.
I tried grounding the Raspberry Pi to the same ground as the printer internals by connecting GPIO39 (GND) to pin 2 (GND) on one of the unused connectors on my LCD display but that did not change anything unfortunately. Next step I will try is powering the Pi from the Ender 3 PSU, hopefully that will resolve the issue same way as it did for @koreth
Oddly enough, switching from the stock Marlin firmware to Klipper seems to have taken care of my retransmission issues entirely.
Either that, or Klipper simply is not reporting on them. In any case, I have (touch wood) not seen any printing artifacts since changing to Klipper, so firmware is also potentially something one might want to look at.
For what it's worth, I am on an Ender 3 Pro with a 4.2.2 mainboard (aka the Ender 3 pro "1.5")
I don't think Klipper will report resends to OctoPrint, since the resend would now happen between Klipper and the Klipper on the mainboard side, rather than between OctoPrint and the printer mainboard. It's highly unlikely that the communication between Klipper and OctoPrint would have to have resends.
But that's not to say it didn't solve the issue - the firmware absolutely could have been the issue, and the different implementation of Klipper resolved the artifact issue.
Thanks Charlie, I figured that's what might be going on.
Looking at /tmp/klippy.log it does seem to be showing some bytes retransmitted still but very very minimal, and this number seems to have been at 9 bytes from the moment the connection was first established (so not rising while I print)
Octoprint is remaining at 0 resend, so I'm going to conclude that the issue is gone and the 9 bytes retransmitted are just a remnant of the serial connection being established when the printer was first powered on.
I still plan to power the Pi from the Meanwell PSU via an LM2596 buck converter, if only to have everything powered from a single lead instead of still having the separate power adapter for the Raspberry Pi.
I had similar issues, for anyone if it might help, I taped off the 5v on the usb cable cause the raspberry pi send 5v to the printer while it has it's own. after this I had no more issues with terminated longer prints. hope it helps you or anyone else👍
Very New to 3D printing, but not to computers and electronics. I was having a very high resent ratio (19% - 20%) and longer prints halting with communication errors on my Ender 3 Pro. I was also having the back-power issue with my Pi 4B. I took a short (about 12") USB micro B cable I had, and carefully removed a small section of the outer cover, and while disturbing the shield as little as possible, I reached in with a pair of wire cutters and clipped the power wire. I then folded both ends of the power wire onto the outer cover to prevent accidentally shorting the power wires to the shield, and taped them in place with electrical tape. I double-checked that there were no accidental shorts or opens with my DVM, and plugged it back into the Pi and printer.
I also took a short female to female 0.1" jumper cable, cut off one connector and put a crimp connector on that end. I attached the jumper to a ground pin on the Pi's GPIO connector, and the crimp connector to the frame of the printer.
I'm currently 1 hour into a 5 hour print with 0 resends.
