I keep seeing posts on the various Facebook Groups that print quality suffers using Octoprint (Raspberry Pi) since there is a "bottle neck" between how much data Octoprint can deliver, via USB, to the 3D printer. I've seen some say you should have Octoprint save the file to the SD card to remedy this. I've seen others advise reducing the print speed to 40 mm/s or quality suffers. I've also seen suggestion people buy ferrite core-equipped USB cables to quash interference between the Octoprint server and the printer.
I'm just curious how much of this is urban myth and how much is really fact?
Personally, I have 4 Octoprint servers on 4 Raspberry Pi 3's and have not seen any quality differences between using them or printing direct via SD card. I usually print between 40-50 mm/s, depending on the quality requirements of the print. I have an Ultimaker 2+, two CR-10S printers and a Geeetech A10 using Octoprint. I have three others I haven't attached to Octoprint yet (awaiting delivery of some additional hardware).
But...I am also not an expert in the finer details of I/O operations of hardware and software protocols.
If MythBusters was around, I'd ask them
Perhaps we can discuss these comments and debunk, or verify, they are indeed known issues?
It's obvious that with USB the maximum print speed lowers:
The incoming data has to be processed. Checksum control, moving the line to the input buffer, taking the recent command from the input buffer, clearing that line in the input buffer, sending information to the USB host. And all this besides the printing calculations.
So it is not a problem with OctoPrint only.
I'd say the firmware's configuration.h settings are another big factor as I mentioned in an issue on OctoPrint and someone who took that advice to solve their shredding problem. Basically, one can adjust the size of the receiving controller board's buffers to accommodate faster bandwidth.
In mentioning factors about one's setup, I'd suggest that many things are going on:
What slicer is being used, what version of that slicer, what profile settings were used in that slicer and what overrides were used for the file in question
What printer, what controller board, what firmware and configurations within it
The type and length of the USB cable which connects the Raspi with the controller board
The model of Raspi and the quality of the microSD card
The collection of plugins running which themselves hook into the serial stream
The overall type of the printer: cartesian, delta or otherwise
The type of leveling that's in use as compared to the configured speed of Z axis
Whether or not the good UART is in use for the stream
Whether or not the PIXEL Desktop has been loaded as well
Whether or not a webcam is streaming back to the browser and whether or not the browser has been refreshed
The number of simultaneous printers trying to be run from the same Raspi
I can definitely vouch for unshielded cabling causing bandwidth issues, though. And I can also vouch for slamming the four cores of the Raspi with too much simultaneous work, causing stuttering.
What would be brilliant would be to have a visual interface of the effective throughput in realtime of the serial line plus an indication of the outbound and inbound queues on both sides. When you do see a stutter, you'd then say "aha, the firmware's inbound queue was max'd out!" perhaps.
I'm just curious how much of this is urban myth and how much is really fact?
It's fact. On prints with a lot of small segments anyway.
If your print is a giant cube, you're unlikely to see any sort of speed or quality improvement from lowering the print speed, at least nothing that's not attributable to your printer being garbage at high speed.
If you're printing an item with hundreds of small segments in a row, you are very likely to see the print suffer because of the octoprint -> usb serial -> mcu transfer speeds, and possibly even the speed of the printer's control board.
I tested this a while ago by making a cylinder in openscad with like millions or billions of segments around the circumference vs a cylinder with a more normal vertex count. It's a test you can easily do yourself if you want to prove or disprove it. The more segments your model has, the more gcode is needed to change directions, the more your host has to send, the more the board has to process. That combined with the relatively small buffer in the printer means it might execute all those moves faster than the usb serial rate can keep up with and thus isn't necessarily limited to octoprint, but any host that prints via usb.
I'm glad I asked this question....fascinating insights.
So would a good option be to utilize the "Upload to SD Card", which I assume moves the file to the SD card installed in the printer itself? Based on what I am seeing here, that seems to be a good alternative to weakness of the 3D printer's serial communications chipset?
@OutsourcedGuru: Obviously.
A cylinder is a simple attempt. But for this, there have to be long straight runs and tiny complex structures.
Finally we will find out, that the 8 bit controller age for 3D printers come to an end.
Either faster boards (32 bits) or splitting calculation and driving as it's done with Klipper.
This may be one of those times when you need to reply with "That depends..."
For a delta type of printer if it's combined with an 8-bit Arduino then this probably spells disaster. Possible fixes would be to 1) slice in such a way that you're not looking for that much detail (lowering the line segments), 2) upgrading the Arduino board to something beefier, 3) introducing Klipper into the mix to offload decisions back to the Raspi, 4) reconfiguring the firmware to increase the buffering.
For other types of printers the calculations aren't quite as difficult. If it's an 8-bit Arduino, perhaps an upgrade would be the fix if you expected the same kind of detail. Or compromise on the quality and dial things back in the slicer for the number of segments. Likewise, you could take the same advice as before.
If a Raspberry Pi Zero W is in use, I would consider stuttering to be a pi-side problem in this case and upgrade to a Raspberry Pi 3B.
In setups where the Raspi's Bluetooth or similar has stolen the good UART (another pi-side problem), I think I would suggest changing the setup to avoid that. One can also purchase a second good UART as an add-on board for the Raspi which might work.
Way easier, just a bunch of cylinders will do, you don't even need to print anything, just run the printer in circles in mid air and you'll see whether or not you suffer transfer speed issues, buffer underruns, or whatever.
I just used openscad with like one line of code to create a cylinder with a stupidly high segment count.
cylinder(d=120,h=20,$fn=16); cylinder with low segment count cylinder(d=120,h=20,$fn=16000000); cylinder with dumb as segment count. Will probably take like an hour to compile. I used openscad so I could be sure the program wouldn't mess with the mesh on export and decimate the vertex count like some programs that I won't mention. Also if I remember, it took like half an hour or some crap to slice as well and my computer probably ran out of memory and crashed. You might want to lower that segment count. 16 million segments was just an example.
Surely if you are connected to the printer via USB, UARTs (on the Pi) don't come into it?
You do realise most arduino based printers aren't actually usb devices, right? That fancy usb plug you're using, isn't actually a usb plug. It's a serial cable. The printers usb plug just goes to a usb-serial chip (CH340 in the case of chinese boards, FTDI chip in the case of expensive ones, or another atmega chip with usb-serial firmware on it). Most of the time you're communicating with your printer via serial, at serial speeds, the same speeds you connected your dialup 56k modem to your computer at. Why do you think you're selecting com ports and baud rates in octoprint?
Some newer printers might be actual usb devices with usb speeds, but I'd wager 99% of those $150 printers from ebaliexpressbabadotcom are serial based machines with serial communication speeds.
the question is mostly answered already but I have some free time (everyone asleep here, NY came 36 min ago, me celebrating my b-day by having some time with myself for few hours till kids are up ... so before everything HAPPY NEW YEAR FOLKS!!! let our printers run true ) so I'll add some experience I collected over last ten years with 3d printers...
The slower transfer will produce a sh*tload of issues like pauses, zits, overextrusion, lips, bad corners, pronounced faces etc etc ... even failed prints.. I assume everyone is clear on that, how it happens and why (the effects on print) ... now why / when the slower transfer will happen depends on few factors
if you use a sh*tty host device (for e.g. rpi) that you load with bunch of tasks (mpeg encoder and streamer, bunch of plagins in octoprint, maybe another service that was nice to have on rpi like samba or whatever else you added) your host device will not be able to push data fast enough and you have issues with transfer speed (solution, remove some load or use faster device like rpi3 or orangepi with h5 or.. use externali IP camera so you don't need to run streamer..)
if you use a sh*tty client device (for e.g. 8bit atmel) and you overload it (for e.g. you run coreXY or you run DELTA or you run new fancy options like pressure advance, mesh bed leveling, graphics screen.. ) it will not be able to handle input stream that's too fast ... (solution is usually remove some of the options and increase serial buffer, or use a faster client device like smoothieware or duetwifi or some other 32bit board or fpga board or ...)
if your client or host device have sh*tty serial port (some of the mini devices are known to share usb hardware with some other hardware, e.g. share usb interrupt with ethernet or wifi) .. solution - change device (host or client whatever is problematic)
sh*tty board (host or client, usually client) that has bad EMI protection so you have bunch of noise on your USB line so the USB is not "ok" so you have errors and retransmissions. check your syslog if you have a linux host (rpi or orangepi or ..) there will be USB errors if that's the case. sometimes this can be solved by using short usb cables and adding the ferrite ring on both sides of the cable, but usually you just want to scrap that board and get a new one
(should be actually no1 but I forgot), your rpi/opi power is shi*ty and since you don't supply enough current to your host it flickers and creates all different kind of problems including this ones
for e.g. I'm running bunch of octoprint's on orangepi one (H3 cpu only octoprint, I don't run mpegstramer there as I use external ip cameras) running bunch of plugins with smoothieboard on the printer and I never seen a problem with transfer speed ...
not most, ALL 8bit arduino based printers are serial devices, the atmel chip running the firmware communicates via serial port with usb2serial chip (first originals FTDI, later originals AT90U.. first clones used fake ftdi, new clones use CH340) but no, they don't talk 56k .. most of the atmega's in use can talk 1.5mbps over serial, iirc marlin support 1mbps, safe value (due to poor pcb design, marlin doing other stuff then talking to usart ..) is up to 250k which is still 4.5x faster then 56k (not to mention 56k modem had asymetrical speed, 56k was one way other way was only 28k or slower) ... anyhow 250k is plenty fast for 3d printing ...
for few hours till kids are up ... so before everything HAPPY NEW YEAR FOLKS!!! let our printers run true