You can read more about it here if you think I’m imagining it or delusional. I’ve experienced this aberration with a cheap Creality Ender 3 as well as a rather expensive Prusa i3 MK3. These movements translate into artifacts marring up the finish of your prints. And while the SD card slot with it’s faster speed throughput has no problems, the USB port connecting your printer to the Raspberry Pi simply cannot keep up and send G-Code fast enough, which ultimately causes jerky and stuttered movements. Under the right circumstances, or wrong in this case (and also vastly determined by the complexity of your model) the USB/Serial interface can become saturated with data. When connected to the USB interface, as Octoprint requires you to do, your rather weak 8-bit 3D printer needs to parse the thousand of lines of incoming G-Code to print your model at a constant rate. And although I already use Octoprint (for monitoring really) it sadly introduces print degradation, albeit through no fault of its own. Now before you get all up in arms and cry foul, I know there’s a simple approached – a newer Raspberry Pi with WiFi and Octoprint, right? Well, yes, sort of. So if you’re into 3D printing, read on, it might just save you some grief… Introduction I know, first world problems…In this installment, I’d like to propose a viable alternative to this rather common conundrum. Recently, I’ve been playing around with 3D printers and having a blast doing so! But one thing has always troubled me: the manual process of sending sliced G-Code files to the printer.

Toshiba flashair tool manual