Wednesday 17 August 2011

Curve fitting

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.



Monday 15 August 2011

Drawing a Prusa

Minor update this evening...

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 )

Hello World with Bezier Curves

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.

Friday 12 August 2011

Native cubic bezier curves for Sprinter

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:

http://forums.reprap.org/read.php?147,93577

Will post a video soon

Tuesday 2 August 2011

Sierpinski Curve at 150mm/s

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! :)