Printer slows down around tight bends, with blobbing as a result...

Hi

I've got some issues with my printer... The single largest contributor to making my prints look like crap at the moment is that the printer slows down a lot when encountering tight circular/rounded turns.

I would assume this is due to the fact that getting around such a turn requires a lot of instructions, if you can only instruct the machine to move in straight lines. Maybe the instructions aren't getting there quick enough, or maybe the printer can't handle enough instructions fast enough. I don't know.

This would be okay if it wasn't for the fact that control of the extruded plastic is kind of bad. Just because the extruder slows down when the printer slows down, that doesn't mean that the plastic flow is going to slow down until after a few seconds.

So basically, all my small round perimeters look horrible, they are lumpy, blobby and ugly. I can remedy this by printing more slowly, but who wants to print any part bigger than a few cms at 15 mm/s?

Does anyone know how one might fix this issue?

The experts will need to know what material, temperature, extruder hot end, firmware and slicer. Maybe layer thickness and width too.

I see... Though I don't believe most of this matters much...

3 mm PLA

Varying temperatures, haven't noticed any difference even between 190 and 240 to be honest.

I have a 3dstuffmaker Creator, it's called. Rather unusual model I have come to understand, because of this I can't really say what hotend or firmware it is.

I'm using slic3r, but repsnapper has shown the exact same issues so I don't believe it's slicer related.

I heard there is some fancy firmware called Marlin, but I don't know much about the PCB of this printer, so I have no idea if it is compatible with the usual rep rap firmware...

Here,

[forums.reprap.org]

It's not the same problem. His problem is related to a slow Z axis movement, causing plastic to ooze out when he changes layers...

What you describe does sound like a problem I used to have before I switched to Marlin. No promises though.

You're going to need to learn a lot about your machine if you want to improve it. It's just not possible to make meaningful changes if you don't know what it is you're changing.

Two possible reasons:

Using a firmware which stops at every corner before accelerating to a new direction. This can be slow on circular shapes made out of short straight segments. Change to use Marlin firmware.

Or printing an object which has an unnecessarily large number of polygons, which causes the printer to run out of commands when printing the tight shape. Raise the communication speed or reduce the polygon count. I had this problem with Nautilus Gears. The teeth and some other parts are made of so small polygons that the printer starts stuttering when printing the perimeters.

I had a similar problem whenever I would print small objects with lots of polygons (3D scans of faces). Whenever the printer got to an especially complicated part of the model, it would pause for a few seconds and then start again.

I was using an older non-gen6 version of Marlin (running on RAMPS1.4) and a mid 2012 version of pronterface (running on an old Windows XP Dell laptop) with serial communication at 115200 baud. I would also get intermittent serial errors that would completely stop the print (or worse yet, with an older version of pronterface, would restart the print and then crash into the half finished print). I played with the buffer size in Marlin and upped the baud rate to 250000, but neither to these things seemed to fix either of the problems. I built two Prusa Mendels with identical RAMPS 1.4 electronics and firmware and the serial errors were much worse with the second printer (to the point where it was failing on every other print). I replaced the arduino mega on the second printer and this definitely helped, but didn't completely solve the problem.

What finally fixed it was switching to Repetier firmware and Repetier host. It seemed like there was a serial communication bottleneck and Repetier firmware can use a more efficient binary encoding for the instructions instead of wasting bandwidth by sending the gcode in plain ASCII. I also followed the Repetier host firmware instructions and replaced the arduino serial communication code with the version provided along with the firmware prior to compiling and uploading the firmware. I'm not sure which change made the difference, but the problem went away on both printers!

I just read the entire thread more carefully. If changing the firmware in your printer is not an option, I bet ttsalo's suggestion of reducing the number of polygons in your model will also help. The easiest way I've found to do this is with Meshlab. Use the Quadratic Edge Collapse Decimation command (I believe this is in Filters > Remeshing, simplification and construction). Meshlab has a pretty steep learning curve, but a google search should pull up some great video tutorials on youtube.