Reprap ?
The reprap project provides
the designs and drawings necessary to make a self replicating, plastic
extrusion 3D printer. There is only one hitch: self replication; you
need a plastic printer in order to make one. Failing that you need to
bootstrap your printing world by building a 'repstrap' - something
that can (just about) print the pieces.
An ad-hoc repstrap
I have knocked together such a thing from spare bits of floating
timber (mostly MDF and ply-wood), which has some unpleasant calibration
problems: related to thermal issues, and a lack of an adjustable,
(or even better heated) bed. Nevertheless it can be persuaded to print
useful things. Indeed - arguably it is easier to cut a nice, rigid sheet
of MDF, than to create isometric triangles made of studding with complicated
plastic verticees.
Anyhow - the beastie re-uses almost all the parts: steppers, controllers,
belts etc. from an existing reprap - so you can re-use them in the final
product (in theory). It also requires only simple hand-tools (except for
the extrusion nozzle, and knurled driver which is a pain generally). It looks
a little bit like this:
Notice the horrific warping problems that come from poor
print head - bed spacing calibration, and the lack of a heated bed.
Still, this is one of the largest, and most problematic prints
necessary to bootstrap.
I have the vague intention to create useful drawings, and
instructions to replicate/iterate it for others with low-precision
tooling - but the joys of LibreOffice are ship-wrecking this
aspiration currently. Please also note that the all-important safety
goggles are just out of frame somewhere.
Making large z axis gears
One of the most fun problems of repstrap construction are the
gears. After several attempts - to whittle gears from acrylic rod, to
make them from MDF, and so on I hit on a near perfect solution,
reproduced here for your gear-constructing pleasure.
It turns out that simple 30mm panel-pins fit rather snugly into the
required timing belt, creating a nice firm fixing. So - this makes the
construction of the large gears a matter of rough cutting vague disk shapes,
(or better using a nice large circular cutter) four disks from thin ply-wood,
then using the stencil linked below - marking out the pin locations, drilling
them through (as vertically as possible) with a 0.5mm drill, and then simply
pressing the pins through. This and a pair of nuts in the centre yields a
beautiful, functional z drive, as modelled by my youngest, as she
concentrates on reprap assembly thus:
Stencils for gears
It turns out to be remarkably hard to draw gears, or lay
them out manually by measurement. Luckily most people have a
phenomenally accurate ink-jet printer. Thus simply print out this file:
gears.odg -
clearly using LibreOffice if
you don't have it. Then use a bradawl to make holes to enlarge with a
drill in the right positions.
Making stepper gears
These smaller gears present a real problem for ply-wood -
which would just crack and split, and not provide enough purchase on
the shaft of the stepper. After some initial semi-functional attempts
with some aluminium, I discovered that the perfect material for small
pin gears is near to hand, and luckily is stocked in your kitchen, it
looks like this:
Naturally, it is only a matter of explaining to a suitably
patient wife, her desparate need of a new chopping board, and the
invaluable nylon is procured. To satisfy yourself that it is indeed a
wonder material, try driving a panel pin into it 5mm from the edge,
and then breaking it out.
Attack the chopping block with a junior hack-saw or some such
device, to make an octagonal piece of suitable diameter. Again use the
bradawl, stencil, and 0.5mm drill as above. Drill a larger central
hole, which should be of a slightly smaller diameter to the drill
shaft (which should have flats filed onto it).
Simply 'drift' (ie. wallop with a hammer) the nylon onto the shaft
for a fool-proof fix. Eventually you end up with something beautiful
like this:
Why bother ?
Hopefully, after much more wood hackery, adjustment,
suffering, remedial medical treatment and so-on you can finally
produce a working 3D printer, and hence something actually
worthwhile. While this is only a prototype - and died on the
first attempt of a lawyer to bend it, the full (more solid)
version has resisted the attempts of a long line of hackers
in their eagerness to break the end off; enjoy:
Of course, you really need to use RepSnapper
on openSUSE for controlling that sort of thing.
-
Up early, dropped babes at school, wandered through E-mail.
Admired the large patches Norbert Thiebaud is creating, and set too
writing a vtable enumeration tool for OpenOffice. But why ?
Re-factoring C++ and the vtable problem
The opportunity
Consider that you have large piece of C++, over many years, for
reasons unknown, it has accumulated (at least) four boolean types:
FASTBOOL, BOOL, sal_Bool and of course
the native boolean type bool. Now consider a class with a virtual
method in it:
class Base { ... virtual void setValue (BOOL b); /* A */ }
class Sub : Base { ... virtual void setValue (BOOL b); /* B */ }
Please notice that these two classes are highly unlikely to be in the
same header file, and may even be separated by many leagues of code,
so you might never notice.
A small cleanup
Now imagine that we want to cleanup this obsolete 'BOOL' to a 'bool' -
that would be nice and pretty; so - since we are hacking on 'Sub' - we
change it there, and we change all the callers in Sub's implementation:
class Base { ... virtual void setValue (BOOL b); /* A */ }
class Sub : Base { ... virtual void setValue (bool b); /* B2 */ }
At this point we have a problem - we suddenly broke the functionality
of the Base class, and anyone calling the virtual method A. This is
because without realising it we introduced an entirely new method with
the same name and a different signature - by the miracle of polymorphism.
ie. now we have two virtual 'setValue' methods, and B2 does not
override A. That is not good.
Of course, because this is a feature, the compile will just love it,
and suddenly, magically compile a completely different piece of code, and
better - since the change is almost invisible to the casual reader this
will be a nightmare to debug. Interestingly changes such as the above may
seem rare, but are only the top of the iceberg - a more common incidence
of these crops up in 64bit porting, where there is some mix of different
types down the virtual function chain - someone overrides with a different
typedef - all of which previously resolved to 'int'.
How to avoid some grief
The (rather dumb) tool I hacked up today tries to avoid this sort of
problem. It does this by noticing that when we make this sort of slip, we
add a new virtual method to Sub's v-table. Thus - if we simply
print-out all the vtables sizes (in slots) before, and then after a change,
we can rapidly check if they match. If there is a disparity - we can find
the class that changed size, wind back to (all of) its parents, and work
out which one is missing a suitable change. This technique was remarkably
succcessful in finding 64bit portability problems (by comparing 64bit vs.
32bit builds) when Kendy was working on the original OpenOffice.org port to
64bit architectures. The tool is here
How to re-introduce grief
One final deep joy about C++ is that there is no real need to mark an
overriding method as virtual (though most people, most of the time tend to).
So we can write the original problem just as well as:
class Base { ... virtual void setValue (BOOL b); /* A */ }
class Sub : Base { ... void setValue (BOOL b); /* B3 */ }
It is worth noting at this point, C#'s much better, and more readable
syntax, mandating an 'override' for B3. Then lets re-add
the great change we made before:
class Base { ... virtual void setValue (BOOL b); /* A */ }
class Sub : Base { ... void setValue (bool b); /* B4 */ }
So - now we have an even nastier beastie - in this case by changing
the type, we suddenly stop overriding A, but instead of creating a
new virtual method, we create a normal method B4. Worse - this
doesn't change the size of the vtable - so it is even harder to notice.
At this point, at the moment - you loose.
All is not lost (in future)
Fortunately, this shouldn't be entirely the end of the story; in
subsequent iterations, it should be easy to add a 'method count' that
can be calculated for each class - and compared before and after, this
would allow B4 to be detected rather easily. Perhaps tomorrow
I'll expand the tool to do that too. Probably I am missing some other
obvious gotchas, but getting this wrong - particularly in deeply
inherited hierarchies, with complex interactions can create some
particularly nasty problems to debug.
- Up late, sync, with JP, prodded mail, patches and blog entries.
- Update1: Mikael Olenfalk points out that the Mozilla guys have some
magic keyword
they use for this, along with Dehydra - probably
libreoffice should be doing the same; we could add an
override
keyword that could be enforced by Dehydra, and #define it
to virtual + some attribute (I guess).
- Update2: A friendly hacker advised me that the Sun Studio
compiler warns about virtual functions being hidden by non-virtual ones,
it seems g++ has an equivalent
-Woverloaded-virtual -Werror=overloaded-virtual that
should be used to detect this case. There is also a nice wikipedia
page with the latest C++
standards thinking
