Here is a description of my recent experiences building a 3D printer and getting it up and running, for those that might be interested in this technology.
Includes my first print results which turned out to have surprisingly good accuracy (although needing some tweaking to get things “printable”). Good accuracy? I can not measure the variation from 90º on my printed parts, all axes combinations. Dimensional tolerances are on the order of 0.7 mm., all three axes. At least half of this can be attributed to material shrinkage during cooling. Improving surface quality will most likely improve tolerances significantly. Coming soon – tweaking my 3D printer for improved print quality.
Building A Makergear RepRap 3d Printer
We recently purchased a RepRap Prusa Mendel 3D printer kit for experimenting with the technology, from www.makergear.com. Total investment $1,115.05 (not including a few odds and ends I added from my stores of miscellaneous parts from various projects). Delivery took slightly over 2 months, which was anticipated based on disclaimers on the MakerGear website.
We ordered the metric unit with 1.75 mm hot-end kit. We selected MakerGear from the list at http://reprap.org/wiki/Prusa_Buyers_Guide, which offers alternative suppliers as well as some customer reviews, because they seemed to be highly regarded within the community-a reputation that appears well-deserved based on the active user’s group on Google.
And this is what it looked like when it arrived: The first frustration encountered was the fact that the kit was shipped without a parts list or documentation. An abbreviated parts list is provided on the MakerGear description page. This page also links to a Google Doc page with specific instructions for the MakerGear version of the machine, which, in turn, refers one back to the official Prusa Mendel Visual Instructions, available as a *.pdf download. Both the Google Doc page and the official Prusa Mendel documents are critical for building the machine. Start with the MakerGear instructions on the Google Doc page, read through them to identify the major differences between the standard model and the MakerGear model. Neither document alone provides adequate instructions for a first-time builder.
One issue I encountered is that the dimensions for setting the Y-axis rods in the Prusa Official documentation don’t work with the MakerGear version. The 39 mm offset from the left frame results in interference with the frame. This should be on the order of 60 mm, possibly a little more to get the print bed centered and maximize the print area. The separation between the Y-axis rods should be on the order of 120 mm rather than the 140 mm specified in the official documentation. The MakerGear laser-cut carriage (specifically, the center to center distance of the bushings) will dictate this dimension.
Also, mounting the extruder motor as illustrated significantly limits the available X-axis travel. I have reversed this mounting configuration.
This also requires setting X home at about 20 mm instead of the specified 10 mm. This gives me about 190 mm of useful build area in the X-direction. More tweaking of the Y-axis position should give me a full 200 mm as specified. In the illustration, one can see my solution to the issue with the infamous Molex connectors. These connectors are not for the amateur builder! Note also the fan mounted on the extruder head. It is secured with a small wood screw driven in to the end of the wooden insulator layer between the hot end and the X-axis carriage. I haven’t the slightest idea if this is correct or not. The fan came with the MakerGear kit with no information about what it was intended for. After playing around with the 1.75 mm PLA material and reading a variety of contributions to Google Groups, I figured out that one problem with the small-diameter PLA material is that the hot end gets too hot, resulting in jamming inside the extruder. Here’s a picture of what can happen:
If the filament gets too hot to high up in the extruder, the teeth of the drive gear bite too deeply into the plastic, and the plastic starts to kink as it is forced into the extruder barrel.
The fan gets power from the D9 connection on the RAMPS board, and is controlled by sending G-codes to the Arduino: turn on with M106 and off with M107. For some reason, after starting the fan and turning it off, one must power down and restart the firmware to get the fan going again. I do not yet know why this is. I have no idea if the fan is mounted as intended or if the set up I have devised actually solves the problem. Time will tell.
Because I prefer a right-handed axis configuration to the left-handed axis as built, I have reversed the Y-axis, which has resulted in limited Y-axis travel. I will probably revert to the original configuration (Y-axis home in back corner) to maximize the Y-axis range.
Note that the MakerGear instructions refer to this page for instructions on building the RAMPS electronic kit. These instructions apply to Version 1.2 of the electronics package, while the kit now ships with version 1.4, which includes a number of components already installed (surface mount). The instructions for building version 1.4 are found here. Note that this is likely to be a continuing saga-check which version you have when you purchase your equipment (I had to refer back to the MakerGear home page for the specifications, and there is no guarantee that the home page hasn’t been updated since the purchase!).
We also had to track down the appropriate instructions for the latest version of the hot end kit used on the extruder, found here, and the 8×8 Heater PCB (Red) with pre-soldered LEDs and resistors, instructions found here. A key piece of information not included in the instructions is that the heater PCB is likely warped, and will not mount flat to the bed. A piece of glass needs to be added to give a flat build surface. Here is my solution:
The clips holding the glass are home-made, from stuff I had lying around. There are more elegant solutions. Note also that I cut the glass to the recommended 200 by 200 mm size (to avoid the PCB mounting screws). It would have been better to cut it a bit larger in one direction-again, to maximize printable area.
It is not always easy identifying which set of instructions actually apply to the components shipped with the kit. This is understandable, in that this is a work in progress, and updating the documentation for every build modification would be an extensive project. However, including a packing list with appropriate links to the proper set of instructions for a particular configuration would really simplify things for the builder. Furthermore, not all of the instruction sets come in down-loadable formats, which can create an issue if one is building in a facility without easy access to the Internet (my Internet connection is in the office, while I am trying to build in the shop, where I don’t have Internet).
The next frustration encountered is that the ABS material from which the printed parts are fabricated apparently are very weak in shear/tension, although they seem very capable of handling the compressive stresses encountered (at least during the build phase). We especially ran in to problems with the bar clams on the x-axis motor mount and the x-axis idler mount-when tightened too vigorously, we see indications of tensile failure.
With the X axis motor and idler ends, we find that the captured nuts in used to locate the ends on the smooth rails will pull through if the screws are over-tightened (see the next image). This feature could most likely be overcome by thickening the base section on these two components, without major impact on the overall system design. My quick and dirty solution was to build up the area around the damage with some two-part epoxy I happened to have lying around.
My printer came with the ATX power supply. While the instructions on the Google Docs page at MakerGear are adequate for getting this connected, I went a little further:
Note that the switch is connected where the instructions call for either a jumper or a switch- I prefer the switch for emergency shut-downs. Also, I connected the two 12 V supplies for the RAMPS board to two of the yellow wires (+12 V DC) on the same connection, and used two of the black wires for the ground side. Not having a decent box handy, and since the Johnny Mathis tape has long degraded beyond any useful function, I fit the whole thing in an old cassette case, which fits nicely under the Arduino mounting platform, secured with a couple of wire ties. The switch is quite handy in this position. Fortunately, I haven’t had the emergency situation yet…
It took us about six days to finished construction (working in our spare time), and getting communications set up between our computer and the Prusa Mendel. I probably spent a good deal more time surfing the Internet looking for the right instruction sets and software packages than actually building the system.
There are a number of elements to the software chain, referred to as the “Tool Chain”, that must be put together to get things running, described nicely here. Here is a nice picture from the Wiki:
There are many different options for software for the Prusa Mendel, detailed in part here: http://reprap.org/wiki/Useful_Software_Packages
This can get a bit confusing, because everyone has their own idea about the “best” solution. One of the issues that must be addressed first is what operating system one is using for controlling the machine. In keeping with the Open Source spirit, I prefer the Linux operating system (specifically, Ubuntu 10.04 LTS 64 bit-experiences may vary with some of the newer approaches to the graphics desktop being bandied about, like Unity or Gnome 3), but others apparently are working quite nicely with Windows and MAC OS. I won’t pretend to be a guru on this subject. I will share my experiences, and let the reader decide the direction to go.
We will leave the issue of which CAD package is preferred to the reader. The important issue is the ability to get the design into *.stl format. I personally prefer BrlCAD because it uses a CSG (Constructive Solid Geometry) approach, which means one starts with primitive solid shapes and adds and subtracts other primitive shapes to arrive at the final object. OpenSCAD is also a CSG type system, but I have trouble figuring out where I am in model space, which makes it difficult to position objects. I have the same problem with FreeCAD. Salome is a nice package as well. My preference for BrlCAD or Salome probably is related to the fact that I am more familiar with these packages. Also, were I more interested in artistic subjects, I would probably prefer Blender, but I find Blender a real trial to use for engineering-type objects (although others have done some pretty impressive engineering illustration with Blender). There are, of course, any number of commercial packages that would serve just as well, were one willing to lay out the outrageous cost of a seat.
Once we have the design in *.stl format, we need to generate the g-code that will be used to pass instructions to the printer (the same thing that is used for CNC work). The easiest approach would seem to be to go with the RepRap basic solution, referred to as the “Host Software” (available here), which also integrates the communications software required to talk to the printer. I immediately had problems with this package, in that it is Java based, and Java has lost it’s “cross-platform” advantage ever since Oracle bought Sun-and I am not convinced Oracle is going to leave Java as an Open Source solution. Personal preferences here, compounded by the fact that the RepRap software did not build on the first go on my system, and I have no real motivation to pursue it.
Slicer Utility/G-code Generator
We narrowed our choices for the Slicer/G-code generator to either Skeinforge (with SFACT) or Slic3r, with the Skeinforge package apparently being the older standard, and Slic3r being the new kid on the block. Skeinforge has a built-in simulator, so that one can examine the output before committing to a print, but, after playing around with Skeinforge and SFACT for some time without getting a decent print, I gave Slic3r a try, and got a decent (not perfect) print on the first try. One of the issues I have with both packages is that there is some ambiguity in the terminology, and this can be a bit confusing to the newcomer.
The website has some very good documentation for using this program, and some handy tutorials.
Printer Communication Program
We settled on PrintRun, and find it quite intuitive and easy to use. It found the correct communications port and baud rate with no prompting from us. PrintRun consists of printcore, pronsole and pronterface, and a small collection of helpful scripts, and is usually integrated with Skeinforge (apparently from the same author). Pronterface consists of a very clean and intuitive GUI from which Skeinforge can be called.
For the Linux aficionados in the crowd, it is rather easy to set both these programs up to start from the “Applications” menu. Begin by selecting “System/Preferences/Main Menu”, and one gets something like the following:
I set up a new “Menu Item” for my 3D printing applications. Select “New Menu” and you get a dialog that asks for a name for the new menu item. Once this is done, in the “Main Menu” window, select the new Menu you just created by selecting it in the left column. Now select “New Item” and you get the following dialog:
For “Type”, select “Application in Terminal”. Enter whatever name you want to call the application. For the “Command”, enter, for example:
“ python [PATH TO PRINTRUN DIRECTORY]/Printrun/pronterface.py”
Change the icon if you so desire-I used a *.png image of the printer I built for the PrintRun menu. For Slic3r, I copied the logo from their website to use as a launcher icon.
Another option is to integrate Slic3r into PrintRun, a procedure described here. Essentially, one replaces the slicer command in the “Settings/Options” menu of PrintRun.
Put this into slicecommand:
[$PATH TO Slic3r EXECUTABLE]/slic3r $s –load config.ini –output $o And this into sliceoptscommand: [$PATH TO Slic3r EXECUTABLE]/slic3r –load config.ini –ignore-nonexistent-config
Replace “config.ini” with the full path of your config file.
Just makes life a little easier…
We are using RepRap Sprinter, which was pre-loaded on the Arduino board that came with our kit. Available here: https://github.com/kliment/Sprinter
There are guides to modifying, compiling and loading the firmware onto the Arduino, especially of interest in some of the calibration steps to follow, but we are going to assume that MakerGear has already done some of this for us for the time being. The Arduino package is available in a *.deb package for our system, but there does seem to be some issue over which version of the Arduino software to use.
Once the software is installed and working, one needs to do a bit of checking to make sure everything works properly. A good guide for the checkout is:
Once everything is up and running and the computer is talking nicely to the printer, there are some calibration steps that should be implemented. A good guide can be found here, or a better one here. My summary and comments following are based on working through this guide (and a few other sources, where the guide is inadequate in my opinion).
There is a major issue with leveling the bed, in that the Y-axis carriage is a bit too flexible-one can cause the bed to become “cocked” and it will no longer move smoothly. One needs to continually check that the X-axis carriage is perfectly parallel to the Y-axis rails as one proceeds. There are a number of different approaches to bed leveling on the Internet. I followed (mostly) the one recommended in the RepRap Wiki referenced above for the easiest approach. One issue is the proper mounting screw arrangement-again, there are as many different approaches as there are builders. The system I found that works well is shown here:
Note the double nuts on the bottom-this locks the bottom nuts. I found that leaving these nuts loose prevents warping the carriage. If the nuts are left loose, they vibrate off during operations. It can be rather unsettling when parts start falling off during a print run. Others have other ideas about the best approach to bed leveling. Use what works.
Bed Surface Preparation
I use bare glass for now, working with PLA. Glass must be clean. Removing the printed items from the glass is relatively easy once the heated print bed has cooled down. I use a square Xacto blade to slide under one corner of the object. This seems to work well for now, with PLA. Others seem to think that the glass should be covered with tape. I rather like the glassy finish imparted to the printed object when printing directly on glass.
Don’t omit this step. Not mentioned in the instructions is that if the motor ticks like a clock, the Pololu stepper driver is likely overheating and going into thermal protection, suggesting too much current. Turn the potentiometer counter clockwise slightly (1/8 turn) to lower the current. I also have an issue with my dual Z-axis motors not being synchronized, meaning the X-axis does not remain parallel to the print bed. I suspect this is due to too low a current setting, and am in the process of tweaking this. Meanwhile, I check that the X-axis carriage rails are parallel to the print bed before each print, and adjust by turning one of the Z drive screws as needed.
Calibrating the extruder involves accurately marking the filament and manually extruding some given amount (some authorities suggest 20 mm, some 100 mm. The longer length would theoretically be more accurate, but is difficult to measure accurately. I used 20 mm). PrintRun makes this process relatively easy. Turn on the heater, let it come up to temperature, set the length of extrusion in the box in the lower left corner of the GUI, and click on the “Extrude” button. Fortunately, my extruder was right on the money. Otherwise, one must modify the firmware header file and recompile and reload the firmware-something I am not quite ready to attempt at this point. It would be really handy were someone to redo the firmware such that this parameter could be adjusted from the computer.
According to Richrap, “Layer height is very important and needs to be compatible with the Nozzle hole size. For a standard 0.5mm nozzle I always use 0.3mm layer height, you should avoid going any bigger than 0.4mm and as low as you dare, but much below 0.1 mm you will struggle to see the benefit…” Richrap also provides some nice illustrations of the effect of varying the layer height.
The procedure described on the RepRap Calibration page referenced above has given me a bit of a headache. After playing around with the procedure, working with the 0.5 mm thin wall *.stl recommended for this test, I came up with a best guess of 0.2 mm layer height- I was never quite happy with the final prints I was getting of the =.5 mm thin wall rectangle (voids, layers not always sticking, etc.). I decided to print the traditional minicup based on a tutorial I can no longer locate, which included Slic3r settings. When I printed the “minicup”, I used the 0.3 mm layer height (and other settings) specified in the Slic3r tutorial, and came up with a decent print. Interestingly, some of the minicup *.stl files available for download have the cup oriented to print on its side, which intrigued me (being interested in overhangs and bridging open spaces). I got a surprisingly good (although not “presentable”) print in both the traditional orientation and the laying-down orientation (obviously, the correct orientation would be preferred, but an interesting experiment). Finally, I came up with my own “calibration” object, the “Caged Ball”. My first attempt demonstrated that aspect ratio on tall thin columns is critical. The second attempt, with adjusted dimensions, came out much nicer. We still have not determined the appropriate layer height (all of these objects, except the thin-walled rectangle) were printed with 0.3 mm layer height. Our latest trial of the Caged Ball was printed with 0.2 mm layer height, with some improvement to the surface finish, but we still have a lot of tweaking to do to get prints of the quality we are looking for. Here are some things we have printed:
The rectangular print is the layer height calibration object. The cup on the left was printed in the horizontal position, a good test of bridging open areas. The cup on the right was printed in the vertical orientation, with much better dimensional control and better quality surface. To the far right is the first design for the Caged Ball-obviously, the aspect ratio for the vertical columns was inappropriate for the process. The bottom version of the Caged Ball printed with a layer height of 0.3 mm is how it came off the printer-note a lot of stringing, and the surface is considerably rougher than desired. We re-printed the Caged Ball with 0.2 mm layer height:
Still a lot of strings, but a bit of an improvement on surface finish. Still a long way to go…
An interesting event- this is what happens when one experiences a minor earthquake during a print: