TechPaladin Printing » Software

Nathaniel’s guide to high-detail printing

Nathaniel — Wed, 21 Dec 2011 16:41:58 +0000

A lot of people have asked me recently how I make extremely high-detail prints, such as this little gnome house:

Using a better firmware (Marlin) and a gcode generator that creates more sensible paths (Slic3r) are the first two things you absolutely must do. Without using both Slic3r and Marlin, you’ll struggle to print your perimeters at more than about 25 mm/sec without seeing severe blobbing on corners and arcs. Let’s assume you’ve followed my advice in Getting all the pieces to fit together and you’re using Marlin and Slic3r. Excellent! Let’s get started.

Low layer height

Layer height is the primary setting that determines the surface detail of your print. The lower the layer height, the greater the “resolution” of the print. A 0.3 mm layer height will display visible layers, while at 0.2 mm layer height, the layers will begin to appear smooth with certain filament colors. The gnome house above was printed at 0.2 mm layer height in silver PLA, which is very forgiving of surface blemishes. Black PLA is similar, and translucent blue PLA is even more forgiving, but white PLA needs lower layers and perfect layer alignment before they need to disappear; 0.15 mm layer heights and below, usually.

As for your nozzle diameter, the truth is, the relationship between your nozzle diameter and your layer height is a very loose one. A bigger nozzle lets you print with a slightly higher layer height, but doesn’t really constrain you that much when you want to decrease it. This is because the nozzle diameter merely determines the width of the extrusion that comes out of it. Even a fairly wide extrusion should react fine to being smooshed down on top of the previous layer. To sum up:

Larger nozzle (0.5 and above):

Taller (and more visible) layers possible
Greater maximum speed is possible

Smaller nozzle (0.35 to 0.4)

Shorter layers (< 0.1 mm ) possible
More contour on extremely short layers possible

One thing I’ll mention is that I do not recommend a 0.25 mm nozzle. That small of an opening makes it a real challenge to print quickly, and can lead to jams. I really like a 0.35 mm nozzle. I can get great high-detail prints, but I’m also able to print infill at 120 mm/sec without the extrusion getting too sparse. If I go much faster than that, though, I can see it start to string out. A 0.4 or even 0.5 mm nozzle would be better for higher speeds than that, but my focus is maximizing speed given a certain quality I want to achieve, so I’m more than happy to sacrifice a bit of potential infill speed so I can get the benefits of a lower potential layer height. Perimeters, of course, are printed much slower than 120 mm/sec to ensure good surface detail and layer alignment. Which leads me to…

Only maximize speed for the desired quality

In the beginning, I was so excited about pushing my printer faster than I sacrificed quality to ramp up the speed, going as fast as 65 mm/sec for the perimeters on this building. Now I know better. It’s far more sensible to pick a desired quality level and then maximize the speed without diminishing the quality.

Once you have a desired quality (say, 0.15 mm layers), you can set about increasing the speed until you start to see diminished surface quality. The exact speed you can achieve for your target quality will vary from machine to machine, so you’ll need to do some experimentation. Here are some tips:

Print hollow if you can. This really saves time and filament, and more models than you think can be printed without any infill at all. The real challenge is for models with flat tops; those flats need good bridges. But that’s not too hard if you make sure to keep your number of solid layers at 3 or more.
Print infill faster than perimeters. After all, nobody sees the infill! If you can’t print hollow, you can increase the infill speed all the way until the extrusion get stringy and begins to lose its structural integrity. For me, with PLA and a 0.35 mm nozzle, this is about 120 mm/sec.
Don’t print infill for every layer. Again, if you can’t print hollow, this is another good alternative. Skeinforge calls this “Skin”, but Slic3r uses the “Print infill every n layers” setting. Make this 2 or even 3 if your layer height is really low or you have a big nozzle.
For PLA, use a fan. PLA needs more time to cool than ABS, so the faster you go and the hotter your nozzle, the more imperative it is that you use a fan to cool the extrusion after it hits the previous layer.
Increase your first layer speed by moving the nozzle closer to the build platform. The only reason you need to go slow for the first layer is to ensure good adhesion. You can also get this by moving the nozzle closer to the platform, ensuring that the extrusion is really smooshed down. But don’t go too close or it can be tough to get the print off the platform!

Once you’ve got good prints with all that, there’s an additional piece of the puzzle that lets you increase the speed even more: a rigid frame. No matter how you slice it, the Prusa Mendel isn’t an especially rigid machine along its X axis. The faster I go, the more I can see the frame triangles wobbling back and forth. That won’t do! There are band-aids such as this brace but a better design is really needed. That design is the MendelMax. I’ve finished my MendelMax’s frame and axes, and the thing is rock solid. Even at very high speeds, I just don’t see it bending or wobbling at all. So get yourself a MendelMax!

Getting all the pieces to fit together

Nathaniel — Mon, 21 Nov 2011 07:07:15 +0000

This whole DIY 3D printing thing is pretty awesome, but I’m convinced that it can be even more awesome. Today, we generate gcode with generators that are kinda slow and clunky, and we use firmwares that are good enough but limit your speed. The reason for my relative blogging absence over the last two weeks has been due to some hardcore en-awesome-ification; I’ve been seeing if I can do better. It’s taken two weeks of learning and tweaking, but I’ve gotten pretty far.

Marlin

The most important piece of my puzzle is the firmware, which interprets the gcode into movements on the printer. Even if you sent the printer awesome gcode, if your firmware can’t handle it or does odd things with it, the results will be less than satisfying. I believe this picture will illustrate the differences between the Sprinter (the most common firmware) and Marlin. I’ve written about Marlin before, but here are two Yoda heads (both printed with identical gcode), the one on the left printed with Sprinter, and the one on the right printed with Marlin:

Observe the Sprinter print’s rough, frosty appearance. That frosted appearance is caused by the constant fast-slow-fast-slow sequence it follows due to the curves (which are really just a series of short lines after all) and lack of movement planning. The constant, minute motion also causes the extruder to vibrate quite terribly, even at fairly slow speeds (? 30 mm/sec). This not only slows it down, but reduces precision since the nozzle may be a few fractions of a millimeter off from where it’s supposed to be at any particular time. Marlin, by contrast, can plan its moves so it doesn’t have to slow down to draw each individual line segment, resulting in a smoother surface sheen and more consistent layers. Also notice how the Marlin print is unfinished, because a communication error killed the print mid-way through. This error, which I’ve reported, was totally preventing me from completing large prints with Marlin. Over the last few days, I’ve been working with the developer Erik Zalm to feed him information so he can fix it. It turns out that my Sanguinololu electronics are just too limited and were hitting a number of edge cases. Erik’s made some affordances for us Sanguinololu users, but PID temperature control has to remain disabled due to lack of memory.

I now recommend RAMPS rather than Sanguinololu due to the better system specs. It’s really only gonna be about $40 or $50 more expensive, but it’s totally worth it. Firmwares aren’t getting any smaller or less-full-featured.

…But at least Marlin is working again with my Sanguinololu thanks to Erik’s labors! Here are the final results; again, Sprinter on the left and Marlin on the right:

Slic3r

Next up, once you have a good firmware with movement planning, you need to send it better gcode. And one of the best gcode generator out there is Slic3r. Despite its extreme newness, Slic3r is quickly gaining acceptance in the RepRap community. When you compare it to our old standbys Skeinforge and SFACT, Slicer operates much faster, requires far, far less calibration and experimentation to get your settings right, and generates nice clean gcode even at very low layer heights, which I’ve found that Skeinforge struggles with.

It’s also full of bugs that make it not quite ready for prime time. But I can see the writing on the wall; Slic3r is destined to be our gcode generator, and I can’t wait for that day to arrive. To that effect, I’ve been doing a lot of work to test Slic3r with hard prints to find bugs. You can see a number of them on my desk here:

I’ve found the Vanderbilt Mansion (which you can see a several of above) to be a great print quality torture test, especially at very low layer heights. It’s got lots of details, straight walls, curved walls, slopes, domes, and subtle bridges. It will really show you what your printer has trouble with. I still don’t have a copy of it I’m sufficiently happy with that I’m willing to put online, but I’m getting there. It’s a tough print. Here are all the bugs ones I found trying to print that object and others:

Many are already fixed! Alex has released a new version of Slic3r that’s most excellent, and it includes lots of neat features, such as new infill patterns and a more tolerant parser. And my previous post about how cool Slic3r is has been featured on the homepage!

Here are prints that I’ve done with the new version. This is a SimCity capitol building:

Nothing super fancy, just a standard 0.3mm layer print, but Slic3r generated its gcode in about 45 seconds, and I think it came out great.

And here’s a print that I’m very, very proud of:

It’s one of Whyst’s adorable little gnome houses, and I printed it with exactly the same settings as the capitol building except for changing two things: I reduced the layer height from 0.3 mm to 0.15 mm, and I told it to only draw infill every other layer. That’s it. If you still need any more proof that Slic3r is awesome, I don’t know what to tell you!

Marlin rocks a little less still totally rocks

Nathaniel — Fri, 28 Oct 2011 00:43:32 +0000

Update: This was a case of PEBKAC. The problem had nothing to do with Marlin in the end.

I’d been merrily printing things at blazing speed (such as this SimCity 2000 building) and I’ve been really happy with Marlin’s ability to not only print faster, but smoother at the same time. Unfortunately, I’ve run into what I believe to be a reproducible bug in the firmware. I have a 3 or so hour print, and after a while, the printer abruptly starts printing each layer farther off to the right:

I’m using Replicatorg of course, and after printing the same model three times (second and third printed with a different gcode file after re-skeining), the same thing happens in the same place at the same time. I checked out the gcode in Skeinlayer and it’s fine; it’s definitely not telling the printer to make the mess shown above!

I’ll mention at this point that I changed Marlin’s baud rate to 115200 to get it to work with Replicatorg. Yeah, yeah, I’m a bad person and all that. I decided to try printing the same gcode file with Pronterface, keeping the 115200 baud rate to see if it was my fiddling with the baud rate or Replicatorg. With Pronterface, it exhibited the exact same problem, albeit it started messing up immediately rather than waiting two hours (how considerate!). I then returned the baud rate to the normal 250000 and printed the same gcode file with Pronterface once again and got the exact same result as when I printed that file at 115200 baud. So it’s definitely the firmware’s fault.

I’ve asked the Marlin devs for help, but in the meantime, it’s back to Sprinter once again…

Marlin rocks

Nathaniel — Sun, 23 Oct 2011 15:54:56 +0000

It turned out that getting Marlin to work with Replicatorg was drop-dead simple. All I needed to do was change the baud rate in the firmware to match the baud rate listed in the reprap.xml config file. Duh! In the past I tried changing the baud rate in the config to match what was in the firmware, but that didn’t work for some reason. Altering the baud rate in the firmware is the way to go. And that’s it; it just works. And the result?

It’s a goddamn print monster.

My Prusa is now buttery smooth. There’s just no other way to describe it. No more jerky movements; no more bubbles on corners; Marlin makes your extruder carriage seem like it’s floating on a cloud. The printer’s every movement becomes not only more graceful, but quieter. My Prusa is truly near silent now. While playing music at a low volume, I literally can’t hear the printer when it’s printing not 18 inches from my head. The loudest noise now is the faint squeak of threaded rod against M8 nut when it changes layers.

Don’t take it from me; see for yourself:

You’re gonna have to turn up the sound to hear anything, even with the camera about 8 inches away. That’s a Weighted Storage Cube being printed at 50 mm/sec for perimeters and 100 mm/sec for infill. I’m sure in practice it’s not quite reaching those speeds due to the small size of the object, but just look at that extruder zip around!

For even more awesome, grab this improved reprap.xml file for Replicatorg, made by ccotter247. Apparently, there was an easier way to get the extruder motor controllable from the Replicatorg control panel: remove the steper_axis variable from the machine config. Between that and my fix, this should Just Work™ in the future.

First Replicatorg patch

Nathaniel — Thu, 20 Oct 2011 04:51:40 +0000

I submitted my first patch (or “pull request” in git-parlance) to Replicatorg to fix issue #4 that I wrote about in this earlier post. As usual, the most challenging part was actually figuring out what part of the code was being called where, i.e. just what in the heck is going on. Once I got a handle on the flow, it was really quite a simple fix; in fact, somebody had even left a comment in the code basically saying “hey, I think this will break things”:

// TODO: Reverted to separate commands for enable + extrude + disable. This probably breaks 5D
machine.runCommand(new replicatorg.drivers.commands.EnableMotor());
machine.runCommand(new replicatorg.drivers.commands.Delay(extrudeTime*1000));
machine.runCommand(new replicatorg.drivers.commands.DisableMotor());

Yeah, you’re darn right it breaks 5D! That’s the driver used for RepRap machines, so of course the functionality didn’t work. I special-cased in working behavior for the 5D driver, since no other drivers seem to exhibit the problem:

// Reverted to one single command for RepRap5D driver
if (machine.getDriver().getDriverName().equals("RepRap5D")) {
  machine.runCommand(new replicatorg.drivers.commands.EnableMotor(extrudeTime*1000));
} else {
  machine.runCommand(new replicatorg.drivers.commands.EnableMotor());
  machine.runCommand(new replicatorg.drivers.commands.Delay(extrudeTime*1000));
  machine.runCommand(new replicatorg.drivers.commands.DisableMotor());
}

I think this change will really benefit RepRap users. Replicatorg will be a real first-class host app lacking no major functionality.

Marlin’s working again

Nathaniel — Thu, 20 Oct 2011 02:49:03 +0000

Turns out there’s a relatively easy solution to Marlin’s connectivity problems on Sanguinololu boards: in Marlin.pde, change BUFSIZE from 8 to 4. Now it works like a charm and you can turn your perimeter federate back up to 50 mm/sec and your infill feed rate basically as high as you want. I’ve only gone as high as 100 mm/sec but it looks like it go even higher. Now my next step is to get Replicatorg to support Marlin so I can use it for my stable setup…

Replicatorg!

Nathaniel — Thu, 06 Oct 2011 02:12:25 +0000

I managed to get Replicatorg working with my Prusa tonight. In some ways it was easier than I thought it was going to be. Here’s what you need to know:

Upgrade to the latest Replicatorg, available at replicat.org
Replicatorg doesn’t support SFACT, so you gotta make a real Skeinforge profile. Make one, if you don’t already have one. You can grab mine if you’d like. One important thing I had to do was disable the Export plugin’s suffix option or else Replicatorg wouldn’t automatically load in newly-created gcode files. I’ve filed a ticket for SFACT support, unlikely though it may be.
The reprap.xml file in Replicatorg/Machines usually needs some tweaking. I needed to set the e_steps_per_mm values for each axis to match what I had configured in my firmware. The build platform size needed a few adjustments, too. You can have mine.
Manipulating the extruder motor with the control panel doesn’t work. Since the motor behaves as expected while printing, I think it’s fair to say that this is a bug. I’ve filed a ticket.

Other than that, it pretty much all works. Now it’s back to calibrating and recalibrating with the new Skeinforge profile.

What an amazing machine

Nathaniel — Sat, 01 Oct 2011 04:43:33 +0000

My Prusa is finished and printing. And man has it been a rush. I’ve been truly amazed by how my new machine required no calibration to start producing beautiful prints. Now, I didn’t say “very little calibration”, or “almost no calibration”, I said that it didn’t require any at all. Feeling ambitious, my very first print was a gigantic starfish. However, it had a peculiar problem: each layer was a little more skewed to the right than the last one:

Eventually I figured out the issue: the filament, which was mounted on a spool to the right of the printer, was hampering the extruder carriage’s leftward movement by pulling it to the right. Solution: put the filament spool behind the printer, and problem solved. So this wasn’t actually a problem with the printer itself at all! After that, I printed another starfish that looked near-perfect.

I just don’t know what to say. This printer has absolutely shattered my expectations. I was thinking that it would be my “project” printer to hack on while the Makerbot did all the work; instead it’s proven itself to operate better in almost every way.

The layer alignment is perfect. Filament reversal is perfect. There are no strings or blobs on the exterior of the pieces. I haven’t even begun to push it yet, and I’ve gotten the Prusa to print more than twice as fast as I’ve ever gotten out of the Makerbot. On top of all this, the machine is very nearly silent. My wife and I watched a movie while the Prusa was printing not ten feet away in the same room and it disappeared into the background noise. Here, see for yourself:

Compare this to the racket my Thing-O-Matic makes while printing:

My only disappointment so far has been Pronterface (not a typo, sadly), the host software that seems to be most common. It’s pretty bad. Its interface is a mess and it lacks most of the features of Replicatorg, the program that my Makerbot uses. Luckily, it doesn’t seem like too much of daunting task to get Replicatorg to work with the Prusa, so that’s going to be my big weekend task.

Quick tip

Nathaniel — Sun, 14 Aug 2011 20:44:26 +0000

In Replicatorg’s “Motherboard Onboard Preferences” dialog box, increasing the “Z home offset” value puts the extruder nozzle closer to the build surface.

This is my shocked face

Nathaniel — Mon, 05 Jul 2010 16:16:32 +0000

Apparently the NSA with all of its billions of dollars of equipment, internet trawling, and email-sniffing were outwitted by these two-bit Russian spies for years. Ahh, I love it when my tax dollars fund unconstitutional, liberty-destroying surveillance regimes that don’t even work!