Tag Archives: RepRap

RepRap Principle

Replicating Rapid Prototyping: 3D print parts for 3D printers.


  • 2020/12/29: adding Ashtar K photos and “genealogy” tree or lineage.
  • 2020/12/28: published


Adrian Bowyer, an academic at the University of Bath, coined the term RepRap as “RepRap is an open-source self-replicating rapid prototyping machine”. It became obvious that RepRap also meant that the plans would be Open Source, so the developers could iterate and improve the design over generations, like a biological development.

Adrian Bowyer (left) and Vik Olliver (right) showing how one 3D printer printed parts for another 3D printer

Adrian’s focus was on easy to source parts, such as threaded rods, nuts and bolts, beside the 3D printed parts which connected the non-printed parts together:

RepRap Darwin Version 1.0 (May 2007)

The first RepRap was named “Darwin”, a cubic frame work with printhead XY (left/right, forward/backward) and bed Z (up/down) – its printable parts were printed by a “Stratasys Dimension – a commercial 3D printer, see also 3D Printer History.

RepRap “Darwin” and the research behind is well documented in this paper:

The design eventually got simplified, the amount of parts of printed and non-printed (aka vitamins) were reduced:

A major step was done by Josef Prusa, who joined the RepRap movement with his “Mendel Prusa” (2010), which he iterated into “(Mendel) Prusa i3” in 2012, the XZ axes were no longer build with threaded rods but a laser cut frame.

During 2010’s laser cutters began to be considered part of common Maker (maker = Do It Yourself or DIY) equipment and so it became a viable approach to build 3D printers:

Josef Prusa started his Prusa Research company and still follows the RepRap principle (2020) by 3D printing parts of his Prusa i3 series on a 3D printer farm:

Prusa Research 3D Printer Farm

Other companies like Makerbot, Ultimaker, and the many chinese manufacturer used other means to fulfill their needs for fast and scalable production of parts.

And therein lies also the limitations of the RepRap, 3D printing is slow compared to injected mold or sheet bending based production, it doesn’t scale well for centralized production.

In this particular interview Adrian Bowyer shares some historic perspective of the early days of RepRap, highly recommended:

Deeper Roots of RepRap

I gonna quote a larger part of the paper on RepRap – The Replicating Rapid Prototyper, to illustrate the deeper thoughts behind the idea of self-replicating machine:

(— start of quote —)

The Genesis of RepRap

Sometimes the progress and the reporting of a project can obscure the train of thought that instigated the project. Typically, that train of thought was incomplete, or sometimes downright wrong. In this section, we attempt to set down as a matter of record the ideas that led one of us (Bowyer) to invent RepRap.

Understandably, the design of most practical artificial reproducers starts with proposed solutions to many technical problems of getting a kinematic machine copy itself. However, RepRap was not instigated in that way at all. RepRap was instigated by biomimetically considering extant naturally evolved strategies for reproduction.

Biologists categorise most bacteria, archaea, protists and plants as autotrophic because they are capable of selfnourishment using inorganic materials as a source of nutrients and using photosynthesis or chemosynthesis as a source of energy. However, almost without exception, all the natural species of reproducers in the world (including those in the previous sentence) depend upon other species in some way for their survival and successful breeding – by this light they are all assisted self-reproducers. A few lithophile micro-organisms can survive alone in what are essentially mineral environments, but their numbers are vanishingly insignificant compared with those of the interdependent species. Clearly, primordial organisms must have been completely autotrophic, but now that way of life has all but disappeared because the environment in which modern organisms have evolved consists, to a first approximation, entirely of other reproducers.

Yet research into artificial reproduction often concentrates upon making the reproducer as autotrophic as possible (like the lithophiles), and researchers regard this as an important aim. Clearly this aim is important for an extraterrestrial reproducer, but why so for a terrestrial one? Why try to follow a strategy that biology has all but abandoned? An artificial reproducer designed to be interdependent with the natural reproducers that will make up its environment would be more likely to be successful.

Dependencies between species take one of the following three forms: predation, commensalism, or mutualism. Predation is well understood: lions eat antelope; antelope eat grass. Commensalism usually implies some sort of scavenging – lions and antelope are uninterested (though not ultimately disinterested) in what the grass does with their dung, their urine and their exhaled CO2. Mutualism implies a symmetry of dependencies giving benefit to both partners: the pistol shrimp digs a burrow in which it then lives with a goby fish; the shrimp is nearly blind and the fish warns it of danger.

This variety of dependencies prompts a choice in the design of an artificial reproducer: Which type of dependencies should our artificial reproducer exploit, and with which natural species? Beneficial options to people might include predation upon pests, commensal gathering of waste, or mutualism with a species whose welfare we wished to promote (such as an endangered or an agricultural one).

However, clearly the most interesting natural species with which our proposed artificial reproducer might exhibit a dependency is ourselves. This makes the choice more sharply cut: it would be foolhardy to make ourselves the prey for our artificial reproducer; having it collect our waste commensally might be useful, but the option most pleasing to our evolved senses of morality and symmetry would be to make ourselves a reproducing mutualist. In other words, we should make an artificial reproducer that would benefit from us, and we from it.

The most famous mutualism in nature, and the one that we all learn about first at school, is a reward for a service. Butler said of this in Erewhon:

Does any one say that the red clover has no reproductive system
because the humble bee (and the humble bee only) must aid and
abet it before it can reproduce? No one. The humble bee is a part
of the reproductive system of the clover.

Moreover, he might have added, the bee is rewarded with nectar.

Mutualism between the flowers and the insects evolved about 140 mya in the late Jurassic period and is one of the most enduring phenomena in biology. For both sets of species it is an evolutionarily stable strategy corresponding to a particularly unshakable Nash equilibrium.

What service could our mutualist reproducer ask from us? Moreover, with what could it reward us? It would seem sensible to play to the differing strengths of artificial kinematic machines and people. Artificial kinematic machines can make objects accurately, repeatably and tirelessly. In contrast, they fumble at manipulative tasks that would not tax a small child. People are exquisitely dexterous. (Aristotle called the human hand, the instrument of instruments.) But – though with practice people may carve and mould beautifully – they cannot do so accurately, repeatably and tirelessly.

So our self-reproducing kinematic machine could be designed to manufacture a kit of parts for a copy of itself, and to need the assistance of people to assemble that copy (that is, it would be an assisted reproducer along the lines of NASA’s unit-reproducer). The people would be the humble bee, and the kinematic machine the clover. And what about the nectar?

If the kinematic machine were sufficiently versatile to make its own parts, then chances are that it would also be able to make many other items useful to people. When it was not reproducing itself, it would be rewarding its assistants with a supply of consumer goods. This idea of a self-reproducing machine also making useful things for people is not new. It goes back through von Neumann to Butler. But we contend that regarding this as a form of biological mutualism and deliberately seeking to achieve that in order to position both reproducers at an evolutionary Nash equilibrium for each is a novel idea.

This was the genesis of the RepRap machine. It was designed to make its own parts to be assembled by people into another RepRap. The people would be driven to do this by the fact that the machine, when not reproducing, could make them all manner of useful products. It seemed (and still seems) likely that this would lead to a mutualist relationship between people and the machine that would inherit some of the longevity and the robustness of the evolutionarily stable strategies of the insects and the flowering plants.

Finally in this section, we note that flowers do not attempt some biological equivalent of copyrighting or patenting the “intellectual property” of their genomes. Such a genome builds the flower with the sole intent† of spreading itself with the most promiscuous fecundity possible. Any genome mutation that arose that – for example – attempted to extract some payment (like the nectar) in return for a copy of itself would clearly have a lower reproductive fitness. The nectar and the information are not in any way equivalent. The nectar is a real material resource. In contrast, the immaterial genome information has been arranged purely because of its success in copying itself as freely as it can, and any impediment placed in the way of that would be to its detriment. For this reason, it was decided to follow the principles of the free software movement and to distribute every piece of information required to build RepRap under a software libre licence that requires no royalty payments whatsoever. This would allow private individuals to own the machine, and to use it freely to make copies for their friends.

The RepRap machine is intended to evolve by artificial rather than natural selection; that is, to evolve as the Labrador has evolved from the wolf, rather than as the wolf has evolved from its ancestors. It is hoped that this evolution will come about by RepRap users posting design improvements on-line that may be adopted in future designs of the machine and then in turn downloaded by old and new users. That is why the General Public Licence was chosen as the RepRap licence, as that obliges people who improve the machine to make public their improvements under a similar free licence.

(— end of quote —)

Limits of RepRap & Future

In its current form (2020) RepRap is a principle which allows a low entry in regards of complexity, cost and availability to 3D printing. Many pieces, which cannot be printed yet, need to be machined separately, e.g. with programmable CNC machines, like the hotend: heatsink, heating block, the nozzle; those pieces need to withstand the heat which is needed to melt the plastics which RepRap’s currently use to create a piece – the machine itself cannot be fully plastic, as it needs to bring the plastic in a formable or molten state to position and deposit it in space.

A future RepRap might function differently, e.g. programmable self-organizing machine which positions molecules which form a bacteria, which create nano bots and nano motors, which boot strap an assembly and create a machine again, one which can arrange molecules – there it will not be the issue of molten plastic, but the separation of what the machine is and what the in-progress machine would be; if that separation would not be regarded, such a future RepRap would blend into the 2nd machine while it would make it, and it would evolve without generating a child, it would morph into a new machine instead. Right now (2020) RepRap’s are not in danger to morph into themselves, as the pieces are plastic, and many non-printable pieces limit the completeness of self-replication.

Yet, on one occasion it happened when I was printing pieces on an Ashtar K #1 (Prusa i3) for another “Ashtar K #2” printer – quasi the child – and due some mechanical mishaps the piece was printed too close to the bed fasteners, which were printed in PLA – so they fused in that moment (failed print) – in that moment it also became clear to me, that the separation of what the machine is and what the piece it produces is, is essential. I had to break the newly printed piece apart, but it damaged the bed fastener with the hot nozzle . . . and as the morphing or fusion was so good, it no longer was clear were the bed fastener (parent) and the new piece (child) began.

So, if a RepRap comes close to create nearly 100% replicate of itself, it requires a marker and safeguards to distinguish the parent from the child in-progress to be produced, and ensure it does not morph or blend into each other.

Needless to say, self-replicating machines is reinventing life from the gross technological level downward, whereas physical life emerges from the entire stack of sub-atomic, atomic, molecular, DNA, cell, organ, body-level to planet-sized ecosystem with many species.

Thanks to Scott Crump, Adrian Bowyer, Vik Olliver, Josef Prusa, Shenzen Getech Technology, Zhuhai CTC Electronic Ltd and Marius Kintel (OpenSCAD) to provide the base for my 3D printing adventure . . .


Continue with 3D Printer History or RepRap Blog Archive.

3D Printer Ashtar D: Classic XY, First Draft

After the Core XY implementation of Ashtar C I pondered on changing the kinematic to a more classic approach to separate X and Y axis motors, but otherwise keep the setup and frame, hence Ashtar D:

Ashtar D: classic independent XY kinematic: head XY, bed Z setup, with 500mm 2020 alu profiles


Again using 500mm alu profiles, utilizing the frame itself as rails:

  • 1 V-slot beam for X axis with V-carriage/module (triangle shaped carriage) as X carriage with hotend
  • 2 V-slot beams for Y axis, 2 V-carriages/modules with the X beams on it
    • using classic V wheels
  • 14 T-slot beams for the rest of the frame
    • Z bed: white 7.3mm thick Delrin wheels on T-slots

The target is again a 400x400mm printbed, probably 380x400x380mm build volume alike with Ashtar C (Core XY), perhaps a bit less X-wise due the more complex pieces to mount the X motor and pulleys.

More high resolution renderings:

The project page on Ashtar D summarizes the current state of the project.

3D Printer Ashtar D (Draft)

Status: just a draft

Ashtar D (Classic XY)


  • 2021/01/14: very experimental IDEX upgrade option added
  • 2021/01/08: starting with details of Y belt/pulley (non-)printable parts
  • 2020/12/28: beautifying X & Y motor and pulley mounts with rcube(), rcylinder() and chainhull()
  • 2020/12/25: starting with some basic parametric enclosure, refining some details
  • 2020/12/24: X & Y motor mounts as well X & Y pulley mounts done
  • 2020/12/23: starting with Ashtar C frame and transforming it to classic X/Y head, X/Y motor mounts and pulleys mounts missing


After the Core XY of Ashtar C I thought to convert it to a more classic kinematic X/Y head with two dedicated NEMA17 motors for each axis – independent XY. Mostly using the same frame setup with 500mm alu extrusions, same V-carriages/modules as before, but reposition both motors to dedicate for X and Y axis now. The main goal is to achieve 400x400mm print area with 500mm alu extrusions.

Ashtar D (Classic XY)

  • X motor & Y motor
  • no XY frame tension
  • shorter belts
  • one moving motor (Y-wise)

Ashtar C (Core XY)

  • Core XY with motor A & B
  • XY frame tension
  • long belts
  • no moving motors


After the rough design was OK, with X = 0 .. max and Y = 0 .. max and maintaining max of printable area, I went ahead and did basic Y motor mount and X motor mount, and I was designing the pieces in OpenSCAD, the ad_[xy]mount(type="motor" or "pulley") and I changed the 42×42 interface for NEMA17 to pulley holder which made it quite a fast design – so motor-side and pulley-side are very similar made with the same OpenSCAD module:

Y Motor Mount

At Y = max + Y margin (beyond print bed, but not yet touching anything else):

X Motor Mount

Exploring the X & Y minimum, how X carriage can as close as possible with the part cooler attached:

X & Y Motors / Axis


  • Build Volume: ~380 x 400 x 380mm (not yet finalized)
  • Frame: 17x 500mm 2020 alu profiles
    • 14x 500mm 2020 T-slot alu profiles
    • 3x 500mm 2020 V-slot alu profiles

Issues to Resolve

  • mounting X motor, resolved
    • mounting X pulleys, done
  • mounting Y motor, resolved
    • mounting Y pulleys, done
    • using M6 or M5 smooth or threaded rod to extend Y motor shaft
  • Y belt mount to carriage, done
  • positioning: extruders, controller, power-supply (like Ashtar C)
  • positioning: X, Y and Z end-switches
  • tuning toward 400x400x400mm build volume with 500mm 2020 alu profiles
  • build printer
  • print tests
  • release parts
  • release code


Classic XY vs Core XY

Compared to Ashtar C Core XY the Ashtar D is less elegant, more complex parts but better setup using the rather thin 2020 alu profiles for such a big build volume.

Sharp vs Rounded Edges

The round edges are achieved by replacing cube([x,y,z]) with rcube([x,y,z],r) and in conjunction with chainhull() { } the round edges propagate. Actual prints will show if any drawbacks appear, e.g. it introduces some small overhangs, but they might be disregarded at small radiuses/radii.

Toward Elegance

IDEX Option

In order to provide Dual Independent Extrusion (IDEX) a 2nd belt and motor is required, yet, the Y carriage is quite delicate in this current setup but after some pondering I think I came up with an elegant solution: the main idea is to utilize the NEMA 17 shaft as axis for 2nd belt idler:

and then rotate the same Y carriage on the other side:

Since the entire Ashtar D design is still just a draft, this IDEX setup is also very experimental in nature and only actual build will tell if it’s feasible.


Z Axis & Motors

It has been tested successfully with Ashtar C, so I use the same setup again:

Ashtar C/D: Z Axis / Motor


Printable Parts

  • 1x ad_xmount-type=motor
  • 1x ad_xmount-type=pulley
  • 1x ad_ymount-type=motor
  • 1x ad_ymount-type=pulley
  • 1x ad_ypulley-left
  • 1x ad_ypulley-right

Note: the new parts aren’t released yet until I used them in a test setup.

Non-Printable Parts

  • 2x 625ZZ bearings ID=5mm
    • 2x for 1x ad_ymount-type=pulley
  • 12x 629ZZ bearings ID=6mm
    • 8x for 4x Z thread holder (2x bottom)
    • 4x for 4x Z thread holder (top)
  • nx pulleys (dimension not yet determined)
    • 2x (5mm hole) for 2x Z motors
    • 1x (5mm hole) for 1x X motor
    • 2x (5mm hole) for 1x Y motor, 1x ad_ymount-type=pulley
    • 4x (6mm hole) for Z threaded rods
  • nx idlers (with 3 or 5mm hole)
    • 2x (3mm hole) for 1x ad_ypulley-left, 1x ad_ypulley-right
  • ~520 mm M5 smooth or threaded rod (Y shaft extension)


Developing some enclosure, either attach to the Z beams – as one side is free to fasten pieces and use acrylic sheets – or enclose entire frame, like with

or doing my own approach, something like this:

With the enclosure the display must be reachable, and therefore likely be on the front and longer wires from the controller board, which most likely resides on the back right side as with Ashtar C.

Ashtar D (Classic XY)

  • Build Volume: 380 x 400 x 380mm (57.7Kcm3 / 57.7L) = 100%
  • Device Dimension: 590 x 650 x 620mm (237Kcm3 / 237L)
  • Build vs Device Volume: 4.11

Creality CR5

  • Build Volume: 300 x 225 x 380mm (25.6Kcm3 / 25.6L) = 44%
  • Device Dimension: 530 x 487 x 621mm (160Kcm3 / 160L)
  • Build vs Device Volume: 6.25

Ultimaker S5

  • Build Volume: 320 x 240 x 300mm (23.0Kcm3 / 23L) = 40%
  • Device Dimension: 495 x 585 x 780mm (225Kcm3 / 225L)
  • Build vs Device Volume: 9.78

Creality Ender 6

  • Build Volume: 250 x 250 x 400mm (25.0kcm3 / 25L) = 43%
  • Device Dimension: 495 x 495 x 650mm (159Kcm3 / 159L)
  • Build vs Device Volume: 6.36

Ashtar D and Ultimaker S5 device volumes are nearly the same, 237Kcm3 vs 225Kcm3, but Ashtar D would print more than the double of the volume – so it would be volume-wise more efficient. Creality CR5 and Creality Ender 6 are more volume efficient than the Ultimaker S5, but not as good Ashtar D. Let’s see if I can keep this advantage for the final implementation.


  • Ultimaker S5: different XY head design using smooth rods, head: XY, bed: Z, build volume: 330 x 240 x 300mm, swapable hotends/printcores; priced at EUR/USD 6,500+ (2020/12)
  • Makerbot Replicator: head: XY, bed: Z, build volume: 295 x 195 x 165mm, priced EUR/USD 2,400 (2020/12)
  • Creality CR5: blatant copy of Ultimaker 2, S3 & S5 case design, head: XY, bed: Z, build volume: 300 x 225 x 380mm, priced EUR/USD 1,500 (2020/12)
  • Creality Ender 6: low cost Core XY, head: XY, bed: Z, build volume: 250 x 250 x 400mm, priced EUR/USD 500 (2020/12)

3D Printer Ashtar B: Cantilever, First Draft

It has been on my mind for quite a while to do a 2020 alu extrusion based Cantilever 3D printer, and so I started in December 2020 with a rough design, starting from the existing Ashtar K design and cut away parts:

  • using Head XZ and Bed Y
  • aiming common build volume (e.g. easy to source print bed)
    • 140mm to 190mm each axis
  • tried 6, 7 and 9 beams options, settling with 6 beams for now
  • aiming for uni-length 2020 alu extrusions, T-slot and V-slot where a carriage rides (X & Z axis) with V wheels.
  • trying to keep as simple as possible

Frame: 6 vs 7 vs 9 beams

The 9 beams give an overall better sturdiness, but not sure how essential at small building volume (less than 220mm each axis). I might be able to remove beam, the last beam at the back at the bottom reducing to only 6 beams, in that case the Y motor is mounted on the remaining beam in the back.

Z Carriage: 3 vs 4 wheels module

The 4 wheels looks best but it also sacrifices some of the X range by apprx. 10mm, the obvious choice is 3-wide mount – actual tests will tell if the X & Z axis are solid enough.

Different Sizes

The 200mm build axis length would be good, but I’m not sure if the XZ carriage will allow it as the max margin or tolerance would be half of a layer-height, e.g. 1mm layer height ⇒ 0.05mm tolerance, at X = 0 .. max the head should not flex more than 0.05mm. At this this early draft stage I don’t know which size is most suitable, I focus on 180mm build axis.

The project page on Ashtar B summarizes the current state.

3D Printer Ashtar M: Moving XZ Frame (Moving Gantry), First Draft


  • 2020/12/20: adding XZ arch option
  • 2020/12/14: initial post
Jon Schone: Moving Portal Mod

In April 2020 Jon Schone (@properprinting) showed a “Moving Portal” mod for his CR-10 – a Prusa i3 derivative – and I thought to adapt his approach as “Ashtar M” as moving XZ frame or moving gantry in CNC terms.

On a second thought, this approach makes only sense with larger beds, as the bed weight should exceed the weight of XZ frame and X carriage:

weight(XZ frame + X carriage) < weight(bed)

and as I compose my Ashtar 3D printer series with alu extrusions (beams) I can say:

weight(XZ frame) = beam X * 2 + beam Z * 2 + NEMA17 * 2
weight(bed) = X * Y

and it becomes here clear, the bed weight grows X * Y whereas XZ frame only (X + Z) * 2, but also 2* NEMA17 motors of the Z axis are part of the XZ frame.

Moving Portal / Gantry

A few still images of Jon’s YT video to look at some details of his approach:

First Draft

  • using solely 500mm 2020 alu extrusions (T-slot for general frame and XZ frame, V-slot for carriages: X beam, 2x Y beams)
  • trying to achieve 400x400x400mm build volume as close as possible, alike Ashtar C 38.40.36

Using for Y carriages existing vcarriage2 module with vcarriage2(width=100) to have it wide enough:

The two main new pieces required were connecting the Y carriage with the XZ frame:

  • Piece “A” outside ycarriage_xzframe_mount_a(): has to be printed with 0.1mm layer height in order to stay within the +/- 0.05mm tolerance, otherwise it will introduce tilt and stress on the Y carriage and cause long term damage – tricky part to print.
Adding side pieces “A” & “B”
  • Piece “B” inside ycarriage_xzframe_mount_b(): is quite elaborate already and should be functional, with the Y belt ends fastening with M3 screws and M3 nuts inserts, the belt endings will come out downward:

XZ Arch Option – Removing Lower X Beam

In order to gain some Z build space by lowering the print bed, I may reduce the XZ frame to an XZ arch:

Actual physical tests may reveal if it’s suitable to maintain overall geometrical integrity. Removing the lower X beam also reduces moving mass of the XZ arch/frame/gantry.


  • gain Z build space
  • reduce XZ gantry weight / inertia


  • decrease XZ gantry stability

Further Development

As I develop Ashtar M further, I will post updates on the blog here, and also keep documenting the current state at Ashtar M page.

That’s it.

3D Printer Ashtar M (Draft)

Status: just a draft

Ashtar M (Prusa i3 MG)
Ashtar M IDEX – Draft


  • 2021/01/14: Option IDEX (Independent Dual Extrusion), early draft (not yet tested)
  • 2021/01/07: Y motor and shaft extension with Y pulley holder added
  • 2021/01/03: Z motor mounts added, Y carriage to XZ frame/arch pieces refined using rcube()
  • 2020/12/19: new “XZ Arch” option (removing lower X beam from XZ frame)
  • 2020/12/17: change X carriage, routing X belt inside 2020 alu extrusion
  • 2020/12/12: first drafts, just a skeleton, details still to be worked out


Jon Schone (@properprinting) did a “Moving Portal” (MP) mod for his CR-10 in April 2020, and I thought to adapt his approach as “Ashtar M” as Moving Gantry (MG) using CNC terminology.

Instead to move the bed in Y axis to move the entire XZ frame or gantry – the rest of the Prusa i3 style printer remains the same.

Reducing Moving Weight

Ashtar M with Moving XZ frame using modular & parametric V-carriage

This variant only makes sense when the weight of the bed exceeds the weight of the XZ frame + X carriage, in order to reduce the moving weight as of inertia – so only for large(r) build volume this makes sense:

weight(XZ frame + X carriage) < weight(bed)

and as I compose my Ashtar 3D printer series with alu extrusions (beams) I can say:

weight(XZ frame) = beam X * 2 + beam Z * 2 + NEMA17 * 2
weight(bed) = X * Y

and it becomes here clear, the bed weight grows X * Y whereas XZ frame only (X + Z) * 2, but also 2* NEMA17 motors of the Z axis are part of the XZ frame.

The main differences of Ashtar M and Ashtar K:

Ashtar M (Prusa i3 MG)

  • static bed
  • 2x Y belts
  • 1x Y motor
  • 2x Y beams: V-slot 2020 alu
  • Y axis: 2x V carriages (each 3 wheels)
  • XZ frame is moving (do not add anything more)

Ashtar K (Prusa i3)

  • movable bed with simple sliders
  • 1x Y belt
  • 1x Y motor
  • 2x Y beams: T-slot 2020 alu
  • XZ frame is static (can hold filament, extruders etc)


For now I decided to use my V modules as Y carriages with width of 100mm vcarriage2(width=100) but actual tests are required how stable the moving XZ frame will be.

As you can see on the draft, I lose some build volume because I stack on top of the Y carriage instead within, but if I put the gantry / XZ frame between the Y carriage I need extra long X beams for the outer frame, and make it impossible to achieve uni-length design (same beam length for all); it’s all about balancing a compromise.

XZ Arch Option

The “XZ Arch” option is removing the lower X beam from the XZ frame, hence, extends Z build space as the print bed also goes lower – for now I moved the Y beams supporting the print bed on the lower framework, details how the print bed will be mounted not yet determined. The side piece “A” is a bit shorter, and side piece “B” is a bit more solid – the way the Y belt is fastened remains the same: Y belt ends come out downward, and are fastened with M3 screws & M3 nuts inserts.


  • Build Volume: ~380x400x380mm
  • Frame: 10x 500mm 2020 alu profiles (XZ arch option)
    • 3x or 5x V-Slot 2020 (X, Y and optional Z axis)
    • 7x or 5x T-Slot 2020

Issues to Resolve

  • Y motor & Y pulley holder, likely using 6mm smooth or threaded rod as extender, resolved, details defined with 625ZZ bearings
  • print bed mounting with adjusting nobs to level bed
    • optional remove lower beam of the XZ frame and make it just a gantry, would allow to lower supporting bed beams (space for springs and nobs etc) – but might introduce weaker XZ gantry geometry
  • Y Carriage to XZ Frame mount: either combine the L shape of XZ frame, or have a separate piece to attach – that part likely is the most challenging to get right, using two pieces “A” and “B” to connect to XZ frame with Y carriage
    • resolved in theory, but in actual implementation it will be tricky, as the piece “A” aka ycarriage_xzframe_mount_a() will be printed flat, and quantized by layer height, but the thickness has to be very precise as +/- 0.05mm not to introduce any tilt on the Y carriage (it would damage the V module and/or V wheels and introduce wobble Y-wise), hence 0.1mm layer height required for piece ycarriage_xzframe_mount_a() mounted outside, and ycarriage_xzframe_mount_b() (◤-like piece) mounted inside:
  • Z motor mounts, resolved: how stable it is needs to be tested
  • cabels & bowden tube routing
    • XZ frame moves as well – lot of motion involved – likely not put bowden extruder motor on it and avoid to add additional weight again
    • cable chain to ensure it bends in a controlled manner
  • positioning: controller, display, power-supply, optional: filament holder
    • none of them can be put on the moving XZ frame anymore
  • tuning to common to build-volume with uni-length beams
    • likely 400x400mm build plate achievable, but perhaps 380×400 printable, losing 10-15mm on left- and right-hand side.
  • XZ frame vs XZ arch: to be determined if it’s essential with actual tests
  • build printer
  • print tests
  • release parts
  • release code


Ashtar K & M bed mounting

The bed is stationary, so it’s relatively simple, a bed carriage it still required so the fine level adjustment is possible with some knobs – using the same setup as for Ashtar K.



Printable Parts

  • Y carriage:
    • 2x am_v_plate-2020-double-v-244-110-100w-a
    • 2x am_v_plate-2020-double-v-244-110-100w-b
    • 2x am_zmotor_mount
    • 2x am_ycarriage_xzframe_mount_a
    • 2x am_ycarriage_xzframe_mount_b
  • 1x am_ypulley_holder
  • 1x am_ymotor_mount or 2020_Y_motor_mount
  • 4x am_foot_hh

Non-Printable Parts

  • 2x 625ZZ bearings
    • 2x for 1x am_pulley_holder
  • nx pulleys (dimension not yet determined)
    • 2x (5mm hole) for 1x Y motor, 1x am_ypulley_holder
    • 1x (5mm hole) for 1x X motor
  • nx idlers (with 3 or 5mm hole)
    • 1x (3mm hole) for 1x X belt
    • 2x (3mm hole) for 2x Y belts
  • ~490-500 mm M5 smooth or threaded rod (Y shaft extension)

See the on-going blog-posts on Ashtar M development, with some more details than the overall page here.

IDEX Option

As Ashtar M shares much of Ashtar K design, the IDEX option comes easily – yet, adding a 2nd motor on the moveable XZ frame/gantry definitely pushes the limits of Ashtar M, significant forces will be applied at high Z positions while moving Y axis.

In order to run two independent printheads (Independent Dual Extrusion) following changes are needed:


  • 1 x xcarriage_short_hmount_motor_2020-endstop-idex-left
  • 1 x xcarriage_short_hmount_motor_2020-idex-right
  • 1 x xcarriage_beltmount_2020-idex
  • 1 x pulley_holder


  • 1x Nema 17 42-45Nm (39-40mm height) with 1m wires
  • belt ~110cm GT2 6mm
  • 1 x pulley
  • 1 x idler

As soon I tested this option I will document it in more details, like electronics, changes in firmware, slicer settings etc.


3D Printer Ashtar B (Draft)

Status: just a draft

Ashtar B (Cantilever)


  • 2020/12/23: added more details on Y bed, and size comparison, blog post published.
  • 2020/12/17: X motor mount done, X belt pulley holder, XZ cantilever x-offset 10mm.
  • 2020/12/12: just the basic idea, an early draft with a few options (extra foot, 3/4 wheels for Z carriage), 6 vs 7 vs 9 beams.


Ashtar K was the first design with 2020 T-slot alu extrusions, and I used 11 beams of 500mm length to make up the entire frame. In the back of my mind I thought also doing a Cantilever 3D printer with 2020 T- or V-slot, like the Prusa Mini or Printrbot Simple Metal, and as before I like to reuse the frame as rails directly and not use any smooth rods or alike, which means X beam as V-slot, and optionally Z beam as well as V-slot, Ashtar B:


A build-volume of 140mm to 190mm each axis is targeted in order to keep the X axis short – also, likely using a Bowden extruder setup where just a hotend resides on the X carriage.


  • Build Volume: ~180x180x180mm
  • Frame: 6x 340mm 2020 alu profiles
    • 2x V-Slot (X and Z axis)
    • 4x T-Slot (Y axis with simple sliders where T-Slot are sufficient)

Issues to Resolve

  • X belt routing: outside of 2020 extrusion or inside
  • X motor mount: rather simple, perhaps combine with xcarriage_short_hmount_2020(), done
  • Y motor mount position: will determine overall build volume
  • Y bed slider: perhaps like Ashtar K final version
  • testing overall stability: 6, 7 or 9 beams
  • 3 vs 4 wheels on Z carriage, 4 wheels (see below why)
  • positioning: extruder, controller, display, power supply, optional filament holder
  • positions of X, Y and Z endswitches
  • tune to a common build volume while having uni-length beams/extrusions
    • 150mm, 200mm, 215mm for X & Y build axis length

Frame: 6 vs 7 vs 9 beams

The 9 beams give an overall better sturdiness, but not sure how essential at small building volume (less than 220mm each axis). I might be able to remove beam, the last beam at the back at the bottom reducing to only 6 beams, in that case the Y motor is mounted on the remaining beam in the back.

Z Carriage: 3 vs 4 wheels module

The 4 wheels looks better also because it allows to add another 2020 horizontal mount or wider mount, some X range is sacrificed (10-20mm).

Different Sizes

The build volume from 150mm to 200mm for each axis, I like to have 200mm but not sure if the X axis can maintain linearity fully (e.g. half of a layer-height such as 0.1mm ⇒ 0.05mm linearity for head X = 0 .. max), I might to have to settle for 180mm or even 150mm. Actual tests and fine tuning of the Z axis (4 wheels V carriage) and X axis (3 wheels V carriage) will tell.


Build Axis: 150mm (83%)
Area: 225cm2 (69%)
Volume: 3.4Kcm3 (58%)

Build Axis: 180mm (100%)
Area: 324cm2 (100%)
Volume: 5.8Kcm3 (100%)

Build Axis: 200mm (111%)
Area: 400cm2 (123%)
Volume: 8Kcm3 (137%)

IdeaFormer Magnetic Sticker
(Aliexpress, 2020/12)

Common quadratic bed-sizes are 150mm, 200mm, 214mm, 220mm and 235mm e.g. for magnetic beds. A 200mm bed can be used but only 180mm be printed, as I have sufficient margin on the XZ cantilever side.

Y Bed

I gonna use the simple slider riding on T-slot (derived from an existing nylon slider) for the Y bed, 3 sliders in total:

The sliders are glued beneath the Y carriage, then the Y bed snaps into the T-slots easily. I have printed on these sliders with two Ashtar K‘s (K1 = 380×400, K2 = 300×300) for about 1+ years successful. This simple approach requires gravity, and the bed needs its own weight to stay in place (cannot be up-side-down or in no-gravity environment like International Space Station ISS).

Back & Bottom View

Ashtar B (back view)

Ashtar B (bottom view)


RepRap.org Blog Archive

A History of RepRap Development (2012) [PDF]

A treasure of knowledge as posted on blog.reprap.org was collected by Gary Hogdson, which I host here as well for archival purposes:

Early research for

  • extruders, nozzels, heating blocks
  • printing material research ABS, PLA and other materials
  • slicing algorithms
  • deciding to use Arduino as motor controller

Notable Excerpts

RepRap Family Growth

Adrian Bowyer summarizes RepRap history April 18, 2011, in brackets the amount of RepRaps:

  • Spring 2007 – The first RepRap Darwin was finished. Its RP parts were made in a Stratasys Dimension. [1]
  • During that summer we made four or five sets of parts for the machine in the
    Stratasys and sent them to RepRap team members round the world.
  • September 30, 2007 – Vik Olliver in New Zealand finished the second Darwin. [3]
  • Around Christmas 2007 – A number of people start to make wooden and lasercut copies of Darwin. The Bath RepRap Lab also supplied a Stratasys-printed set of Darwin parts to Ian Adkins of Bits from Bytes, who created silicone moulds from them and started selling Darwin copies made by PU moulding. [8]
  • February 21, 2008 – Zach Smith (now also of MakerBot) gets his Darwin working. [20]
  • February 22, 2008 – Ponoko have a lasercut version of Darwin.
    Spring 2008 – Lots of the wooden and moulded Darwin-type Repstraps are working, and people start using them to print RepRaps.
  • April 2008 – Nophead starts printing Darwin parts on his Repstrap Hydraraptor. [60]
  • May 29, 2008 – Vik Olliver’s Darwin has made a full set of parts for another
    Darwin; these are assembled in New Zealand and finally tested when he visits at Bath University in the UK. This is the first true RepRap replication. [100]
  • Summer 2009 – RepRap Mendel introduced. [400]
    Around this time Nophead, I, and many others went into serious production
    selling reprapped sets of parts for RepRaps made in RepRap machines on Ebay etc. Summer 2010 [1500]
  • Spring 2011 – Nophead alone has made over 100 RepRaps for other people. I have made over 50. [4000]

Prusa Mendel Announcement

October 4, 2010 Josef Prusa announced his Prusa Mendel version with this post:

He eventually iterated to Prusa i3 May 2012, which became quasi standard for low-cost FDM 3D printers.

See also 3D Printer History.

3D Printing: Ashtar C Printer: 1st Prints

Back in September 2018 I started to code the first parts for Ashtar C, a “Core XY” type 3d printer – finally, after several weeks waiting for the several parts (bearings, closed loop belts), I was able to finalize the bed and Z axis (2018/01/30) and perform the first test prints of Ashtar C #1 composed with 500mm 2020 T-slot and V-slot alu extrusions:


  • CoreXY style
  • Build Volume: 380 x 400 x 380mm
  • Frame Size: ~500 x 500 x 500mm


  • 400 x 400mm black bed sticker (~0.7mm thick)
  • 400 x 400 x 4mm mirror (custom order)
  • 4x bed corner mounts (printed), with M3 x 30 and spring and 4x washers each
  • 420 x 420 x 4mm OSB

residing on 2020 T-slot alu extrusions.

Z Axis

  • 1524mm GT2 closed belt: even though driving 4 threaded rods worked somehow, but not reliably therefore:
    • Option A
      • 2x Nema17 (45Nm) stepper motor with 18 teeth GT2 pulley 5mm bore
      • 2x 760mm closed beltbelt-routing-z-axis
    • Option B
      • Using 3 or higher : 1 gear box (e.g. 3:1 gearbox could be used, but external shaft isn’t strong enough stabilized versus tilt) or alike to increase torque and still drive 4 threaded rods
  • 4x M6 x 490mm threaded rods
  • 4x M6 nuts with bed mounts (printed)
  • 4x bottom Z rod mount (printed)
  • 8x 606ZZ bearings (each rod has 2 bearings)
  • 4x 18 teeth GT2 pulley 6mm bore




Following challenges came up in the first test prints:

  • CoreXY principle works well, yet, the friction of each idler really matters as it increases risk of missing steps, well greased and well positioning mandatory
  • X endstop: right now positioned on the left hand side of the X beam, but the cable hangs down – likely need to reposition X endstop on the X carriage itself
  • the Bowden tube is long and so hangs to the bed, the tube (4mm OD, 2mm ID) isn’t stiff enough to bend upward, so requires some guidance to ensure it doesn’t ride on the bed surface and entangles with print process
  • E3D V6 clone this time really does not perform well: extrusion is not even, and missing steps of the extruder; requires further investigation.
    • thermistor seems off, increasing to “220C” print temperature, gave better and cleaner prints


That’s it for the moment.

3D Printing: Ashtar C Printer: CoreXY Belt Routing

After some delay of parts, I finally was able to finalize the belt routing and configure the firmware for Ashtar C #1:

Belt Routing


CoreXY belt routing of Ashtar C

Early on I decided to separate belts of motors A and B in the Z axis, so they would not cross as such, and also hoped one axis of the carriage holding the X beam would allow some idlers to redirect the belts – to save space and keep frame dimension and build (or printable space) dimension close.

The Bowden tube and the wires of the hotend are preliminary arranged:



To configure the Marlin firmware turned out not that simple, as CoreXY has its own interdependencies of A & B motors: first X axis was reversed, whereas Y axis worked correctly, the INVERT_X_DIR setting on Configuration.h of Marlin did not help, it reversed the stepper motor direction, but not the actual X axis direction. After many attempts to use COREYX instead of COREXY I ended up

  • swap cables of A & B stepper motors
  • keep #define COREXY
  • #define INVERT_X_DIR = true and #define INVERT_Y_DIR = true

and X and Y direction worked correctly.

Preflight (no extrusion, just X & Y axis movement testing):

The stepper drivers still need some tuning, as I saw or rather heard a few missed steps at fast movement.

X & Y Endstops

The preliminary positions of the endstop are:

  • X endstop resides on the X beam left-hand side (USE_XMIN_PLUG)
  • Y endstop resides on the right-hand backside, (USE_YMAX_PLUG and HOME_DIR_Y 1)

Z Axis

I postponed the actual details of the Z axis, as my main concern of the design was to have a good CoreXY setup and then see how I would achieve the Z axis.

In order to use 625ZZ bearings I started to use them as idlers directly (after cleaning the grease off their surfaces) and also use them to increase contact surface when driving a closed belt which drives 3 or 4 threaded rods M6 x 500mm:


Since the surface of the threaded rods is rough, I realized I need dedicated bearings to hold the rods at the bottom, otherwise the friction would wear on the mounts and increase its diameter. So, the Z axis isn’t finalized yet, but close.