Blobs on the Surface of Prints

What is the problem?
I get very blobby print surfaces since the printer sometimes stops for a fraction of a second

What did you already try to solve it?

  • Increase Buffer sizes (see my marlin configuration.h and configuration_adv.h)
  • different USB cable
  • added a ferrite bead to the power cable of the pi
  • Try some of the solutions people with the same problem used

Logs

serial.log
octoprint.log (142.9 KB)

Additional information about your setup
OctoPi Version 0.17.0, running on Raspberry Pi 3 Model B Rev 1.2
OctoPrint 1.4
Printer Sidewinder X1 with Firmware Marlin 1.19

Configuration.h (72.2 KB) Configuration_adv.h (68.9 KB)
plugins.json (113.9 KB)

This topic/issue is discussed in depth here: The ongoing USB Conspiracy Theory?
In short: there is a bottleneck in the serial transfer from OctoPrint to the router and a lack of calculation power with 8-bit printer boards when it comes to high resolution routes the printer hotend has to handle.
A quick workaround is to reduce the slicing resolution of the slicer.

1 Like

I have actually seen this thread already and thought I already was using the

for octoprint. I added dtoverlay=disable-bt to /boot/config.txt an removed console=serial0,115200 from /boot/cmdline.txt.
If possible, I would also like to talk directly to the Board in the Printer without going to USB and back using /dev/ttyAMA0, but i couldn't find good instructions so far. Is there even a way to do it without a level shifter?

I guess in the end ill just be buying a 32 bit board :man_shrugging:

1 Like

If you're good at adjusting your firmware (Marlin), try increasing the default receive buffer.

Another option is to reduce the print speed. This should reduce the serial bandwidth requirements.

Already have, and while I was at it, I also upgraded to marlin 2.0.3(iirc) because I was having difficulties getting enough free progmem currently I am using

#define BAUDRATE 250000
#define DEFAULT_MINSEGMENTTIME        50000
//#define SLOWDOWN #define SERIAL_XON_XOFF
#define RX_BUFFER_SIZE 1024
#define TX_BUFFER_SIZE 32
#define MAX_CMD_SIZE 96
#define BUFSIZE 32
#define BLOCK_BUFFER_SIZE 16

I disabled Arc support and all display features as well as a couple other features to leave 20% progmem.

I am wondering if disabling

// Printrun may have trouble receiving long strings all at once.
// This option inserts short delays between lines of serial output.
#define SERIAL_OVERRUN_PROTECTION

might have an effect, right now I am printing something at 50% feed rate and seeing how the result is going to be

1 Like

This is somewhat unrelated, but why did you disable arc support? Is this for performance reasons somehow?

Presumably he was chasing memory on his controller board so that he could increase the buffers.

Any idea how much memory this saves? I'm curious because arc support is essential for a new plugin I'm writing (the one I just messaged you about). I hope disabling arc support isn't too common :frowning:

This is the first time I've heard anyone removing it.

1 Like

I think it might be quite common with people adding a BLTouch with an 8-bit Melzi board. It saves a fair bit of memory and is recommended in at least a couple of Teaching Tech YouTube videos from last year. It's certainly commented out in my Marlin 1.1.9, where it saves about 4KB, IIRC.

1 Like

Wrt memory usage, there are two types of limits: ram and storage. Disabling arc releases some storage space, which is indeed needed if one wants BLTouch to work on base Melzi board (these only have ~128kb of storage).

On topic: have you tried increasing "Maximum resolution" in the slicer? it's been documented by CNC Kitchen: https://www.youtube.com/watch?v=Hvw3DrVAeTA
Also have a look at "Maximum deviation" as it's linked, and WILL override the above one, if needed.

The reason for people removing Arc Support is that common 3D slicers might never use it. It is stated that Ultimaker's Cura is not supporting curves. Other slicer might not either.

We get that... but Cura should include this. Imagine if your gcode file is suddenly 50% smaller in size?

The problem is, that the stl-file format does not support arcs in any way. stl-files store the surface of an object in a bunch of triangles: https://en.wikipedia.org/wiki/STL_(file_format).

Only cad programs that support slicing can make a benefit of using gcode arc commands.

That's what FormerLurker is interested in looking at. Since the slicer folks haven't picked up on this yet he's interested in bridging that gap.

1 Like

Check dryness of filament, it could contain moisture

Usually that would be accompanied by plopping sounds

:laugh: My filament is always too-dry. I don't think I've ever seen the blobbing on mine, though. I now run it through a wine bottle cork in a reservoir with canola oil and everything's great.

1 Like

@mathiaspl20, are you still having problems? If so, and if you're willing to re- enable arc support, you might be interested in trying out a new plugin I've created that may help.