Is that smoothieboard or you are using some MKS or other clone? Looking at the dmesg it seems like a fairly common issue with bad hardware clones usually have... lowering speed (in config.ini) and using shorter higher quality cable helps but depending on what hw you have sometimes there's no help... MKS for e.g. is heavily affected by EMI and will drop uart connection often... I have similar issue with some conversion I made where turning motors off at end of the print (drop the enable pin on drivers) will in 80% cases drop the USB connection
If the serial cable isn't shielded (with a metallic sheath inside) then it's susceptible to noise and errors at higher speed. Remember, the circuitry for 3D printers has those steppers and they emit a lot of electromagnetic noise.
Add one of these to the cable and it should be more forgiving of noise in the air: ferrite core
This is with a creality ender 3 (has a CR-10 Board), I have a high quality shielded cable with a ferrite choke on it as well as the PI's PSU has a choke as well.. This board won't connect at any baudrate other than 115200 it seems
config.ini, find uart0.baud_rate set to different value, reboot printer if that's smoothieware...
not sure where did I read it's smoothieware since I can't find that info now (my apologies I might be mixing two threads) and afaik original CR10 is running marlin ?! In order to drop comm. speed on marlin you have to recompile the firmware, IIRC creal... recently published full sources for CR10 firmware so it should be simple, and testing it with lower speed should give you valuable info
And although it's not been said yet, a Raspberry Pi 3 will do a much better job of running the printer and streaming video than, say, a Raspberry Pi Zero which only has one core.
And although it's not been said yet, a Raspberry Pi 3 will do a much better job of running the printer and streaming video than, say, a Raspberry Pi Zero which only has one core.
This is with a "Raspberry Pi 3 Model B" Going even further using this cable : http://a.co/h0hgMRr with this power supply http://a.co/5YWN6K Although I'm not getting low voltage warnings I did see some negative reviews on that PSU and have another replacement coming today to try..
Just to be pendantic, your cable isn't shielded and yet it's fine for what you're doing given the ferrite core.
Here's an example of one which is and note that the price tag is around four times what you paid for yours. Okay, so it's an HDMI cable but it actually has the word "shielded" in the product's title.
And I note your Raspi 3 response. (Good.) Your power supply link doesn't work, btw.
The absence of low-voltage warnings could be something as simple as your /boot/config.txt configured to not display them: avoid_warnings=1. A better test is to run vcgencmd get_throttled having remoted into the Raspi and try to interpret what you see. You want zero as the output.
From another thread here in which I said:
Running vcgencmd get_throttled should return a variable throttled=0x50005 which ought to be zero if no throttling is occurring (either due to under-voltage or that it's too hot). Following up, a vcgencmd measure_temp (with my own output of temp=41.9'C) will show you if it's looking hot or not which could then rule out temperature.
The low threshold for input power is 4.65VDC, I believe.
So now, back to the issue at hand, I myself recently have been working on a contrived rig and had some problems getting things to work. I had to go all the way down to 9600 baud for it to test okay. But I was watching the terminal responses from my program so that I could see the garbage characters that were coming back from the downstream printer.
1 other thing I just remembered though is I do have a piece of tape over the positive voltage rail on the usb cord connection to the pie so it doesn't backfeed power through my board.. That couldn't possibly cause any issues right ?
So... you're saying that you added some tape inside the Type A end of the USB cord which goes to the Raspi so that the printer doesn't supply power to the Raspi.
If you did it perfectly, then this shouldn't affect you.
If you accidentally also covered either the RXD or TXD pin on that connector then it would behave as you've described.
sorry mate my bad, I was doing something with smoothiware code and replied to your post somehow seeing that you use smoothieware ... happens ..
the 115200 is already too slow for some precise short moves, if you have a lot of them, so going as fast as possible is always advisable .. the idea to lower down the speed is just to test if that would solve the problem, but it's not really a solution... if you can't have the stable connection between the two I'd go with sdcard printing ..
now said that, I seen soo many issues wrt PRC made cables (long, short, expensive, cheap...) so using brand name cables actually makes sense... I have rather good experience with ugreen, it's prc made, cheap, but never had any issues with them (does not mean it's 100% safe, main issue with PRC made stuff is quality control so some % of delivered goods will always be faulty) ...
I seen alu tape help (use alu tape, wrap around cable, connect to ground on one side only, so to either printer or to the rpi) but...
I'm not very good with marlin, see with marlin experts if you can somehow debug marlin and see what happens when you lose connection... I'd personally attach a logic analyzer between usb2uar and atmega ... your board, what usb2uart chip it uses? some cheap ch30 or atmel u* chip or ftdi? it can be a faulty chip, it's known to happen ...
If your cable isn't too long, you can temporarily make a "poor man's shielding"...
get some aluminum foil
and some Scotch tape
cut the aluminum foil in long strips of the same width as the circumference of your serial cable
put some Scotch tape on the table upside down (securing the ends)
put the aluminum foil strip on top of the tape so that a 1/4" of the tape isn't covered
wrap the aluminum foil + tape around the serial cable, aluminum side toward the cable
stick the tape so that it stays
wrap it again with tape so that none of the aluminum can short to something else (insulating it)
Then put it back into service. A real version of a shielded cable then connects the ground wire to the shielding but this version is good enough. If you find that this poor man's version allows you to connect to your printer, then go buy an expensive one.
that's kinda worse possible scenario ... since afaik ENDER 3 is a CREALITY I seriously doubt that board uses original FTDI chip as @PythonAteMyPerl already suspected ... those chips are so unstable ...
Check the board, see if, maybe, between ftdi chip (the only chip after usb connector) and big atmega chip are some 3 or 4 test pins, maybe even 3-4 pin header? try to follow traces from those pins where they go to ftdi chip or to atmega chip... if those pins are exposed you can bypass the crappy chip and connect uart directly from rpi to atmega
of course, before all that, try a decent usb cable (for e.g. the short blue cables being sold on ebay/ali 50% of those don't work at all, and the other 50% work if there's no lot of interference around them) ... see if you have usb cable you got with some MFP printer, those are usually great ... also, check, doublecheck and tripple check power to the rpi and remove that 5Vusb tape you added
I have started to get the same problem the last few weeks Octoprint on my Pi 3B + have been working well on my Ender 3, but suddenly it has started to get "communication error" mid print.. and about 50% fail rate is starting to become a problem Any suggestions is welcommed to say it mildly hehe