Unicorn Tutorial 01

<<< Unicorn Tutorials List || Tutorial 01: Vector-based Drawing Walkthrough || Tutorial 2: Basic Hatches >>>


flickr:5071198078

MakerBot Unicorn Tutorial 01 - Vector-based Drawing Walkthrough

In this first tutorial I will walk you through the entire process of creating the "MakerBot Exploded Diagram — for MakerBot Unicorn" that I released at Thingiverse.com.

Along the way I will discuss the applications and scripts I used to pass from stage to stage (with links to where you can get software or help with installing software), so if you follow through this tutorial you should have everything you need to create MakerBot Unicorn sketchs from vector-based drawings.

A Pen Plotter

Decades have elapsed since the inkjet, laser, and thermal technologies defeated their competitors to become the reigning kings of at-need 2D printing in the world. In fact, when most people talk about "printing" (well, not us) they are mainly referring to these methods. So "plotters" have been relegated to a more artisan/speciality-use existence along with other byways of print technology history: optical/film, polymer plate, set-type, woodblock, silkscreen, and dotmatrix technologies.

But despite being passed a pink slip from the professional world of architecture, computer-visualization, illustration, and engineering1, plotters resurface all of the time, resurrected and re-purposed by artists, DIY enthusiasts, and tech-heads for much the same reason that the arcade game Asteroids with its unique analog vector-driven laser display continues to attract new fans: a unique "look" that cannot be accomplished any other way.

I had been a fan of pen plotter projects for a while thanks to radical repurposings such as Draftmasters and Hektor the Spray Painting Robot and loads of projects for DIY pen plotters such as The Make Drawbot. The MakerBot Unicorn stands out among its peers not only because it is a swap-in pen plotter toolhead for a beefy 3D printing robot (already very cool), but also because of what it offers the designer:

  • It is very fast.
  • Has great positional accuracy within the page (and from print-to-print) thanks to the engineering challenges solved for 3D printing.
  • You can print on about any surface you can fit on (or tape to the top of) a build platform, including copper plates, scratchboard, and all forms of paper.
  • You can use a range of marking implements, including diamond scribes, rotating blades, and watercolor pencils.
  • Tiny servo allows for lighting-fast pen lifts. (Allowing for stippling.)
  • Pen is "gravity-driven" rather than "motor-driven" down to the marking surface, so the marking process can handle slight tilts, bumpy surfaces, etc., quite easily.

But most importantly, the Unicorn has a native illustrator's "hand" (well, "horn") that leads to a less "machine-flavored" result than I anticipated from a plotter.

Getting You Equipped For Printing on the MakerBot Unicorn

I'm not going to pamper you — to push your MakerBot Unicorn to the limit, you are going to need to install some software. But the good news is that everything you really need is free / open source, and for the most part crossplatform. Even better, many of these tools are essential tools for other disciplines (and current cool projects like Eggbot) so please Google-forth to extend what I cover here to make sure you suit out your particular OS with the tools you need in the configuration you prefer.

I figured that simply presenting you with a list of what you need to install and what processes are necessary to move from design to print would feel more overwhelming than the process actually is, so instead I am opting to present a walkthrough for the process I use, listing the applications I have settled upon within the contexts I use them. If you find alternative software to accomplish these tasks, don't hesitate to share them here or elsewhere.

I tested many many packages for a month and found this process to consistently work, and that is the primary criteria for me including them here. But as with anything in the world of computer visualization and graphics, there are a thousand thousand projects happening all over the world approaching each of these process from a different angle.

MakerBot Exploded Diagram Walkthrough

I will be walking you through a printing project I did over a Saturday afternoon in early October. I printed:

flickr:5071198078

from the following illustration:

makerbot_exploded_bw_thumb_large.jpg (original here)

The original drawing was created for MakerBot Industries by James Provost, and shows all of the elements of the MakerBot Cupcake CNC machine "exploded" from their assembled position so that you can see how the pieces fit together and function. I didn't have an original vector illustration file, so I took the at-hand bitmap image and traced it (more in second tutorial on this process) in Inkscape to extract the SVG file I used for this entire process.

It was easy to trace this source because the art is restricted to black or white values, no halftones. The slight distortions introduced by the process (slightly deforming the text) worked well in the final drawings, so I held off pressing for vector illustration (if there is one).

I released the assets used for this project at Thingiverse here so please grab the original files so that you can duplicate this process yourself.

flickr:5070383781

A chart of the process I followed.

Inkscape (inkscape.org)

flickr:5077552097

There are a vast variety of vector graphics applications out there in the world, but I am using the SVG editor Inkscape not only because it is Open Source and crossplatform, but also because it contains other tools I use to create successful Unicorn drawings.

Specifically, the excellent Potrace tracer, Live Path Effects that helps me create crosshatch effects and washes (more of this process in fourth tutorial), and third-party contributed extensions and plugins (make sure to follow the plugins the Eggbot team is writing here). In fact, I've been looking into taking leads from the "Scribbles.py" Python script (see later stages within this tutorial) to create an Inkscape plugin to generate MakerBot g-code as an export process. (I could use some help.)

If you prefer doing the initial vector design work in another program like Adobe Illustrator, you still might want to pass your work through Inkscape when you are finished for a few of these tools by exporting a standard SVG file for import into Inkscape.2

The 75mm by 75mm Inkscape SVG template file I started with is here (download).
The Inkscape SVG illustration I finished with is here (download).

Exporting from Inkscape as EPS file

Speaking of the Scribbles.py script, I'm going to have to jump ahead in the process briefly to mention a current limitation of Inkscape.

Scribbles currently requires that old venerable DXF file format for input, and the manner Inkscape handles DXF output (it also has DXF importing functionality, btw) is not only a bit of a mess in general, there are issues depending on which operation system you are using for Inkscape.

At the time I wrote this tutorial, there are serious complications for getting a DXF file out of Inkscape for the Mac that have to do with which versions of certain libraries in Darwin are blessed by the OS X operation system. There are ways around the lxml library issues, but…well…let's just skip all of that for now and pretend we aren't compiling everything by hand and tweaking OS kernels.

I had the luxury to jump from Mac to PC when needed, so I did experiment with actual DXF output from Inkscape3 — but I noticed that complicated drawings, especially traces from photographs, created huge (and highly inefficient) DXF files leading to slow, uglier plots that tended to stipple where lines would have worked better.

After trying well nigh everything to solve this issue, I ended up settling for a work around that proved to be a blessing in disguise. I moved the DXF conversion out of Inkscape and into pstoedit, and pstoedit generates pleasing, better managed DXF files to feed to Scribbles.py. At this point, I consider pstoedit the best route on all operating systems.

I took my Inkscape document and exported the EPS file here (download).

pstoedit (pstoedit)

flickr:5077559799

I suppose I should apologize for encouraging you to install pstoedit — this process can be a bit difficult. Thankfully, this tool, and its cousin tools Ghostscript, GSView, and GraphicsMagick, are essential go-to swiss army knives for image manipulation for many many projects out there, so Google is your friend for this one.

The "cousins" you need as well:

One trick I recommend is to put these apps in the path listing for your command line shell. The PC binaries for these projects offer this option as a part of the install, I believe, but you might want to look up how to get the pertinent directories in your $path on a *nix solution such as OS X.

Here is the command I passed to pstoedit:

$ pstoedit -f dxf:-mm makerbot_exploded_bw.eps makerbot_exploded_bw.dxf
  • "-f" — format conversion
  • dxf:-mm — convert to dxf establishing "millimeters" as units of measure

You can also experiment with the splines version of DXF format (listed in the pstoedit manual). There are many tools that can call pstoedit without the command line, but as my needs were simple I stuck with the command line.

QCAD (http://www.qcad.org/)

flickr:5077552151

One of the issues I faced heading for the Scribbles.py script is that I need to prepare my DXF file for the specific conditions that Scribbles expects. I always use QCAD for this stage, even though it is indeed a commercial program. However, there is a Community Edition4 and a demo of the Professional Edition that can be used for many many hours worth of ten-minute spurts.5 So even if you don't buy this inexpensive, useful tool, you can still check placement, clean up art, and use the use the "explode" function with the demo.

My QCAD tasks: getting design elements into the non-negative quadrants of a millimeter based DXF document, checking to make sure the design fits on the build surface: 100mm x 100mm is the absolute maximum6. Typically (thanks to the handiness of 75mm x 75mm sticky notes) I keep my design within 74mm x 74mm.

If my drawing is in the wrong location, I use the following trick: I use Select>"Select All" and then Edit>Paste the elements back into the document again. QCAD requests a reference point for the paste action — which will be where the center of the drawing will fall — so I divide my outward limit of x and y axis in half and type those numbers in the little command line slot below the document window: 37.5, 37.5 (for 75mm x 75mm).

You can do quite a bit of editing right here in QCAD (if you are quick!). I always save a pre-exploded copy of my DXFs in QCAD to use as a state for further manipulation if I see anything strange in my final print. Also, I sometimes duplicate my QCAD DXF file and create separate passes for each color or writing implement I plan to use. (Example: deleting all of the outlines and printing just tone crosshatch in a gray or brown instead of black.)

After checking placement, size, and design, I take advantage of QCAD's handy "explode" tool. First Select>"Select All", and then, using the left-side tool dock: hit EDIT and then the exploding firecracker). Basically, this tool breaks up all of the nodes of your polylines and curves and replaces each part with a tiny, simple line or arc. Tiny lines that are much easier for Scribbles to process than crazy polylines with splines contorted into negative values by a tracing program to match the exact shape needed, for example. Scribbles.py doesn't like that stuff and tends to fail on many DXFs that aren't exploded.

There are times — say when you create a drawing right in QCAD — that exploding the results might not be necessary, but until Scribbles.py is updated to handle all elements of processing DXF files, AND there are better solutions for passing DXF blocks properly through the whole process, I'd suggest you explode nontrace vector-source drawings as well.

Here (download) is the dxf as it came into QCAD before cleanup and "exploding." I always "save as" and add "_xpld" to dxf files that I have processed to be ready for Scribbles. Exploding is a one-way process which is much more difficult to edit/manipulate than a pre-exploded illustration. Plus, saves me running the wrong DXF file through scribbles.

Python 2 (http://www.python.org/)

Not only do I need Python for Scribbles.py, I also need the Python Imaging Library for Scribbles and Plotterize. I originally installed Python 2.6 and the proper PIL version to match, but have since added a Python 2.7 install without obvious ill-effects.

There are ways to run Python on any operating system — but please be mindful that you need to be familiar with how to access a command line to run the Scribbles.py script. So if you have a windows system, it might be worth it for you to investigate Cygwin to get more native *nix-ish interface.

By the way, PIL is an extremely powerful tool that can be exploited even further for the Unicorn by folks willing to investigate. There are already so many software projects out there using these tools that you might be able to generate really interesting results without building something from the ground up.

Scribbles (http://wiki.makerbot.com/scribbles)

flickr:5078147354

I must admit I have an extreme prejudice for sticking to the vector-based route using the Scribbles script instead of the bitmap source Plotterize script. For me, the behavior of Scribbles (moving the pen tool over the page as lines, arcs, and stipples) is more interesting/satisfying than what Plotterize does (which more closely resembles a dotmatrix or black-and-white inkjet, with the printhead traveling back and forth across the page depositing ink where it is needed — leaving a more mechanical-looking striation to the dark patches where the horizontal marks rub up against each other). Most of the advanced techniques I will be sharing with you require a vector-based route, so please follow me along the Scribbles route for now.

Scribbles is a handy Python script based on lunchlines.py, the script written to find the tool path for printing with the Frostruder. The code is available on Github here and the code can be hacked to suit your specific needs.

I highly recommend that you replace the default "context.py" sub-script with the one I released and discussed here, as my revision starts with a registration test (marks a tiny dot in the lower left hand corner of the platform) to tell you if your pen is at the right height and x/y placement, and offers a machine halt with the pen lifted away from the page so that you can remove your work without marking it against the exposed pen. (Also, my method starts and ends the pen in the same position, making it easier to swap marking implements and re-test registration without messing up your work.)

Here are the g-code lines resulting from my updated context.py after scribbles.

Preprinting instructions:

(---------------------------------------------------------------)
(---------------------------------------------------------------)
(Start of sheet header)
(Print-to-Pad Scribbled version of makerbot_exploded_bw_xpld.dxf @ 2000.00)
( scribbles.py makerbot_exploded_bw_xpld.dxf )
G21 (metric ftw)
G90 (absolute mode)
G92 X0 Y0 Z0 (zero all axes)
G92 Z0.00 F150.00 (go up to printing level)
M300 S40 (pen down)
G4 P120 (wait 120ms)
M300 S50 (pen up)
G4 P120 (wait 120ms)
M18 (disengage drives)
M01 (Was registration test successful?)
(while drives are disengaged, adjustments can be made to position)
M17 (engage drives if YES, and continue)
(End of sheet header)

Post-print instructions:

(Start of sheet footer.)
M300 S50 (pen up)
G4 P120 (wait 120ms)
G0 X0 Y0 Z15 F3500.00 (go to position for retrieving platform -- increase Z to Z25 or similar if you have trouble avoiding tool)
G4 P300 (wait 300ms)
M01 (Have you retrieved the print?)
(machine halts until 'okay')
G4 P120 (if yes continue, pause 120ms before ... )
G0 Z0 F3500.00 (return to start position of current sheet)
G4 P300 (wait 300ms)
M18 (disengage drives)
(End of sheet footer)

M01 (Printing on the next sheet?)
(yes, if dropping the default .1 mm to next sheet; no, if you will print again on same sheet)
G0 Z-0.10 F3500.00 (drop 0.1mm to next sheet)

(Paste in further sheets below)
(---------------------------------------------------------------)
(---------------------------------------------------------------)

Note that this drawing is "stackable." I could take another drawing from Scribbles with this script, and I will have the machine halt (M01) to let me retrieve the page, returns to the proper pre-drawing position, and then makes a .1mm adjustment to compensate for the removed page.

There are two tricky issues with Scribbles:

  1. It requires you to have Python 2 installed, and accessible via a command line interface. (But you have already accomplished this step, right?)
  2. It asks for a DXF file, a specific vector-based format which has been implemented in slightly different ways by the range of tools that offer it.

Currently, the best way to use Scribbles.py is to move your DXF file into the main Scribbles directory. Otherwise, you need to include the precise path to your source file.

Here is the command I used to process my image through Scribbles.py:

$ python scribbles.py makerbot_exploded_bw_xpld.dxf>makerbot_exploded_bw_xpld.gcode

The resulting gcode from this process is here (download), and here (download) is the "exploded" DXF file I submitted to scribbles.py.

ReplicatorG.app (http://replicat.org/)

flickr:5078147414

So now we reach the software that communicates with your bot: ReplicatorG.

You have to have ReplicatorG version 19 or later in order to run the Unicorn. This version adds recognition for the machine command M300 for the little servo connected to the D9 port on the extruder board, and the shift between 40º and 50º determines the lift or drop of the pen.

ReplicatorG (and thus your MakerBot) runs on G-code. G-code a somewhat human-readable list of positioning and machine tool commands that your bot commits, line by line.

Here are some useful commands to have at hand to insert into the beginning or end of your g-code to help with release the drives so you can make placement adjustments or halt the drawing process, etc. You can throw the M01 or M00 commands plus a Z-axis move into random parts of your code as "debug" halts to locate where you are having issues with your gcode.

M300 S50 (pen up - this is a comment by the way)
M300 S40 (pen down)
M18 (disengage stepper motor drives)
M17 (engage stepper motor drives)
M01 (the printing halts while RepG asks you whatever is in these comment parentheses as a question waiting for a "yes" to continue or a "no" to stop)
M00 (the printing halts while RepG alerts you to this comment and waits for "okay" to continue)

So G-code is also human-writable, but the process of writing the actual plotting can be so laborious that almost no one does this manually. That is where Perl, Python, and Java tools come in for transforming one array of data (say, points to hit in a drawing) into a list of g-code commands the MakerBot can follow.

While you are welcome to roll your own tools, chances are that to get the g-code you'll need for the Unicorn, you will want to pass your work through Scribbles or Plotterize.

Here (download) is the g-code document that I used for this project, generated from Scribbles.py.

Printing the Design

Before starting the print, I adjust the build platform position (with stepper drives disengaged via the jog controls window) to put the pen tip above the bottom left corner of the page and then zero x,y,z axes.

With my gcode file loaded into RepG, I activate the Build option and wait for the registration mark test in my custom gcode "pre-print" block. Essentially, this makes sure that I know if the height of the z-axis and the x/y placement are optimal without leaving the pen-tip smashed into the page. If I answer "no" to the registration mark dialog box, the print stops there with the drives disengaged and the pen in its lifted position. I can make adjustments and re-run the script to get the registration test a second time.

Note, if I'm breaking up a drawing into a series of prints (say, different pens) on the same page, I can answer no to the "Printing on the next sheet?" question so that there is no page-removal adjustment. Also, if I am stacking all of the passes of a multi-pass document in the same g-code document i can just cut off that "Printing on the next sheet?" section.

Here is a video documenting the final print:

Unless otherwise stated, the content of this page is licensed under GNU Free Documentation License.