hits counter

Building and testing the Makerfarm Prusa i3 3d printer: The Software

Okay, you’ve got your new printer all built, you’ve got a power supply hooked up, and maybe, if you’ve got an LCD controller, you’re basking in the blue glow of success.

Now what?

Maybe you’ve checked out Thingiverse, or one of the other sites where people can share their designs.   YouTube has lots of examples of  printers creating shapes that have been shared and downloaded.  Maybe that’s not your thing. Maybe you got the printer so you could create your own stuff, and make all kinds of neat things that nobody has ever seen before.

Either way, you’re going to have to figure out how to talk to your printer, and that’s where it gets interesting…

Like most of these posts about 3D printing, this one is not so much of a “How to” as it is a “How I do it”.

What we’re going to need here is a good, old-fashioned software tool chain.  For purposes of this discussion, I’ll be starting at the printer and working my way backward.

The program that works most directly with the printer is the host software.  This is the program that actually directly controls your printer, and is the path by which G-code gets passed along  (I’ll get to that shortly).  There are a few 3D printer host programs out there, but the one that I have had the best luck with is Pronterface, a Python program written by kliment as part of the Printrun software package.

Pronterface main window

Pronterface main window (This is what Pronterface looks like when it’s not connected to the printer)

Please pardon the font size mismatch I have going on, that’s another issue.  This is the main window of Pronterface, and it’s actually rather intuitive.  The field in the upper left hand corner of the window allows the user to position the print nozzle anywhere in the build area, and the home buttons are used to (what else?) home the axes individually, or all together.  Nozzle and bed temperatures can also be set.  The mostly white area where I have a fan switch is actually a user-configurable area where all kinds of functions and macros can be assigned to custom buttons.  The top menus are also quite straightforward: Connect and disconnect he printer, load a file, start and pause a print, just what you’d expect.

In addition to the graphical interface pictured above, Pronterface also comes with a command-line version, for anyone so inclined.

Okay, through host software we are now able to communicate with the printer.  So just what are we going to say?

3D printers, like most other CNC-based devices, speaks a language called G-code.  G-code is a language that generates toolpaths, which tell the printer where to move the print carriage, and when and how much to run the extruder.

As you can imagine, trying to write out the entire print sequence by hand would be incredibly tedious.  An average print may include tens of thousands of tool moves, each of which must be explicitly specified.  Fortunately, there have been some very smart people on the case, so we now have slicing programs.  Slicing programs take a 3D mesh, generally contained in a .stl file (again, more on this shortly), and translate it into G-code.  As the name implies, a slicing program will take a 3D design, and reduce it to a series of layers (slices), which can be printed one on top of another.   The result is a long series of commands, which describe each and every motion that the printer needs to perform in order to create the printed part.

For a long time, the standard slicing program for RepRap printers was Skeinforge, and it is still in very widespread use.  I had a couple of problems with Skeinforge:  First, as I was building my printer, Skeinforge was very difficult to find.  The author’s website appeared to be down whenever I looked for it, and it appeared that the most recent version wasn’t all that recent.  When I was finally able to track it down, as part of a larger package called Sfact, I have to admit that I found it very non-intuitive, and quite difficult to navigate.  I may return to it in the future as my understanding of its functionality increases, but in the meantime, I found another project, called Slic3r.

Slic3r Main Window

Slic3r Main Window

Slic3r is a very capable and functional project with an easy to use interface and a lot of options.  Users can specify various profiles, so switching between different filament materials, or even different printers is a breeze.  Start by dragging your .stl file into the drop window, and you’re off and running.  You can add additional objects, scale, rotate or duplicate objects that are already there, so you can generate a full plate of parts if you so desire.  Once you’ve got your objects placed, hit the “Export G-code” button, and you’ve got a .gcode file to feed to your printer, either through Pronterface, or by placing it on an SD card and printing directly (in my experience, this is the preferred method).

Okay, so what is a .stl file?  Stl is a standard file type used in 3D CAD applications.  Where do we get .stl files?  They can be downloaded from sites like Thingiverse, or they can be created with programs like OpenSCAD or Blender, which are both open source CAD programs that run very well under Linux.  In the non-linux world, closed source applications like Solidworks can also generate .stl files.

At the moment, I am particularly fond of OpenSCAD.  It’s a lot different than other CAD programs I’ve used in the past, mainly because instead of using a mouse to drag shapes around a 3d field, it actually uses statements and commands to generate, place, translate and rotate objects.  It’s really writing a script to generate the thing you want.  This is actually quite a bit easier than it sounds.  I think back to experiences I’ve had with various visual CAD programs, and all the frustration I’ve felt around various things that seem like they should be simple.  Take, for example, a case where you might want to rotate a shape, say, 60 degrees in a particular axis, around one end of the shape.  For some reason, this always takes me a very long time, because I can’t get the mouse to grab the shape on the correct axis, or the program wants to rotate in some other weird way.  I know that it’s because the poor program is just doing what I tell it to do, and I just don’t know how to talk to it.

Anyway, I have actually become rather taken with OpenSCAD for designing the little plastic doo-dads that I have needed. I find that being able to explicitly tell the program what it is that I need gives a great amount of control and precision, and dramatically reduces my frustration and wasted time.

OpenSCAD acreenshot

OpenSCAD screenshot: The text box on the left is the script that created the rendered image on the right.

It’s also not nearly as difficult as it may initially seem.  While there is an explicit “Programming language”, it’s really more like a combination between a scripting language and just writing a description of what you want rendered.  It may seem daunting at first, but like any other task, once it’s broken down into its component parts, it’s doable.

So, to sum up, my software toolchain goes like this:

  1. Printrun (pronterface) talks to the printer.
  2. Slic3r generates the G-code
  3. OpenSCAD generates the .stl file.

I really like this arrangement, not only because it works really well, and all the component pieces get along so nicely, but also because it is 100% Free and Open Source Software (FOSS).  I absolutely love it when a community can provide its own solutions, and make them work so well.

I’d love to hear any additional thoughts!

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>