Wednesday, March 31, 2010


Hydra: Cartesian Robot Assembly Completed

So after about 7 hours straight working in the shop on Monday, the assembly for the cartesian, 3-axis robot is completed. We ended up working through lunch so you might see some tired people in the pictures. It was pretty exciting to see the machine start to take shape after all the hard work we had put in making the aluminum parts. Here are some pictures from the build

Most of the parts laid out at the beginning of the morning

Y-axis assembly completed with the X-axis carriage in place. The X-carriage has mounting holes for 4 different Z-axis assemblies. 2 on front and 2 on back.

X, Y, and Z axes completed and assembled. We have a 2nd Z-axis assembly that wasn't in this picture too

Another angle showing the Z-axis and X-axis details. The screws at the bottom of the Z-axis weren't tightened because we have a slight alignment problem we need to fix first. Also, the writing on the side of the Y-axis uprights and several of the other pieces will be faced off before our final presentation to make everything look a little cleaner.

We were able to test out the "feel" of the movement along each axis and it was surprisingly smooth. I was pretty impressed considering we used some pretty cheap plastic sleeve bearings. That said, I am sure using skate bearings or something of that nature would have been much smoother, but our initial calculations said we might have problems with the radial forces during heavy machining. We still have 1 or 2 holes that need to be fixed to make everything fit perfectly, but for the most part, the assembly of the 3-axis robot is completed and we can move on to the subassemblies such as the extruder, heated build table, and spindle mount. Pretty exciting day!

Labels: , , ,

Tuesday, March 30, 2010


selective laser sintering printer: part 4 (putting it all together)

hi folks,

a couple rainy days and the dorky need i have to make this thing work mean, another SLS post! :)

(click on the thumbnails for larger pictures)

i designed a new enclosure for the SLS printer that would let the build chamber, z-axis table (inside the chamber), pivotable mirror, laser, powder feed system, and electronics all fit together. i've been designing the system with the hopes that it would be both easily created by others and inexpensive, and so currently the whole system is essentially just a whole bunch of laser cut acrylic parts, a bunch of inexpensive steppers, and a trip to the hardware store for some bolts and ABS pipe. (i have some thoughts to design a laser-cuttable gimble system for the pivotable mirror, but that's a bit in the future).

the pivotable mirror just rests on top of the sides, which are set at 45° and directly above the build chamber.

one of the things i've been really trying to be creative with is the powder feed mechanism. traditionally, a commercial SLS printer will have two chambers with indexing z-axis tables, and a roller. one chamber will start with a thin layer of powder (the build chamber), and the other will start with a large amount of powder (the material supply chamber). after each layer, the build chamber will index down a little, the supply chamber will index up a little, and a roller will roll new material from the supply chamber to the build chamber.

the key elements here are supplying the build chamber with a thin, repeatable layer of powder, and having a lot of supply powder. i wanted to try and avoid having *two* chambers with indexing tables, as well as a roller (it seems like a lot of extra space and mechanism, if you can design something functionally equivalent). the system i came up with is as follows: a thin piece of acrylic rests on the platform above the build chamber, and it can slide back and forth overtop of the build chamber using a rack and pinion system. the sliding sheet is sandwiched in so that it can only ever move back and forth over the build chamber (not side to side, or up or down), such that if a layer of powder were put ontop of the build chamber, it would wipe off any that exceeded the height of the chamber itself. (this whole sliding thing is essentially the roller, but more of a squeegee)

in that sliding piece is also a long, thin slot. ontop of this slot one would put a little hopper full of powder. when the table indexes down, the slide will slowly slide over the chamber, the powder will fall down into the chamber, and ideally the slide will wipe away any that exceeds the height of the chamber. that's the idea, anyway. :)

the electronics are mounted under everything, with easy access. i had a few spare boards left over from a batch sent to goldphoenix that used a dsPIC33FJ256MC710 on them, so I repurposed them (since they have a breakout header for about 30 pins!), and plugged it into the little 4-axis stepper controller board from the previous post.

the sides were designed with lots of slots and holes, so that little extra bits could easily be added or removed or modified later without drilling anything. it's really handy! :)

here is the (almost) whole system, with a red laser pointer being used as a test.

(the stuff in the build chamber is actually the foam top of the table -- there isn't any powder yet. i hope the foam table will act as a bit of a seal, too, and prevent much powder from escaping below).

the powder hopper -- it's not very big, but the total chamber build volume isn't too big, either. i just glued this together tonight, but it's not glued onto the slide just yet.

after over-voltaging a bunch of DVD laser diodes, and taking apart a bunch of laser pointers for their collimating lenses, i've decided that it would just be a lot easier and more precise to find a pre-made laser module (and, so, i've been looking around ebay for one for the last week or so). i'm thinking 250mw minimum (like the DVD laser burner), but there are bunches of inexpensive 808nm 1000mw diodes on ebay. since these are near infrared, there's a much better chance that they'd be able to work on materials other than pure black plastic, and the additional power means a bunch of good things, including that each layer could be sintered quicker. (unfortunately it also means that one's eye could be damaged even that much quicker -- and the infrared lasers border on what is visible to the eye, so it's a bit more dangerous than a visible diode).

any thoughts for a complete (inexpensive) laser module with a collimating (or focusing, or both) lens would be fantastic, and as always i'm happy to hear comments/questions, or thoughts on where to find very fine ABS, nylon, or other thermoplastic powder.

thanks for reading!

[part 1] [part 2] [part 3] []

Monday, March 22, 2010


New Arduino Mega Shield for CNC interface!

So I have been working in Eagle for about 2 months now and have made a few designs here and there to support the Hydra-MMM project. I just made one in the past week that I thought might be useful to the community. The design is a snap on shield for the Arduino Mega that allows the Arduino to interface with diy CNC machines that are built upon a parallel port (DB25) interface. These machines use a printer parallel port along with computer software (Mach 3, EMC, etc) to control the movement of the axes. The processing is done on the computer CPU instead of being done on an Arduino or something of that nature. Here is a few pictures of the actual eagle PCB

2 sided PCB board layout with the big 25 pin parallel port interface in the middle

Schematic of the parallel port shield

The reason I wanted to make a parallel port interface is because we are hoping to use our machine for both CNC work and rapid prototyping. By using a common parallel port interface we can have a single electronics control box (ECB) that has all the stepper motor drivers, extruder controllers, spindle speed controllers, and everything of that nature inside. I'll have more information on our ECB over the next few weeks, but for now a screenshot of the setup is below. Note that most of the electronics have not been modeled in the CAD program yet, so they are not shown, but their placement should be obvious.

Electronics Control Box (ECB) with power supply, Arduino Mega, stepper motor outputs and endstop/encoder inputs

The ECB can than be connected by a parallel port cable to either a computer with a 25 pin printer port or to the Arduino Mega with the new parallel port shield. The Arduino Mega will be running the Hydra-MMM firmware, but any reprap firmware variation would work. The main concept is that once connected via the parallel port to the ECB, the Arduino would have access to all the stepper motor drivers and endstop sensors that it needs to print! The parallel port pinout is as follow:

1 Estop
2 Xstep
3 Xdir
4 Ystep
5 Ydir
6 Zstep
7 Zdir
8 Astep
9 Adir
10 Xlimit
11 Ylimit
12 Zlimit
13 Alimit
14 Spindle/extruder on
15 Aux Input
16 Spindle/extruder speed control (pwm)
17 Coolant/Fan on
18-25 Ground

Some readers out there may notice the fact that there are no temperature sensors on the parallel port pinout. There are 2 AD595 thermocouple IC circuits built into the shield for measuring the temperature of the nozzle heater and also an optional heated build table. The main reason I did this is that I noticed that the analog wires for temperature measurements pickup a lot of noise if you run them over long distances. By having them mounted directly on the shield that attaches to the Arduino, that noise is minimized. I have tested a prototype pcb using this technique and the improvement in noise suppression over the same breadboarded circuit is amazing! The shield also has an onboard LM7805 5V regulator so that it can be run off the same power supply you are using to power the stepper motors (in our case 30V). This may also help reduce noise as the regulated 5V output is filtered and likely suppresses some noise in the process.

Another reason people may want this shield is that diy CNC machines have been around for much longer than the Reprap project. Many people already have the electronics for a cnc machine that is based around a parallel port interface, however, they are now wanting to try out rapid prototyping using the Reprap Arduino firmware. This shield would let them do that pretty easily.

The eagle files for the shield can be downloaded here:

As I said, I have only been using Eagle for about 2 months so I would love some feedback on the design. Let me know what you think!

Labels: , , , , , ,

Sunday, March 21, 2010



i really need to find a better way of extruding plastic.

our first extruder worked fantastically for a long while, until the heater element got a little too hot and broke. we must have built 5 or 6 different extruder heads in the past month or two with parts from makerbot, and it just hasn't gone well. this is the latest, and i thought we really had it -- until i looked over, and noticed a two inch long blob of plastic steadily coming out from between a swollen barrier, and the heater barrel. a first for me. and, on only the second print.

please, someone, come up with a better method... maybe a ceramic barrier, or something? these PTFE barriers, brass barrels, and wait times for shipping are starting to get expensive after the n_th iteration. o.O;;


Open Source Circuit Boards using RepRap Tech

We are constantly pushing to increase the number of parts the RepRap can make for itself. Why not its own circuit boards? Back in April I blogged on my experiences milling circuit boards on a Darwin. Just because the Darwin couldn't do it out of the box [so to speak] doesn't mean that this won't once be realized.

...I couldn't wait. For the last six months I have been building a larger, tougher, cnc / mill for milling circuit boards. The printed part count is low. I was only able to print the bearings and motor couplings. However, it is still a RepRap in spirit... if I can be so bold. The electronics are Gen 2, with an Arduino at the heart, and the firmware and host are variants of the RepRap firm and host.

After finding most of the ways not to do it I am finally getting high resolution, repeatable, double sided, drilled and scored, boards. Here is an opto endstop 2.1 board that recently came off my "tough" cnc.

I'm still documenting my experiences and getting some bugs out of my updated firmware and host. In the mean time I prepared a video of the board being made. Seeing is better than reading, anyways.

It is my hope that the lessons I've learned through making my own circuit boards will eventually lead to a true RepRap solution. Either Mendel will show itself to be tough enough, it can print something tough enough, or this work will lead to a new species all together that mills itself instead of printing itself. :)

Thanks RepRappers for all the help along the way!

Thursday, March 18, 2010


Final call to do the

Hi, first of all I'd like to thank everybody who took the time to click through all the boxes! Your input is very important to our research, my graduation and to help the RepRap community flourish!

We're closing the survey today, to start data analysis. So if you haven't done the survey yet, you're still in time! :)

It takes 15 minutes on average.


Erik de Bruijn

Wednesday, March 17, 2010


Wiki Goodness!

For those of you who have been keeping up, there has been some talk of major wiki maintenaince being done "soon".....

It's here! The time is finally come! We have migrated the main website over to the same platform/wiki and database as the "".

Oh, and we've upgraded it all to the latest version of mediawiki while we were at it!.

These sites are now essentially equivalent, so a page that used to be at:
can now be found at either of these:

OK , so all the lovely content from the old "TWiki" is still there, and all the content from the 'objects' wiki is still there so the world is a great place. Almost.

Please do bear with us as a now take time to shuff the deck-chairs a little. we'll be reworking the navigation a little, and trying our best to please everyone, so it's sure to work. :-)

If you want to see what content got migrated from the old retired "TWiki" - we conveniently labled them all with a "Category:Twiki" tag. so you can see a full list here:

I hope that's enough info for now!

David Buzz.
Reprap Wiki Hacker.

P.S. Long live the wikifiddlers!


Sunday, March 14, 2010


Hydra Joins the Acceleration Party... with multiple heads

So after about a week and a half of work I uploaded a new release of the Hydra-MMM software and firmware to the sourceforge page this afternoon ( Most of the work was done on the firmware because I got the crazy idea in my head that I wanted to be able to do accelerated movements in 3 dimensions. While this seems somewhat simple at first, I had a hell of a time getting it all to work out. Here are the main problems I ran into
  • If you have a constant acceleration with a non-zero initial velocity, the time interval for stepping cannot be directly determined. A quadratic equation needed to be used to solve for the time interval. This is due to the fact that the motor speed is dependent on the stepping interval (delay between steps), and the distance the machine travels is also dependent on this velocity as well as the constant specified acceleration.
  • (Solved) For some reason, every time I derive the kinematic equation to relate distance, velocity, and acceleration together I get a different result than that which is in the physics textbooks I have used in school. If V = delta x / delta t, and a = (V-Vo)/delta t, if you combine these you get a*deltat + Vo = V = deltax/deltat. Multiplying both sides by deltat, you get a*(deltat^2) + Vo*deltat - deltax = 0. The equation in my textbooks is1/2*a*(deltat^2) + Vo*deltat - deltax = 0. I was forgetting that the V term is actually Vavg which would equal (V-Vo)/2 which answers the factor of 2 difference. Thanks for pointing this out guys!
  • Solving quadratic equations while moving is not a good idea. It was too slow and it was actually limiting my maximum speed (the delay from solving the equation was greater than the interval I was using for stepping). The whole idea of doing this is to allow for faster and smoother stepping so a change was needed. I decided the best way was to compute the acceleration scalers (% of desired speed) for each step and to store those in an array. See the next point.
  • Storing large arrays (200+ items) of floating point numbers eats up SRAM real fast. A 200 item float array requires 200*4 Bytes = 800 Bytes! That is almost all of the available memory on the ATmega168! To fix this I scaled the acceleration scalers up to integer values. The scalers only range from 0.0 to 1.0 so this was not hard to do and it cut the memory usage in half (integers only require 2 Bytes instead of 4 Bytes for floating point numbers).
  • I originally intended to have separate acceleration and deceleration calculations, but it proved to be must faster to just calculate the acceleration values and then duplicate those in reverse for deceleration. I also has a problem when solving the quadratic equation for negative acceleration. The radical is negative if Vo^2 < -2*a*deltax which can happen for deceleration. See the 2 figures below.
Figure 1 - Acceleration from 0 to 80 inch/min

Acceleration is smooth from 0 to 80 inch/min with no errors in the calculations.

Figure 2 - Deceleration from 0 to 80 inch/min

Note the circled section where there should be 2 or 3 more steps before getting to zero velocity, however, this is the area where the value inside the square root was negative and thus, it could not be calculated.
  • So again, it was must easier to just use the acceleration calculations where acceleration is positive and the value inside the square root can never be negative. To help with this problem, I also added a startup speed variable so the motors can start from a specified velocity. For example, if they have no problem jumping to 0 to 30 inch/min, start them at 30 and then ramp up to 80. While this change, as well as only calculating the positive acceleration values got around this problem, I am still intrigued why this was happening.
Eventually, I got everything working, however, it took much longer than I expected. The end result is pretty awesome and allows for a much smoother initial startup as the motors can start from a lower speed and slowly ramp up to the higher speed. Before this, they were just instantly trying to run at the desired feedrate and that made things pretty shaky. I can't wait to test this out of the machine once we get the X and Z axes fully operational (hopefully in the next 2 weeks). I now also have a great deal of respect for Adrian who also got this working on the Reprap front. I wonder if he had as many problems as I did??

Anyways, in addition to adding acceleration to the mix, I also added support for multiple toolheads (the end goal of the Hydra-MMM project). This includes functions for switching heads and tracking the location of each head while building. I still have more work to do with this, but the basic functionality is there. See the release notes below for all of the other new features added in the 1.3 release!

- Acceleration is now supported and computed using kinematics (no linear approximations here!). The computations are performed before each move and have been optimized to reduce CPU and SRAM usage.
- Added support for several T (toolhead) commands for managing up to 4 independent toolheads. See firmware for list of new commands. Also note that there are new parameters that must be declared if multiple toolheads are to be used. See the top of the firmware.
- Added support for physical max and min endstops on each axis
- Maximum software endstops added in case physical max endstops are not available
- PID temperature library and cpwStepper library are now options and can be excluded from the firmware if it is not desired
- GUI now supports M105 command to receive temperature from the firmware and print to screen
- Fixed bug with time to move calculation being dependent on the x axis
- Lots of optimization to get the firmware small enough to fit on the ATmega328 (reduced total firmware size more than 6KB!)
- Serial baud rate changed to 19200 for compatibility with Reprap and Makerbot hardware

As always, you can download the release files at the sourceforge project page:

Let me know what you think!

Labels: , ,

Friday, March 12, 2010


first tests building a selective laser sintering printer: part 3

Hi folks,

This is just a quick post, but I thought I'd post some progress:

The ball-joint system that I'd thought up for the pan-tilt mirror in [part2] was a bit haphazard and didn't work very well, so I decided to rethink the whole thing. A gimble would be idea, but placing the steppers right on the gimble axes wouldn't yield a workable resolution, and would need some gearing to make it work. To keep things simple, I wanted to figure out a way to use lead screws (to get that extra precision), without having to worry about printing some gears out.

I was trying to think of a simple system that would allow you to use a lead screw with a gimble, but there are tricky issues where the motor itself would need to pivot. I left the idea with my dad for a week (especially so I wouldn't be tempted to work on it instead of my thesis), and I'm pretty impressed with what he made. There's still some backlash in the nuts, and ideally you could use even smaller steppers (or, servos, if you could find some really tiny, really high resolution ones), but I think it'll work just great for testing!

Right now I'm tinkering with ideas for how fresh material will be delivered over the build chamber. I'm thinking simple, inexpensive, and easy to make... make your mistakes cheaply, after all...

alt=""id="BLOGGER_PHOTO_ID_5447959549545405538" />

this last one is a 2 second exposure, where the simple square that i coded into the dsPIC controller can be seen (though it's a little blurry). The test square is about 100 steps on a side, and that translates to about 1cm of travel from about 10-15cm high -- so if the mirror assembly is around 5-10cm up, there should (hopefully) be plenty of resolution for the ~1 inch diameter build chamber.

(ps -- still no luck on finding inexpensive thermoplastic powder, the consistancy of flour. happy to hear thoughts on this that haven't already been covered in the past couple posts).

thanks for reading :)

Labels: , ,

Sunday, March 07, 2010


reprap/makerbot gcode visualization tool (3b) code posted

Hi folks,

just a quick note: i've (finally) posted the code to the gcode visualization tool (version 3b) for toolpaths exported from skeinforge. the code is in an attachment on the discussion thread on the forums:,27884

sorry about the lateness of posting the code -- it had completely skipped my mind! happy tinkering! :)


previous posts:
version 3b ( )
version 2a ( )



Don't tap stepper motors

I was ready to mount a stepper motor on a mcwire-ish x axis and decided to tap the holes of some nema 17's I bought for reprap a while back. Never did I imagine that the small metal filings would sneak through the cracks, and because of the powerful magnets inside, wedge between the magnets and the heads causing the motor to cease its steppity rotation... aurghhhh. Well at least I didn't spend a lot for the two I messed up. Next time I just use the right screws, even if it takes another trip to the hardware store. Just thought I would mention this to anyone else thinking to do the same

This page is powered by Blogger. Isn't yours?

Subscribe to
Posts [Atom]