Wednesday, March 31, 2010
Hydra: Cartesian Robot Assembly Completed
Tuesday, March 30, 2010
selective laser sintering printer: part 4 (putting it all together)
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] [cogsci.mcmaster.ca/~peter]
Monday, March 22, 2010
New Arduino Mega Shield for CNC interface!
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
...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 RepRapSurvey.org
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
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 http://www.reprap.org website over to the same platform/wiki and database as the "objects.reprap.org".
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: http://www.reprap.org/mediawiki/index.php?title=Category:Twiki&action=edit&redlink=1
I hope that's enough info for now!
Reprap Wiki Hacker.
P.S. Long live the wikifiddlers!
Sunday, March 14, 2010
Hydra Joins the Acceleration Party... with multiple heads
- 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.
- 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.
Friday, March 12, 2010
first tests building a selective laser sintering printer: part 3
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...
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 :)
Sunday, March 07, 2010
reprap/makerbot gcode visualization tool (3b) code posted
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: http://dev.forums.reprap.org/read.php?12,27884
sorry about the lateness of posting the code -- it had completely skipped my mind! happy tinkering! :)
version 3b ( http://builders.reprap.org/2010/01/added-streaming-to-gcode-visualization.html )
version 2a ( http://builders.reprap.org/2009/09/reprapmakerbot-gcode-visualzation-from.html )
Labels: gcode visualization tool