Thursday, March 18, 2010
Final call to do the RepRapSurvey.org
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.
http://www.reprapsurvey.org
Thanks!
Erik de Bruijn
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.
http://www.reprapsurvey.org
Thanks!
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 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:
http://www.reprap.org/bin/
can now be found at either of these:
http://www.reprap.org/wiki/
http://objects.reprap.org/wiki/
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!
David Buzz.
Reprap Wiki Hacker.
P.S. Long live the wikifiddlers!
Labels: wiki
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 (https://sourceforge.net/projects/hydra-mmm/). 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:https://sourceforge.net/projects/hydra-mmm/
Let me know what you think!
Labels: acceleration, hydra, hydra-mmm
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 :)
~peter
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 :)
~peter
Labels: selective laser sintering, SLS, stereolithography
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: 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! :)
~peter
--
previous posts:
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 )
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! :)
~peter
--
previous posts:
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
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
Sunday, February 28, 2010
Repola Computations
[Updated: Attached new images to show more accurately the curve scales. Previous images lacked an accurate 'zero' frame. Also added a 'zoom' image to show spline error up close]
I have made some progress working thru the conversion of linear segments into an N dimensional spline path.
I've created a simulated environment for the RepolaRap XY platform to test some of my ideas out. I created an algorithm curve consisting of line segments of various lengths, and fractally segment it so I get a few quiet areas with long straight segments, as well as some noisy areas with lots of tiny segments.
My goal will be to produce an complete description of every control that must change at each precise moment, and approximate this with spline segments to within as much accuracy as is needed to get an accurate build.
This first image shows the general shape that I've been testing with. The blue segments are simple euclidean line segments, and would represent the output of a G-Code interpreter of all three axes, as well as extruder rate (integrated to get an extruder 'position'), temperature control, fans, and any other special devices that would need to be controlled. Although I assume these are straight linear segments for my simulation, the conversion to splines does not actually require they be linear, only that some function be described that can give its position at some time t.
The red segments in this image represent the spline approximation for the X and Y axis converted into two angles for a two link arm. The simulation allows for distinct pivot arm lengths, but I have assumed they are the same in this image, E.G, that the extruder will be able to reach the exact center point of the build platform.
Mapping the angle positions across time results in the following chart. I have chopped it into the modular domain, rather than extend it beyond the 360 degree motion that actually defines model space. I point out those cases where the apparent branch cuts actually do not exist in the simulated revolutions. As I have mentioned previously, only one axis actually needs 360 degree freedom (the build platform); the radial arm only requires 180 degrees, so no it does not require welding, and no special logic for handling the branch cut is needed.
My next goal is to figure out a way to dilate or compress the time component such that one axis will always move at maximal jerk, acceleration, or velocity. I think this will happen by cutting each spline segment into as many as six segments as different limits are hit. I've included the stock graphs for the equations that will need to be dilated, consisting simply of the first, second, and third derivatives of the angular motions.
I fully expect during extrusion that the extruder will actually arbitrate the majority of time, with the exception of very noisy, very short segments. As I've not yet gotten this logic in yet, it's hard for me to judge yet.
One last image here shows what the spline error tends to look like. This image was generated by finding a region with some error, and zooming into it 100x. This is the first angle area on the right near the top of the path.
I have made some progress working thru the conversion of linear segments into an N dimensional spline path.
I've created a simulated environment for the RepolaRap XY platform to test some of my ideas out. I created an algorithm curve consisting of line segments of various lengths, and fractally segment it so I get a few quiet areas with long straight segments, as well as some noisy areas with lots of tiny segments.
My goal will be to produce an complete description of every control that must change at each precise moment, and approximate this with spline segments to within as much accuracy as is needed to get an accurate build.
This first image shows the general shape that I've been testing with. The blue segments are simple euclidean line segments, and would represent the output of a G-Code interpreter of all three axes, as well as extruder rate (integrated to get an extruder 'position'), temperature control, fans, and any other special devices that would need to be controlled. Although I assume these are straight linear segments for my simulation, the conversion to splines does not actually require they be linear, only that some function be described that can give its position at some time t.
The red segments in this image represent the spline approximation for the X and Y axis converted into two angles for a two link arm. The simulation allows for distinct pivot arm lengths, but I have assumed they are the same in this image, E.G, that the extruder will be able to reach the exact center point of the build platform.
Mapping the angle positions across time results in the following chart. I have chopped it into the modular domain, rather than extend it beyond the 360 degree motion that actually defines model space. I point out those cases where the apparent branch cuts actually do not exist in the simulated revolutions. As I have mentioned previously, only one axis actually needs 360 degree freedom (the build platform); the radial arm only requires 180 degrees, so no it does not require welding, and no special logic for handling the branch cut is needed.
My next goal is to figure out a way to dilate or compress the time component such that one axis will always move at maximal jerk, acceleration, or velocity. I think this will happen by cutting each spline segment into as many as six segments as different limits are hit. I've included the stock graphs for the equations that will need to be dilated, consisting simply of the first, second, and third derivatives of the angular motions.
I fully expect during extrusion that the extruder will actually arbitrate the majority of time, with the exception of very noisy, very short segments. As I've not yet gotten this logic in yet, it's hard for me to judge yet.
One last image here shows what the spline error tends to look like. This image was generated by finding a region with some error, and zooming into it 100x. This is the first angle area on the right near the top of the path.
Friday, February 26, 2010
Hydra-MMM Software/Firmware updated to v1.1
First off, I am thrilled to see how many people were willing to try out my software and firmware. Thanks for all the feedback from the community! I pushed out an update this afternoon that added several of the features that were most requested. A summary is below:
v1.1
- Extruder support added that automatically determines correct extruder speed based on XYZ specified federate
- Support for external motor drivers added, the option is now at the top of the firmware to choose to use dir/step method (for external driver) or defining each coil and using MOSFET transistors or something of that nature (see below)
- Wiring diagram added by request to show how to hook up a stepper motor without an external motor driver
- Made preview window larger and added ability to change the size easily in the Processing sketch (variables pw_width and pw_height)
- Sample gcode file added by request
The biggest things here are that external motor drivers are now supported. This means that the firmware can now seamlessly be used with a Reprap or Makerbot machine. There is still one limitation that the current firmware assumes you have a stepper motor driver. If you happen to be using a custom extruder board with RS232 comms or something of that nature, you will have to either throw together another external motor driver or just grab 4 FETs and wire the motor up as shown in the schematic below.
If you do choose to go with the above method, the advantage is that you get a microstepping driver for only a few bucks! I hope to add RS232 or RS485 comms soon, but being that I won't be using that method for Hydra, it is a low priority at the moment (unless I get a lot of feedback saying this would be useful!). So as always head over to the sourceforge page for the latest and greatest: https://sourceforge.net/projects/hydra-mmm/
Labels: firmware, hydra, hydra-mmm, release, software
