Also, just to rule out a possible source of issues, see if the presence of the SD card in the printer makes any difference. I've seen some weird 
related to SD cards on printers.
2 Likes
Oh ! Completely unexpected hint 
Added to the list of tests, thanks !
I think you should look at the psi you are using for the pi, if it is giving off bad rf it could be affecting the output through the usb cable to the printer
1 Like
Hello,
Small update after multiple tests : I'm now conviced that EMI are the root cause. Problem not fixed, but I'm still chasing.
Here's a picture :
From left to right :
- printed from the SD Card, in "wood pla"
- printed on Octopi / Raspi3b+ / SD Card inserted (not used)
- printed on Octopi / Raspi3b+ / SD Card removed (hello @foosel ;))
- printed on Octopi / Raspi3b+, No DS, Extraction Max at 3000mm/min (50mm/sec). I thought it was stringing, and I thought that Octopi could have modified the GCODE to limit the extruder. I was both time wrong
So, the stringing you see is not stringing. Models are printed with nearly no travel. Sometimes, the head just decide to jump in the point n+30. That's why my first message referenced a "weird communication", because I just thought that Octopi was flooding the printer. It still could be, but I doubt.
The good thing is that I know have found a way to make tests. I just start a print from the SD, and monitor the logs in the terminal. Octopi is not the problem, it's the solution. And so, I feel like I should stop asking for help here; I may just use these thread as a log of what I'm trying; maybe someone will find it later.
Here are some interesting logs :
Extract 1 : while the printer is printing, I hit the connect button.
2020-10-09 19:02:42,164 - octoprint.util.comm - INFO - Changing monitoring state from "Offline" to "Opening serial connection"
2020-10-09 19:02:42,180 - octoprint.util.comm - INFO - Connecting to port /dev/ttyUSB0, baudrate 57600
2020-10-09 19:02:42,195 - octoprint.util.comm - INFO - Changing monitoring state from "Opening serial connection" to "Connecting"
2020-10-09 19:02:42,813 - octoprint.util.comm - WARNING - Received line:
2020-10-09 19:02:42,814 - octoprint.util.comm - WARNING - | \x00JJ
2020-10-09 19:02:42,815 - octoprint.util.comm - WARNING - The received line contains at least one null byte character at position 5, this hints at some data corruption going on
2020-10-09 19:02:42,975 - tornado.access - WARNING - 409 GET /api/printer (::ffff:192.168.200.247) 9.56ms
2020-10-09 19:02:44,985 - tornado.access - WARNING - 409 GET /api/printer (::ffff:192.168.200.247) 18.60ms
2020-10-09 19:02:45,827 - octoprint.util.comm - WARNING - Received line:
2020-10-09 19:02:45,828 - octoprint.util.comm - WARNING - | \x00JH\x00Ljj
2020-10-09 19:02:45,830 - octoprint.util.comm - WARNING - The received line contains at least one null byte character at position 5, this hints at some data corruption going on
2020-10-09 19:02:49,110 - octoprint.util.comm - WARNING - Received line:
9vS0-10-09 19:02:49,111 - octoprint.util.comm - WARNING - | ÈNHLzÎê\x00JHLzzjøgú½
2020-10-09 19:02:49,113 - octoprint.util.comm - WARNING - The received line contains at least one null byte character at position 23, this hints at some data corruption going on
Extract 2 : while the printer is printing, strange things are received
Recv: echo:Unknown command: "¢\x81\xffÏ\x02\x01¯\x87"
Recv: ok
Recv: echo:Unknown command: "4"
Recv: ok
Recv: echo:Unknown command: "\x04õ¥"
Recv: ok
Recv: echo:Unknown command: "\x01"
Recv: ok
Recv: echo:Unknown command: ""
Recv: ok
Recv: echo:Unknown command: ""
Recv: ok
Recv: echo:Unknown command: "\x05õþ\x01U\xff\xff\x05´u\x11"
Recv: ok
Recv: echo:Unknown command: "\x14"
Recv: ok
My thought, now :
- It is not clear if the PSI is the problem, or the USB connection. I doubt, cause I've tested many cables + different power units, including two official RPI; I do a lot of arduino / rpi things, I never encountered such issues, but I also never use serial interfaces …
- It is not clear that the issue is not in the Printer's mobo. When plugged of, moving the bed manually will drive enough power from the motors to actually light the screen. I've discovered that when the printers does nothing, there's no noise on the serial line; when the printer is at work, there's a lot of noise ("unknown commands"). I'm convinced that the noise comes from motors, directly in the mobo.
If anyone have an Ender 3 Pro v2 (with the 4.2.2 card) and managed to work with Octopi, I'd be happy to know which setup you use, especially brands of your power unit and usb cables – is that a thing, shielded micro-usb cable ? Can't find one anywhere 
Last words : thanks for the hints and help !
Cheers,
K.
Ooh, that is quite interesting.
I just had my mind blown while thinking to a simple thing : connect the serial to a standard computer. MacBook Pro connected to the printer via USB. Using the command screen -L /dev/cu.usbserial-12345, I look at the console output and see nothing like with the raspi.
Print test : as perfect as from the SDCard. Case solved, Raspi (3b+, 4) are having trouble with EMI. Even with PI far away from the printer. I've used the same USB cable from the laptop and the Pi. Tried the PI with official power sources, also powered from the USB hub of my computer (which is not great, raspi are suffering from lack of power), and power plugs from smarphone manufacturers (Samsung, HTC, …).
Two things I'm thinking about :
- powering the Pi from the PSU of the printer may negate the noise
- powering the Pi from a (passthrough) powerbank may help
- I don't know if "grounding the Pi" is a thing, I may try something like this
Cheers,
K
I've tracked down the problem. The only thing I managed to do was narrowing the test. I found it fun so I wanted to share it here.
The printer sends nasty things as soon as steppers are enabled.
I first turn the Temp Autoreport on (a proof that the line is clear).
Then, I turn the steppers on (M17). Here comes the mess.
I finally turn off (M18) the steppers to get back to a clean serial line 
The next step will be to power the PI from the printer's PSU. If the problem is what I think (the PI not being grounded via it's PSU), that will do the trick. I think I had no issues with arduino, since none of them was grounded to the 220V. There might be something that send noise over the power lines which finishes in my raspi.
See ya 
1 Like
That is a GREAT idea to test with M17/M18, will have to remember that for future debugging help. Also really interested on your further findings!
EMI on a Pi is a new one, I've seen a lot of crap over the years though and it wouldn't surprise me tbh.
1 Like
Hey
So, I finaly powered the Pi through the printer's PSU.
As expected : it works !
I suspected a lot of noise based on the fact that the Pi and the printer have non-shared ground; as well mentionned here, Creality's printers emits a lot of noise (due to motors, mainly). I never encountered the issue because it's the first time I play with real electricity :D. Arduino+Raspi have no issues for obvious reasons.
So, here's what I've done :
- buy some XT60 Y-connector
- cut one child of the XT60, goes to a LM2596 to get a 5V from the 24V
- power the Pi from this new 5V line
- Bonus : power a relay module with this 5V too, pinned to GPIO40 of the Pi
- Strap the USB power pin (because uhubctrl doesn't work well with Raspi 3b+)
- Install PSU Control and now I can even power off my printer from Octoprint
Octoprint is really a fantastic product. Thanks to the Terminal command, your help and a bit of reading, I spent some wonderful hours debugging this (as many, I love the path more than the destination ;)). Thanks also to Ragheera, I've sourced the relay/duck thing from their print on Thingiverse, they even shared an electronic schema ! (https://www.thingiverse.com/thing:3483446).
Last but not least, it may be time now to look at plugin writing. PSU Control is cool, I may want to be able to extend it with commands like ... trigger a uhubctl command when receiving a M80
I think I've reached a goal now. I'm in debt, so I'll watch the forums and offer help if possible.
Thanks again !
K
2 Likes
Thank you so much for getting back to us here with the latest findings, and also the kind words.
This is a great example of how to participate in this community that couldn't have come at a better time, thank you so much! 
1 Like
You might be interested in this plugin...https://github.com/OutsourcedGuru/OctoPrint-USBControl.
You cannot be more accurate in that statement. I found it a very positive experience keeping up with this thread and appreciate the time and effort that went into this debugging done by @koreth. It's unfortunate that the new creality boards seem to be so problematic.
1 Like
Hey
To be fair, my electric system here seems to be hard. It may be that one of my equipment is leaking a lot of noise to the line, and the creality may just be failing at filtering this, which is not a requirement for 99% of users. Plus, I'm a rookie in 3D printing so, I'd be happy to share the responsibility with Creality on that one
Thanks for the hint about the plugin. I tried it, but found no parameters to trigger USBControl upon event (like "print finished"). I know Octoprint has such a mechanism (signals). The thing is, printing from a Rpi3b+, if I shut my USB off, there's no more communication with the printer, so I don't want it permanently. I'm using a strap on the USB cable for now.
In french we say « avoir le beurre et l'argent du beurre » ("keep the butter and the money")
K.
1 Like
Hey @users and @foosel !
I'd like to share my experiences with these problems and how I solved them. Maybe you @foosel can include this solution in your FAQs for the new "resend requests".
Soo my printer is an Ender 3S and it worked just fine with an Raspberry Pi 3. But suddenly i experienced all these errors in my terminal, for example:
[Error:Line Number is not Last Line Number+1,]
echo:Unknown command: ...
and so on - especially when the steppers are on!
Because it has worked well so far, I searched for the solution by changing cables, repositioning the RPi or trying another power supply. But I finally found it!
The day before i printed a drawer and pushed the cable for the LCD just behind it - like this:
And that was the problem! After i re-arranged the cable according to the picture below (as I had it before and as you can see on the picture)
1 Like
ALL the errors went away - the amount of resend requests went from 16% down to 0% and print artefacts went away.
(sorry, have to split my answers because i cant post more than one image per reply)
Also the problem came back when i pushed the cable back behind the drawer, so in my case this was definitely the root cause of the problem.
So if you are facing these problems: check your printer cable!
7 Likes
Spent a day looking at the resend ratio issue that I was getting, I did the switched to use different Raspi's / cables. Also reinstalled Octoprint on the Pi, installing Octoprint on a windows tablet, and it was all down to the control cable!!! Why would this be the case? Anyway, thank you for the posting your solution it helped me track down the problem, and now I'm back to been able to use Octoprint 
1 Like
Bad cables can be very susceptible to interference, since they may not be shielded/twisted together. Or over time, the connections within can degrade and so becomes a bit intermittent at transferring data. There's a whole number of reasons, good that you got it sorted!
Thank you sir.. after days of troubleshooting, moving things around.. creating a shielded enclosure for my raspberry pi, cutting power line in a usb cable, adding ferrites, etc.. I knew the problem was only caused when stepper motors are used, but also when using the menus on the Ender 3 LCD.
I had folded the ribbon cable on top of itself and clipped it out of the way. Last night, I ordered another Pi as I was sure that power back from the printer had damaged mine causing EMF sensitivity.. earlier today I read this thread.. I just unfolded the cable and now I am printing with 0 resends again.. with the cable folded.. i was getting them immediately after printer starting printing object (not during rafts) I would have 20% errors within the first 10 mins of printing and the printer would move erratic..
THIS FIX WORKED FOR ME!!! Thank you very much for this insight you have shared.
T.
3 Likes
You just made my day! After fiddling about with all kind of changes it looks like the display cable routing was the solution. I have put it behind the drawers and I had a lot of communication errors. Now I just folded it to the front en the errors seem to be gone!
Thank you, found this thread as I'd just started experiencing garbage and high resend requests since fitting my Pi 3B into a printer mounted case. I'd done the same and tucked the ribbon cable tidily behind the Pi.
Moving the cable and checking with the M17 / M18 commands seems to show no garbage, fingers crossed for this next print.
Thanks for this tip! For me, long prints were stopping because of comms errors. Running Octoprint from an old laptop rather than a Pi. USB cable is good quality Rather than re-routing the LCD cable, I wrapped the cable with aluminum foil (as neatly as I could) to form a shield. Also, fashioned a grounding wire by stripping a bit of copper wire, spreading the wire strands over another bit of foil and wrapped that to the shield. Taped the grounding wire to the shield, then taped the foil neatly (the foil is a bit fragile). Looped the other end of the wire and attached it to one of the control case screws on the bottom of the case. I had moved the power supply to accommodate the dual z-axis screw, so while I was at it, ran the ground wire to a screw on the power supply case as well. Clipped the LCD cable back to the extrusions so everything is neat again. Luckily, the aluminum wrap and tape didn't add much thickness, so I was able to re-use the clips. Worked like a charm! Errors went from over 12% (and killed the printer at one point) to 0%. Cheers!