Same GCODE file twice. Right one printed via Octoprint, left printed via SD card. I really really really don't want to print via the SD card, love Octoprint!!
I've read it could be a Marlin buffer size and USB speed problem? My Octopi baud rate is 250000.
STL file used: http://magnus.thome.nu/tmp/ugly.stl
Can you post a link to the Configuration.h and configuration_adv.h you used to compile Marlin?
You could try with a bigger BLOCK_BUFFER_SIZE, maybe 64 or 128.
I don't think the ascii input buffer BUFSIZE will change much, but you could give it a shot anyway.
Are you using a recent version of Marlin?
How large is the gcode file?
That's a good question!
Checked, it's 2MB
Yes, Marlin 1.1.9 tweaked for Anycubic Mega S with Bltouch, this one:
I have done no changes in the source at all apart from a port number changed in the pins_TRIGORILLA_14.h file.
I'll see what happens with BLOCK_BUFFER_SIZE changed 
Can't compile with 64 or 128, the cpu doesn't have enough memory for that (without me trying to rip out something else to make room...). This is with it set to 64:
Global variables use 11039 bytes (134%) of dynamic memory, leaving -2847 bytes for local variables. Maximum is 8192 bytes.
Not enough memory; see http://www.arduino.cc/en/Guide/Troubleshooting#size for tips on reducing your footprint.
Error compiling for board Arduino/Genuino Mega or Mega 2560.
Since I can't increase buffer size in Marlin for the Atmega2560 I installed Debian + Octoprint on an Intel motherboard last night. Will do some tests today to see if there are any differences in print quality.
But it really can't be possible it should look this bad with a Pi 3B+ and an Atmega2560 based printer board? There must be something else making the curved areas hard to print with Octopi.
So I installed Debian and Octoprint on an Intel motherboard with a bit more grunt than the Rpi 3B+.
This is the printing results, red = Rpi, blue = PC with Linux
The first is just a simply cylinder, nothing more. The second is a slightly conical cylinder (harder to print!?)
Check your slicer. It might be putting out hilariously small segments. The smaller the segments, the more data has to be pushed to the printer over serial and a non optimal communication protocol, limiting the achievable speeds before you run into starvation issues.
Also check that you aren't running into severe communication issues and your printer and OctoPrint aren't kept busy with constant resend requests as a consequence.
There is a hard limit regarding the achievable speeds over serial:
Compare that to serial where the controller can just read the file line by line from the file and doesn't have to checksum it (or puzzle it together from bits read from serial).
The results you are seeing are - in my experience - very unusual though. I have seen other people run into similar problems with unreliable communication and suboptimal slicers configurations though, hence my earlier recommendations.
Check your slicer. It might be putting out hilariously small segments. The smaller the segments, the more data has to be pushed to the printer over serial and a non optimal communication protocol, limiting the achievable speeds before you run into starvation issues.
I've been having similar issues recently when printing from OctoPrint. I have a small whistle that I knocked together in OpenSCAD. It has curved surfaces that are rendered with $fn=90. The STL produced by OpenSCAD is about 2.25MB. I brought it into MeshLab and ran a simplification that reduced filesize to about 128K.
I then sliced both in a recent beta of Slic3r PE. The gcode produced from the OpenSCAD output is 692K. It complained a bit about the MeshLab output, but was able to repair it. The repaired MeshLab output is 154K, and it sliced to 673K...not much smaller than what I was getting with OpenSCAD. It would appear that Slic3r PE (and probably vanilla Slic3r too) is doing some simplification already.
I had previously tried increasing BLOCK_BUFFER_SIZE in Marlin from the default 16, but the resulting image had so little free RAM left (even though it was under 8K usage) that I suspect the stack was getting clobbered, causing Marlin to crash pretty badly. I tweaked some other buffer sizes so that gcc reports total RAM usage of about 7K with BLOCK_BUFFER_SIZE set to 32. Just completed a test, and strangely it made things worse. I'm now going to print the same file from SD with BLOCK_BUFFER_SIZE set to 32 while I build PyPy and try getting OctoPrint running under that (it's currently using the standard CPython).
I would've expected BLOCK_BUFFER_SIZE to mitigate issues with printing while streaming over USB. It'll be interesting to see if Marlin still has issues with the increased BLOCK_BUFFER_SIZE when printing from SD.
Thanks for all thoughts on the issue! Some reflections:
Slicer and slicer settings:
The odd thing is I'm using one of Cura's three fixed factory default presets, unchanged. The 0.2mm slicing setting with no changes to it whatsoever. So the slicing really shouldn't be extreme in any way and must have been used millions of times.
File sizes:
The STL file size for the two cylinders is 311kB when the refinement setting in Fusion360's STL "Make" export is set to "medium". With refinement set to "low" the file is 124kB, I haven't printed that smaller file yet though. Would exporting from Fusion360 set to medium be a unusual decision? What do you who are more experienced say, does the STL file size give you any sort of indication if it's normal size or larger than "normal"? (I've just started with this stuff a few weeks ago so I have no feeling for what is large and small)
The GCODE file from Cura with the Cura factory preset for 0.2mm is 1.6MB.
What is the same and what's not between the two Octoprint printed parts? (putting SD card printing to the side for the moment)
So comparing two ways of printing with Octoprint - Rpi 3B+ or much faster HW - shows quite a large quality difference. These two tests where using:
baudrate - identical
usb cable - identical
same 8 bit printer motherboard, well the whole printer is the one and the same
serial driver in the OS, well, Debian was used for both prints but on vastly different underlying USB/serial hardware I guess, so different drivers too probably.
Speed limiting factors with Octoprint/Python/all the stuff Octoprint is doing, yupp, way more cpu grunt and tons of more and faster memory and.. simply much faster HW running Debian in the Intel setup
Still, as you say, I'm seeeing something unusual when running Octopi on the Pi? And what I am having trouble with on this pretty bog standard setup on the fastest Pi is much helped by faster HW. But... why am I seeing this with default Cura settings and a not at all uncommon printer... very very puzzling.
Hi There,
I had similar problems on a standard i3 mega. I had to clear out some functions from marlin to increase available memory. On the Facebook boards they were distributing modified firmware that included additional functions but caused Octoprint comms to be impacted significantly due to the 8-bit board running out of memory (or something buffer related).
I'd recommend even cutting your marlin right down to only functional features to give you some headroom and try again as it is what fixed things for me.
Interested to see if there is a better solution.
I'll do a test with stock firmware vs davidramiro's firmware!
Not quite the same but... I am running OctoPrint 1.3.10 running on OctoPi 0.16.0 with a pimped out ender 3 2560 GEN L Trinamics all the toys and recently if I connect to octoprint via my web browser the the print stutters and it blobs and the line thicknesses become uneven for a few min's , this is exacerbated if the webcam stream is running as well, It started when the OctoPi got updated to 0.16.0. recently I have been using prota to print with from my laptop the Pi 3B+ is sat lonely in its housing unused 
Quick example, that's what happens if I click refresh in my (Chrome) browser while printing, or any of the menu's or functions.
Seeing the disc, i suspect the problem is not overrunning marlin´s buffer, It could rather be that the Pi needs too long to feed the data into the usb stream. I never printed from SD and even on the both printers where i use orang pi zero i never came across any of the shown problems. But i only use a camera on the main Pi3 based Printer with 640/480 res at 10 fps to keep it low on cpu usage. Also i have already seen plugins which cause some increase on cpu usage, and thrown them off again.
That is a very good thought! The webcam bogging down the limited hardware. So I disconnected the webcam from the 3B+ and disabled webcam and timelapse in the Octoprint settings and... no change whatsoever in print quality I really thought you had the solution there.
Did your comparison of my firmware vs the stock one give any results? I am very curious, we can try and work on this together. Although we really can't increase the buffer that much with our chipset, we could try to at least reduce the impact somehow.
I'm doing some tests right now, will post back!
