Ugh.
While that is not my firmware but a fork of it, we can try to troubleshoot it anyways. Your particular issue is definitely not related to OctoPrint though, so I think we should rather talk via PM than clog the forums. Feel free to send me your GCode so I can try to replicate it on my base firmware.
I'm doing one test run with your fw now. Just t make sure where the problem is.
Interesting that the non factory fw works well printing from SD but not from Octoprint.
Gcode sent 
Printing over Rpi 3B+ / USB / Octoprint with the updated firmware from David. Quite an improvement but the conical one is still not as good as the straight cylinder.
Davids updated fw.
Comparison print done by:
- SD card
- Octopi on Raspberry Pi 3B+
- Octoprint on Intel motherboard (Debian)
.
Octopi:
.
Intel PC (debian+octoprint):
.
SD:
Sorry for different lighting, new photos are daytime...
Conclusion, Davids fw is 100% up to par with stock fw now. And SD still beats Octopi but Octoprint on Intel is similar to SD
1 Like
First, very nice investigation! It makes your results easy to interpret, and much more useful than your average post.
I do have a few questions. Are you running any plugins on your OctoPi instance, or are you running in safe mode? Is logging enabled on your OctoPi instance at all? Have you had any PSU undervoltage/overheating warnings at all?
I'm surprised that there are obvious differences on such a simple model. I've done similar comparisons on my MK2 and haven't noticed any differences between SD and OctoPi, though that's definitely model and slicer dependent. I could definitely create gcode that would give OctoPrint some problems but not an SD print if I wanted to by sending a very high number of commands per second.
I wonder what would happen if you doubled the maximum Z-stepper speed and repeated the SD print of the conical.
Anymore discussion on this issue? I have an I have an MKS L1 Board running Marlin 1.1.9 on an Ender 3 connected to a fresh Octopi instance on a Raspberry PI 3+. Every so often (10 to 30 seconds) my print just pauses for about .5 to 2 seconds, thus depositing a blob of extruded filament on whatever spot it happens to be at. I use Cura 4.0 and have tried changing resolution but no help. Someone mentioned the possible bottleneck of the RPI so I installed the Windows Server version of Octoprint and printing from there works flawlessly.
I'd much rather use the RPI but after may hours troubleshooting I am about to give up and came here where I saw this post.
Any help would be greatly appreciated.
Thanks.
There are actually Raspberry competitors out there which have beefier hardware and are presumably compatible with Raspbian. I personally wouldn't trust a Windows-based computer since it's prone to any number of upgrade-without-your-permission scenarios.
1 Like
This frequently happens when small cylinders are sliced. The slicing creates many small line segments. Normally the time to print a line segment is so long in comparison to the time to send a gcode that octoprint can keep the buffer full. But when these very small line segments are sent the time to print the line segment starts to approach the time to send the commands so octoprint can no longer keep the buffer full. If the buffer empties a small pause is introduced and you get a blob. Even if the buffer does not completely empty the path planning will not be able to keep a stead speed and you can get deceleration and acceleration cycles that will be reflected the print quality. The SD card or faster octoprint hardware can help to keep the buffer full.
I think that is why some people say they have no issue with octoprint and others say the prints are bad. In the normal case of a complex model with a mixture of long and short line segments no difference will be seen between octoprint and an sd card. But on simple cones and cylinders that are sliced very finely a large difference can be seen.
1 Like
And the raxda are full open source the raspberry is not.
1 Like
well i did not say something because i am an octoprint noob.
but i noticed too that from SD cards my small prints look way better than when octoprint is running.
of course the gcode is the same for octoprint and on SD card.
i am using an anycubic mega s.
Blockquote But when these very small line segments are sent the time to print the line segment starts to approach the time to send the commands so octoprint can no longer keep the buffer full. If the buffer empties a small pause is introduced and you get a blob. Even if the buffer does not completely empty the path planning will not be able to keep a stead speed and you can get deceleration and acceleration cycles that will be reflected the print quality. The SD card or faster octoprint hardware can help to keep the buffer full.
new hardware. well i just bought that raspberry..... 
Increasing the receive buffer size in the configuration of Marlin has also been seen to help, for what it's worth.
I have an SKR v1.3 and I'm having the exact same problem. Did a benchy print once my SKR got installed and got blobs. Did it again and really watched and saw the printer would pause for about 0.5 to 1 second and make a blob then continue printing. Printed another benchy from SD and no issues at all. Tried upping every serial buffer setting I could find in configuartion.h but none of it made a difference.
1 Like
Did you find any fix yet?
I recently started to observe the same problem on my Ender 3 prints using the SKR v1.3 and OctoPrint v1.3.11. I don't think I had this problem before, maybe an OctoPrint update caused the problem.
I too am wondering if there were any updates this. After a few months of running the windows server I decided to do a new install on my 3+ to see if the new version fixed anything but it did not. Would running on a Pi 4 perhaps fix this?
Have you increased the receive buffer size?
@SapuSeven
Couldn't also an update of the slicer (or change of it's settings) make this difference you see? I remember one update to Cura for example introduced delays that was rectified with turning of some setting.
I have the latest Cura and I did check all of the settings that would affect this as well as some of the suggestions. Since it works fine from Windows server and SD card it seems it is definitely a Pi bottleneck. I will try the receive buffer size change but previous posts in this thread didn't mention it working.
btw how fast are you printing? (mm/s)
Thanks for all the suggestions.
As it turned out, I think the cause was a bad USB cable from the RasPi to the SKR v1.3. After switching to a new cable, my Ender 3 resumed printing perfectly without any blobs, like before.
1 Like