Hello, I had similar issue using Octoprint with my Artillery Genius (8bits motherboard). During print, the extruder was making micro pauses and this generated blobs. To solve this, I had to adjust 2 parameters in my FW. They are situated in Configuration_adv.h and I updated as follow:
BLOCK_BUFFER_SIZE from 16 to 32
TX_BUFFER_SIZE from 0 to 32
Guess I’ll have to:
- Figure out how to modify the FW
- Figure out where configuration_adv.h is
- Adjust the buffer sizes
- Figure out how to re-compile the FW
- Try to reprint a blobby part
Sound about right?
You may not need to modify the FW but we won't know for sure unless you take the time to fill out the template that appears when you open a new, Get Help, issue. This topic is over a year old so I strongly suggest that you start a new one.
Of particular interest is the serial Resend ratio. You will have to provide the log files generated from a failing print probably including a serial.log which you should enable before printing the failing part.
@rumancz thanks again for the direction. Getting closer.
@b-morgan makes more sense to leave the problem/solution set here.
I looked at the logs and there were no errors. No weird messages/codes, either, when it would pause (usually lasting anywhere from .5-1.25 seconds).
My primary question, at this point, is why is this issue happening? Changing the buffer sizes, if truly the issue here, after ~3 years of a known issue, should have made it into the 2.0.x version of Marlin, should it not?
Anyways, learning my way around VS so I can change Configuration.h and Configuration_adv.h as needed. Will update this message after uploading the recompiled code.
But first, printing a slightly diseased Dalek after upgrading the board to 4.2.7. 
Well that was just a HOOT!
VS/Platformio was actually easier than I thought it would be. Got a single compile error because the .pio folder gets created AFTER the first attempt to compile. That was fun. After that it was smooth sailing.
Reprinting a round-ish part to see if the new buffer sizes cure my ails.
Did you succeed with changing that setting? In the FW I am using the buffer is set to 16 currently, so I might also give it a try.
Actually I am having the same issue, now that I saw the images above (small blobs or gaps somtimes, especially at curves) and I also noticed that short sounds coming from the hotend sounding like either filament shoots out or there's a small break creating some bubble of air or filament in between which then shows up in the print like above.
Did not even think about this could be an Octoprint or FW issue, but now makes much more sense!
No Sir, issue remains unresolved. So “starting from scratch: printed Benchy directly from an SD card. Looks great. Now printing Benchy from OctoPrint in Safe Mode. So far it’s looking pretty good. IF it comes out looking exactly like the… benchmark Benchy, then I’ll print in Normal Mode minus the plugins I installed. PrettyGcode, Octolapse, Resource Monitor, TouchUI and Dashboard.
Was OctoLapse active this whole time? There will be blobs when it's taking its snapshot if you haven't tuned the stabilization options.
Stabilization Options? There are a few options that I noticed, but not sure to what you are referring, specifically. But to answer your question, yes... OctoLapse was active when getting the blobby print.
I'm running OctoPrint now in normal mode and, AFAICS, everything is printing nominally, compared to the SD card print. No pauses/blobs. OctoLapse and TouchUI are still disabled.
BTW: What Pi do you use?
RPi 3 B v1.2. Just scored a 4GB RPi 4 so will eventually have that running, instead.
OK, I am at a loss. Just finished a 24+ hr print. No pops, no blisters and ON OctoLapse. The only thing I can attribute towards the successful print is that I deleted the plugin and re-installed. I guess the old "did you reboot it" step just needed to be taken an additional level. Thanks for all the suggestions!
FYI,
Just by coincidence I saw that whenever I press F5 to reload (or simply first time load) the Octoprint User Interface, I can see the printer start to stutter and create very ugly blobs and stripes as long as the Octoprint web frontend loads.
I already disabled almost all plugins now, but still the issue occurs. Is the Raspberry Pi Zero 2 W simply to weak for it? Or is that a side effect of the new Octoprint V1.8.1 as I definately did not see that problem with 1.7.x before?
This type of reaction to initial page load of OctoPrint has been discussed before, even prior to 1.8.0 IIRC.
Ok, here are 2 examples, first one is what I just described, that longer blob/stripes occuring in loadin the frontend (at the top of the print):
And that one shows the micro dots on the left side, almost entirely occuring on rounded shapes, happening independant from the user interface issue above:
the little micro holes look like layer start/end positions, assuming your slicer settings are configured for random locations and not have aligned seem? compare it to your sliced gcode (showing travel moves) and see if there is correlation or not with that theory.
No, the seam is at the side (not visible on the pics above). Using Cura 5.0 0.28mm all default settings.
This happens on any filament since 1.8.1.
Have you tried it in safe mode?
Yes now, same issues - also with disabling all plugins...