Blobs on the Surface of Prints

mathiaspl20 · March 28, 2020, 6:54pm

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

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)

Ewald_Ikemann · March 28, 2020, 7:22pm

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.

mathiaspl20 · March 28, 2020, 8:03pm

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

OutsourcedGuru · March 28, 2020, 8:54pm

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

b-morgan · March 28, 2020, 9:02pm

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

mathiaspl20 · March 28, 2020, 10:42pm

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

FormerLurker · March 30, 2020, 4:57pm

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

OutsourcedGuru · March 30, 2020, 5:28pm

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

FormerLurker · March 30, 2020, 5:29pm

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

OutsourcedGuru · March 30, 2020, 5:31pm

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

pnt103 · March 31, 2020, 7:44pm

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.

seb · April 1, 2020, 2:32pm

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.

PricklyPear · April 1, 2020, 8:12pm

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.

OutsourcedGuru · April 1, 2020, 9:37pm

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

Ewald_Ikemann · April 1, 2020, 9:51pm

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.

OutsourcedGuru · April 1, 2020, 11:42pm

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.

ProtomakerSprint · April 3, 2020, 1:00pm

Check dryness of filament, it could contain moisture

Ewald_Ikemann · April 3, 2020, 2:52pm

Usually that would be accompanied by plopping sounds

OutsourcedGuru · April 3, 2020, 3:44pm

: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.

FormerLurker · April 8, 2020, 6:47pm

@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.