I've shelved the SVG conversion code for now, as although it's a fun challenge, it's somewhat worthless longer term.
I see my next few activities as:
- Develop a GCode pre-processor that sits between Skeinforge and the printer host, which will convert incoming continuous paths into splines
- Add an acceleration calculation into the pre-processor to provide acceleration "hints" to the firmware
- Modify firmware to support acceleration hints, with graceful degradation to current acceleration algorithm
- Implement tolerance-driven path smoothing to the pre-processor
Might take a while to get through all that, but I've made a start tonight by working up a basic algorithm to take a sequence of linear line segments and convert them to a sequence of bezier curves using a modified form of the Finite Difference approach from http://en.wikipedia.org/wiki/Cubic_Hermite_spline. Currently it smooths all segments, but next I'll add an inter-segment angle calculation and only smooth segments with a small angle (perhaps <10 degrees). Then just need to wire that to a GCode parser and that should yield a functioning, albeit very simplistic, pre-processor.
Extended the "tool" support for the bezier G5 code by adding visualisation support for the curves in Pronterface - also added relative co-ordinate support to the visualisation (both actually implemented in gviz.py). Then felt the need to stress test the code, so vectorised one of Gary Hodgson's Prusa images and ran it through the mill...
Sorry about the poor quality video, couldn't face waiting for an HD version to upload (must find a way to edit the MOV files my camera produces, otherwise even a short clip can be 400MB sad smiley )
Spent the last week working on a java applet to convert SVG to GCode, incorporating my new G5 code for cubic bezier curves. As of this evening, the conversion process will take basic curves from Inkscape and convert them to functional GCode! After a bunch of tests, I figured it was time to film something and share it... what better than "Hello World"
That's right folks - a reprap printing a complex set of bezier curves, with all the complex stuff happening in the modified Sprinter firmware!
The conversion process is working pretty well, need to improve transform support and some more of the SVG path primitives to make it more robust/flexible. I'm starting to hate the SVG standard - it's a real half-way cop out between a bespoke language and XML. What's the point in using XML to encode image data, if you then bail on the critical stuff and encode complex paths/transforms in attributes using a completely different (and fairly complex) syntax!
Of course, I might get distracted by building the extruder/hot-end, but if not, then I'll also be taking another look at how to make the acceleration code play nice with curves.
Started a new thread on the reprap forums to track the development of some new Sprinter capability - namely the addition of a new GCode for cubic bezier curves. See the thread for more details:
Since my last post, I've been working towards getting the core electronics finished, all axes tested and a getting fully functional toolchain setup.
Having got the Y axes moving, I went on to wire in the X and Z steppers. Then expand my little test sketch to do a couple of back/forth moves on each axes to check everything was running smoothly:
This went fairly smoothly, but the Z axis bearings were sticking. I went for the same "fix" as for the other axes and cleaned the rods with a wet wipe and then smeared some lithium grease. That made a big improvement, but it stills needs a weight on the idler end, otherwise it won't slide down under gravity alone. Not a big issue for now, and I'm vaguely hoping the bearings will wear in after a bit of use.
Next was soldering and fitting the Opto Endstops. The kit/instructions from Traumflug were excellent and went together without issue. Fitting the actual sensor was easy enough, but my current solution for the flags is extremely crude - will definitely improve this at some point, but it will do for now. As I fitted each endstop, I extended my sketch to include a set of homing tests:
At this point I couldn't resist doing some speed tests and discovered that the Z axes feedrate is severely limited due to the very low Pololu drive current. I don't want to turn the current up until I've added heatsinks, so got on and ordered a set of 8 off ebay - a bargain at £1.74, but given they are coming from China I'm only half expecting them to arrive.
Once all the endstops were working, it was time to install some proper firmware. I've settled on the latest version of Sprinter, this was after reading up on peoples comments on the various mature firmwares and also after skimming the source code repositories for each. Overall I was impressed with the apparent performance, feature set and also simplicity of the source for Sprinter.
Because of limited cable length, my X and Z stepper motor pins are swapped vs normal RAMPS config, but I had already created a variant of the pins.h for my test sketch, so it was a simple matter to copy that over and upload the firmware.
To test everything, I thought I'd try out Kliment's Pronterface script from the Python Printrun host software - worked an absolute treat and had axRap dancing to G Codes in minutes.
After a while of playing with hand-coded G Code files, I decided it was time to try a more challenging stress test. Rather than jump straight to Skeinforge, etc - I decided to tape a pen to the carriage and play with drawing some pictures. First up was more hand coded G Code to draw basic shapes, but then I struck on the idea of generating G Code for a basic fractal...
That quickly lead to the infamous Sierpinski Curve, which has a nice little Java applet on the associated wikipedia page. A little hacking and I had the script generating nicely scaled/translated G Code, with a little bit of header/footer code to home axes, set feedrate, etc. Here it is printing the 3rd level of recursion at 150mm/s - you'll need to watch full-screen to see the red ink!:
By this point it was very late Sunday night (hence the poor quality video) and time to call it quits. Mission for this week is to build the extruder, hot-end and mount the heated bed - all the missing parts arrived last week, so just need the time to focus!
I also ordered a reel of PLA last night and picked up some Fire Cement from B&Q, so nothing left to order/buy before my first print - can't wait! :)
Thought I'd kick things off this evening by connecting up the Y-axis motor and writing a short sketch to drive the stepper back and forth a few times - simple right? Wrong.
Connecting the stepper was easy enough, writing the sketch was easy enough - but would the motor move - oh, no... not a chance. So, having traced pin assignments, double-checked code, read through the Sprinter firmware, several tutorials on adruino/stepper combos, fiddling with Pololu driver current and finally rebuilding the connector for the motor, I finally found the issue.
*drum roll*
The Pololu enable pins are inverted - low to enable, not high! In my haste to write that little sketch, I missed that little fact and have summarily wasted the rest of the evening - smeg. On the up side, I found this little tutorial on assembling servo connectors:
Which helped a great deal, as it turns out my first attempt was a criminal bodge compared to how it should be done - I'm sure I used to know how to do this stuff, but apparently it's been too long.
Having got the enable pin the right way round, everything works perfectly. I even took a few minutes to make the sketch accelerate the motor at the beginning/end of each move just for kicks... makes the motor sing a little tune as it moves :)
Now I'm knackered, so must sleep and will have to wait another day to get the rest of axes wired :(
PS - will youtube a video tomorrow and post the sketch in case anyone else might find it useful
A few hours this evening, and the odd burst over the last two weeks mean the axRap now has a brain and beating heart.
It began on dark, mild night when the organs of an old ShuttleX SSG were removed...
Dragged back to the lab under cover of darkness, the heart of the shuttle was stripped down to the bare essentials...
All surplus connections were removed, the auto-sense connection soldered onto the bleeding stump where the 3.3V wires used to be. Power-ok (gray) and a 5v line were kept for a possible future application. Power-on (green) and a ground were connected to an old toggle switch then everything was sewn back together by hand...
Then it was time for the saw, at it's mercy was some left-over 6mm plywood from the bottom plates. A few quick strokes, a flurry of the bone drill and a makeshift cradle for the heart was ready...
With the Shuttle's blood barely dry on my hands, I turned my attentions to the brain. A further application of saw, drill and heavy duty threads produced the base of a cranium - with cooling fan. Arteries were laid in, held in protective spiral bindings, and with a flick of the switch I bestowed animation upon this lifeless matter. Admittedly, the animation was merely the drone of a cooling fan, but still - it's progress.
Given it's 1am, I need to get some sleep - so connecting the first of the stepper motors will have to wait until tomorrow. Before I sleep again, I'm hoping to have at least one axis moving under Sprinter firmware, including an endstop.
Admittedly this is a little premature, but I'm keen to detach my printer from the host computer as soon as possible. Wired Ethernet is my preferred option - it can be accessed from all of my devices (desktops, laptops, iPad, iPhone, etc), is fast, reliable and fairly cheap compared with wireless options.
Reading this tutorial Arduino Ethernet + SD makes it sound doable and there's a chance I can borrow an Ethernet shield to have a play.
I envisage an Aduino/Ethernet combo acting as the host and talking serial to the printer's Arduino Mega/RAMPS controller. The host would support uploading a G-code file to the SD card, queuing prints, control power to the printer (toggle ATX power) and also act as a watchdog by monitoring printer enclosure temperature/dead comms link. Cost of the Ethernet module would be somewhat offset by avoiding the need for a display/controls on the host/printer as these can be provided via the web interface and accessed from a existing device.
It might also be practical for the host to operate multiple printers - something I'm keen to try.
Ordered these a while back, but today they arrived... 6x Gen7 EndStops, courtesy of Traumflug
Will try and find some time to assemble them later this week. I did manage to find a few minutes this evening to rig up an ATX supply to the RAMPS board and test everything powered on ok - looking good so far. Can't wait to get the motors connected and test the axes!
Having explored various options (alu tooling plate with resistors, silicon heating mat) I've taken the easy way out and ordered a PCB Heatbed Mk1 (by Prusa) from reprapsource:
Pity about the shipping charge, but seemed to be simplest option overall and good value compared to the alternatives (~£42 inc shipping).
I also finished the RAMPS electronics last week - will get round to posting a picture soon. Next up is ordering a J Head Hotend and some parts for the Wade's Extruder from thingfarm.org.
Started assembling the RAMPS v1.2 board - just over an hour and I've progressed as far as I can without the Arduino Mega board. Will finish up next week...
Managed to squeeze in a little progress this week...
Loctite
Some of the nuts on the frame were already working loose (as of last weekend), so after skimming the forums for suggestions - I ordered 10ml of Loctite 243 ThreadLocker. As of yesterday, I've now put a dab of loctite under each nut on each vertex, plus those around the Z-motor mounts. This also gave me the chance to fine tune the distances between each vertex.
Lithium Grease
The smooth rods were fairly grubby and there was far more friction on the X/Y axes than I'd like. So.... a few minutes of judicious scrubbing with some wet wipes cleaned the rods, followed by a light application of lithium grease (Castrol LM Grease) has made a big improvement.
Spacers
After my initial assembly, the Y-axis belt met the bottom plate at quite an angle - especially when at a min/max extreme. After a bit of research, this seems to be because the design is intended for a 10mm thick bottom plate - whereas mine is only 6mm. The solution was a couple of ply offcuts to raise the height of the belt mounting point.
Nut-Y-less
The standard Prusa places a nut between the Y motor bracket and the belt pulley - this seems unnecessary and causes additional strain/flex on both the motor shaft and the Y motor bracket. Removing this nut didn't take long and has not only reduced the moment on the motor/bracket, but has also given enough clearance to properly centre the Y-belt against the bottom plate.
RAMPS in the house
The RAMPS kit I ordered from xyz printers arrived yesterday - will get started on soldering that this evening...
A Mega issue
The arrival of the RAMPS kit prompted me to check that it would fit properly on the Seeeduino Mega, only to realise that I've been a complete idiot and somehow missed the fact that the Seeeduino Mega is not pin compatible with the Arduino Mega! and therefore not compatible with the RAMPS shield! :(
I did consider creating a frankenstein mating of Seeeduino and RAMPS, but then thought better of it and ordered an Arduino Mega 2560 off eBay for ~£24. It dispatched this morning, so hopefully will be here on Monday.
I'll keep hold of the Seeeduino Mega for now, as I have an upcoming project planned that will make use of the hardware...
Oh for it was a happy day when that glorious package from thingfarm.org did arrive. Nestled within its corrugated womb was a Prusa hardware kit and 5 high-torque NEMA 17 stepper motors. Being an impatient kind of fellow, I impressed myself by not starting to actually build my first reprap until 22:45! From there, the addiction set in and held out through to 00:30, at which point I really needed the use of a circular saw... and that would definitely be frowned upon by my wife and kids.
Nonetheless, the last couple of hours have been very productive and have seen the basic frame assembled. I've been round and carefully adjusted all critical measurements and it's looking pretty good (if I do say so myself). Next up is fabricating the bottom plate for the Y carriage - that'll be tomorrow evening if I can get away with it :)
All told, it's been great to get started at last and I'm very impressed with the quality/speed of my thingfarm order - will definitely use them again (although just noticed they've put the Prusa hardware kit on sale and it's now £10 cheaper :( ). Rock on tomorrow...
Like preparing for our first child, I'm feeling the pressure of an imminent arrival, so spent several hours over the weekend adding some finishing touches to the nursery (office).... namely some discrete slatwall (destined to hold component bins, tools, etc) and a mini-lathe (inherited):
I'm also the lucky recipient of my final birthday presents - a Seeduino Mega and a pair of Pololu drivers :) Fortuitously, an ebay auction has also gone very well, so I've ordered a Prusa vitamin kit plus a set of 5 stepper motors from thingfarm.org - hopefully they'll arrive next week and then the build can get underway!
I've seen a few comments around the reprap forum regarding some sort of tool to do design rule checks before printing an object. It sounds like a very sensible development and I stumbled across this good example earlier today:
It would be great to incorporate this into Skeinforge, perhaps initially as log data and then later with some sort of visualisation... another one to add to the (rapidly growing) list
I started out looking for kits, and other lazy/cheap ways of obtaining equivalent parts, but can't find anything with reasonable shipping costs (there is quite a bit available in mainland Europe, but the shipping is more than the parts cost!).
If I go it alone, getting the parts from Farnell will cost £12.73 + shipping, but Farnell have a minimum order of £20 - so would have to order the rest of the electronics at the same time to make it economical.
Before I commit to that, I've emailed Traumflug to see if he has any kits available at a reasonable price - fingers crossed.
My family has done me proud and to ease the pain of another year, I'm now in possession of:
A set of printed Prusa Mendel parts, inc Wade extruder - ordered from nophead via ebay, arrived in less than 48 hours and are superb quality - very impressed!
2x Pololu drivers
£50 towards other bits (I'm thinking a bundle of steppers)
Just need a hardware kit from thingfarm and I'm good to go....
I'd like to create a skeinforge equivalent that takes a pure NURBS model as input and creates a set of NURBS toolpaths, the fundamental challenge in this approach is how to efficiently/accurately slice the model into printable layers. Graphics literature contains some promising leads for suitable algorithms, this is the most directly applicable I've found so far:
Ignoring it's use of the GPU, my summary of the technique is as follows:
Find the intersections of two NURBS surfaces by building an octree that progressively identifies child nodes that contain an intersection of surface bounding boxes. The octree is expanded until the desired precision is reached. A new curve(s) can then be fitted to the identified intersection points (defined by the octree leaf nodes), using MLS, etc.
I was hoping for a more direct method, but a search based technique will do although maintaining sufficient accuracy on complex models may involve a large computation overhead. I doubt this would be a practical limitation - especially as the host could be generating slices as the model is being printed, so the delay before printing can start would be negligible.
Referring to my earlier post regarding tool path optimisation, the "smoothing" process would be incorporated into the curve fitting stage of the slice algorithm - intuitively I suspect this could be optimised, such that the fitting algorithm simultaneously solves for an accurate and sufficiently smooth curve.
I'm intrigued by the idea of generating tool paths as bezier splines in the host software with the reprap firmware natively operating on the splines, rather than G-Code. Researching that idea, I came across this excellent paper on optimising bezier tool paths:
Aside from cruising reprap.org, a lot of my research has come from some very well written blogs....In particular, nophead's HydraRaptor blog is crammed with insight, best practises and ideas. Given the number of repraps in the wild, I'm surprised by the very small number of people that are advancing the field with good quality documentation and innovation. I'm sure there are many small contributions, but many of the major advancements seem to come from just a handful of pioneers.
From my point of view, this is a major motivation - I can't wait to get into a community where it may be possible to make a big difference, especially one with as much future potential as this!
So... after months, perhaps years, of reading about RepRap the time has finally come for me to try and build one. Nicely catalysed by placing reprap parts as the only items on my birthday list :)
This of course entails producing a very family friendly list of reprap parts, carefully itemised, from reputable suppliers, such that my family stand a chance of ordering the right bits! All in, I think the total cost will be around £350 (exc filament), which seems very competitive compared to buying a full kit.
What to build?
Settled on a Prusa Mendel as the perfect "first fabber" project, Huxley is too small and I'd rather not go via the repstrap route (keen to get to the good stuff )
Seeduino Mega for the controller (with a bunch of Pololu A4983 drivers) - seems to be the best value and simplest electronics combo - will use to build the stripboard version of Adrian's Pololu electronics
I like really like the look of the new v6 hot end from mendel-parts.com - reviews well and should be easy to maintain/extend
A heated bed seems a no brainer, and the resistor-based heating elements look the way to go
Power will probably come from an old ATX supply (if I can find one lying around) or perhaps a laptop power brick
Who to buy it from?
First up, I'm more than happy to pass business in the direction of Mr Bowyer, so Pololu's and possibly filament will be coming from his spin-off business: reprapltd.com
Vitamins will be from thingfarm.org, great price and a single package contains all main hardware inc. the bits for the extruder
The Seeduino is somewhat easier to source, with several good options. My shortlist is either robotshop.com or proto-pic.co.uk
Mendelfactory.com have some great parts, good prices and good UK shipping, so will use them to mop-up on motors (loving the long leads), hot-end (great kit) and heated bed. They also have good value filament, so my 2nd choice for PLA.
Anything left over (e.g. miscellaneous electronics) I'll probably get from Farnell, Maplin or RS once I'm actually into the build.
I spent last week making those "hard" decisions and compiling a parts list into google docs for the family, assuming they go for it (not like I gave them any other options), I should be able to start assembly by late June - fingers crossed :)
