Variable Density Hilbert Curve

First few images from a quick proof of concept, but first the background... I've been pondering infill algorithms for a while and wondering how best to account for variable internal density, whilst still retaining high print speed. Whilst looking at space filling curves yesterday, it occurred to me that it should be possible to vary the apparent density of the curve simply by modifying the recursion depth inline with a reference model or image.

To quickly judge the effectiveness of this approach, I've put together a very quick applet that varies the recursion density of the Hilbert Curve according to the average grayscale levels of a reference image. Below are a couple of samples to illustrate the effect.

 1) Rubix Cube - Hilbert Curve between 4 and 8 levels of recursion:

2) Kitten - Hilbert Curve between 6 and 9 levels of recursion

3) Kitten - Hilbert Curve between 5 and 9 levels of recursion

The two kitten images show the effect of modifying a "contrast" operator, that controls the level of recursion associated with each grayscale range.

Next step is to see what happens if this approach is combined with a density map generated along the lines of this post: http://axuv.blogspot.com/2012/01/adaptive-infill.html. Off to Amsterdam for a few days, so this will have to wait for next weekend...

Bezier Curves with Marlin - Video

Quick video showing a "monster", rammed with bezier curves, being printed via modified Marlin firmware.

Bezier curves with Marlin

Fixed it! Not sure why, but adding a ClearToSend() after processing the G5 code has sorted the weird hanging issue. Ran a quick test drawing a fairly complex monster with loads of bezier curves (converted from an SVG I found online) and it is very impressive. Watching a pen zip round the curves at one hell of a pace has left a great big grin on my smug mug. Good place to call it quits and get some sleep... will try and post a video of it in action tomorrow.

Guess this means I'll have to look at adding bezier curve path smoothing to Slic3r - at least I can start with the arc detection as a basis. Least squares and Newton-Raphson, yummy.

Extruder and hot end assembly

Well, it's certainly been a while since my last post, but after an extremely hectic finish to last year, including transitioning to a new role in another function (!), things have finally settled down enough for me to make some progress on the build.

Over the last week or so, I've put together the Wade's extruder from the thingfarm kit I bought last year. I've also started assembly the J Head Nozzle (MKI), also from thingfarm. It's been a slow process, as I've only had the odd few minutes to spare and keep finding little bits that I need to progress. The most recent was discovering the fire cement I bought to fit the power resistor is useless (far too grainy) and instead opted for some rope seal adhesive (off the back of a hophead recommendation in the forums), which turned out to work a treat.

Installing the two M3 screws in the grove mount hasn't gone quite so well.... I clamped the hot end into the extruder, drilled the holes to 2.5mm and then discovered my taps have gone missing :( Being an impatient sod, I figured I'd just drill out the holes a little and see if the M3 bolts would self tap. It kind of worked - the hot end is held rock firm, however, the bolts got pushed outwards by the peek and have ended up, well, wonky is probably the most gracious way to describe it. In conclusion, looks shoddy, but does the job. No doubt something I can remedy at some point .

Can't do much more tonight, as the rope seal adhesive is still setting, but next step is to wire up the hot end and extruder stepper, then see if the whole shebang works!

As a mild distraction, I couldn't hold out any longer and bought an iMac just after the New Year. While looking for any excuse to use it, I took the opportunity to get the Marlin firmware installed, the latest version of Pronterface and slic3r. I've also started incorporating the bezier code I wrote into the Marlin firmware, something I'd meant to do last year, but never got to it. The first quick hack almost works, however, it seems to randomly hang for approx 10sec after processing a bezier curve g-code. Have spent an hour or so trying to debug it with no joy... very annoying, as I can't see any real difference between how the bezier code works vs the arc code. Grr. No doubt will figure it out after a few more hours digging.

Times like this I wish I had an in-circuit debugger...

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.

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.