Category Archives: Technology

3D Printer: Ashtar K History 2018-2020

by Rene K. Mueller · published January 5, 2021 Technology Ashtar K, Ashtar K 3D Printer, History, OpenSCAD

A brief history of “Ashtar K“, my first designed 3D printer I actually built – documented also for my own sake:

AluX: Prusa i3 Clone

It started with AluX (abbreviation of ALU-extrusion eXtendable) early June 2018, which used CTC i3 Pro B / Prusa i3 Clone pieces as the X carriage, X motor mount and X idler all in STL format. I coded the frame parametric using 2040 alu extrusions/profiles and using smooth rods as rails:

I realized then quickly I need to design and code my own pieces, every single piece I need to control and make it parametric if it makes sense, and not rely on existing STL files, as editing meshes of the STL seemed a waste of time but rather design the piece in OpenSCAD right away and derive new variants if necessary from the geometry itself.

Ashtar X & W Series: Riding on Smooth Rods

Mid June 2018, AluX became Ashtar X (abbreviated as AX), and Ashtar W were using 2040 alu extrusions but differently oriented at the base, still using smooth rods as rails:

At this point I got sufficient experience of the parametric approach and it was obvious to use the frame as rails.

Ashtar T Series: Riding Alu Profiles

Beginning of July 2018, with the Ashtar T series I began to use the frame as rails itself, utilizing 2040 alu extrusions, it also started with the parametric V module (due its shape) composed by 2x V-plates, using 3 wheels which ride on the alu extrusion:

With the parametric V modules the X, Y and Z frame beams became rails as well, simplifying the overall construction compared to earlier designs:

The dual Z motors still residing in the front for sake of accessibility, but then I realized I want them in the back and keep the front dedicated to the printhead.

Ashtar K Series: Riding Alu Profiles, Uni-Length Beams

Mid of July 2018 I started the Ashtar K series, I decided to use 2020 alu profiles and focused on the single length of alu profiles, uni-length so I could reuse the beams for other future designs and since all the designs were parametric, it was easy to attain to find an optimum of single length beams and a common build-plate or build-volume:

The 9 beams design turned out too weak when I actually built the printer, so I added two beams back on left and right, and lift up the 9 beam design.

Eventually I decided to use 500mm alu 2020 profiles to achieve ~380x300x360 build volume; Ashtar K #1 used 400×300 build-plate, and Ashtar K #2 300×300 build-plate. Ashtar K #1 was functional in August 2018, and since then became my working horses together with Ashtar K #2, reliably printing.

See more at Ashtar K project page of the current state.

Next Steps

After the Ashtar K I did the Ashtar C Core XY cubic frame also with 2020 alu profiles. Late 2020 I started to design Ashtar M, a derivative of Ashtar K but with a moving gantry and static bed, and Ashtar D with Classic XY alike Ashtar C; and also a draft of a parametric enclosure as well to be adaptable to all of my 3D printer designs.

That’s it.

3D Printing: Simple Compact Extruder with 625ZZ Bearing

by Rene K. Mueller · published January 1, 2021 Technology Bowden Extruder, Compact Extruder, Direct Drive Extruder, Extruder, OpenSCAD, Simple Compact Extruder

Updates:

2021/01/01: sufficiently tested, finally published
2018/12/20: starting with write-up

I used some aluminium MK8-based extruders but realized I required my own parametric extruder using 625ZZ bearing and I looked around and found Compact Bowden Extruder by Dominik Scholz which uses 608ZZ and adapted the overall design but coded it from scratch again in OpenSCAD with 625ZZ bearing for the Ashtar Series:

It’s “right handed” by default, but filament can go both directions. The handle is pushed from inside out with a spring, not so elegant, yet it saves space and filament does not have to go through the handle this way, which I prefer.

Bill of Materials (BOM)

M5x14 or M5x16: mounting bearing
2x M3x8: mounting base to stepper motor
2x M3x25: mounting handle and spring
M3 nut: insert into slot
M3 washer (or print it): hold spring
20-25mm long soft spring (ID 3.2-8mm) or alike
hubbed gear OD 11mm (MK8)
625ZZ bearing

Recommended further:

PTFE OD 4mm, ID 2mm
PC4-M6 straight fitting

Building

Software

compact_extruder() takes following parameters, in case you like to recreate the pieces:

type:
- "base": the base attached to the NEMA 17 stepper motor
- "handle": the push handle with the spring
- "indicator": small indicator to put on the axis of the stepper motor
mount:
- "none": (default) just attaches to NEMA 17 stepper motor
- "mount": simple mount (center)
- "2020": extends flat (lower left version)
btd: Bowden tube diameter (default: 0), if 4mm is used, then Bowden PTFE OD 4mm/ID 2mm tube can be inserted on both sides as guides for flexible filament close to the hobbed gear as shown below
m5 can be redefined, e.g. 14 then it sinks in

Hardware

I use PC4-M6 push fit connector with PTFE tube 4mm OD / 2mm ID as guides, and began to use it right away on 3x printers for first tests:

Assembled Simple Compact Extruder (M5x16)

Download

https://www.thingiverse.com/thing:3265864

includes STLs and OpenSCAD source code of the module

Applications

Compact Extruder on Ashtar K #1 in Bowden setup

Direct Drive Extruder

A small adapter allows to mount the Compact Extruder close to the printhead to use it as Direct Drive Extruder:

Compact Extruder in Direct Drive E3D V6 Setup

I did not test the Direct Drive approach as I prefer the Bowden setup on my printers, but have it ready when needed, e.g. for flexible filament.

References

Compact Bowden Extruder 608ZZ Bearing by Dominik Scholz, adapted his overall design but coded it from scratch
Compact Bowden Extruder 625ZZ Bearing by Jake D, uses 625ZZ but had no OpenSCAD source

RepRap Principle

by Rene K. Mueller · published December 28, 2020 Technology Adrian Bowyer, Chris Palmer, Edward Sells, History, Patrick Haufe, Pejman Iravani, RepRap, RepRap Genesis, Rhys Jones, Vik Olliver

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

Updates:

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

Introduction

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:

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:

RepRap – The Replicating Rapid Prototyper (PDF, 2010/10/27)
by Rhys Jones, Patrick Haufe, Edward Sells, Pejman Iravani, Vik Olliver, Chris Palmer (aka NopHead) and Adrian Bowyer

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:

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.

3D Printer History, an overview how it all happened, where RepRap history is part of it
RepRap.org Blog Archive, detailed research protocol

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.

V-module: 2x printed parts,
M3 & M5 screws & nuts, 3x nylon wheels

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 . . .

References

RepRap.org
RepRap – The Replicating Rapid Prototyper (PDF, 2010/10/27)
RepRap 10th Anniversary Interviews (2018) at 3D Printing Industry
- Interview with Adrian Bowyer (2018)
- Interview with Vik Olliver, the first RepRap volunteer (2018)
Self-Replicating Mechanisms/Machines: Penrose Block Replicators (1957)
Wikipedia: Nanorobotics

Continue with 3D Printer History or RepRap Blog Archive.

3D Modeling: Elegant Pieces in OpenSCAD with rcube(), rcylinder() and chainhull()

by Rene K. Mueller · published December 28, 2020 Art, Technology Chain Hull, OpenSCAD, Parametric CAD, Rounded Cube, Rounded Cylinder

Updates:

2020/12/31: rcube() extended, RCUBE_FLAT{BOTTOM, TOP, FRONT, BACK, LEFT, RIGHT} support added, rcylinder() with RCYLINDER_FLAT{TOP, BOTTOM}
2020/12/30: rcube() source code extended, support RCUBE_FLATX, RCUBE_FLATY, RCUBE_FLATZ
2020/12/28: inital post

While working on Ashtar D (Classic XY) I looked at some pieces I rushed to design with cube() and hull() and they didn’t appeal to me – yes, it kind of hurt my eyes.

A while back I coded a simple rcube([x,y,z],r) which takes r as a radius for the edges, internally it’s an OpenSCAD module which uses 8 spheres and hulls them together, providing round edges; but I hesitated to actually use it in my designs – until now. Further I thought, let’s do the same with cylinder() using rcylinder(d=10,h=5,r=1) providing round edges by using two torii and hull them together.

These two new functions, rcube([x,y,z],r) and rcylinder(h,d,r) allow to create more organic and elegant pieces, see for yourself:

From Bulky To Elegance

The position of the Y pulley mount is given, a bit of an X- & Y-offset to ensure printable area is not sacrificed for the Y carriage:

Using Chained Hulls

And another example . . . replacing hull() with chainhull():

The final version is composed by only 3 pieces chain hulled together:

difference() {
   chainhull() {
      rcylinder(...);
      translate([0,0,-20]) rcube(...);
      translate([...,-60]) rcube([5,20,50],2); // 2020 mount plate
   }
   rcube(...);     // pulley cutout
}

rcube() & rcylinder()

rcube();
translate([5,0,0]) rcube(0.75);
translate([10,0,0]) rcube([2,1,1],0.2);

translate([0,2,0]) rcube([2,1,1],0.2,false);
translate([5,2,0]) rcube([2,1,1],0.2,true);

translate([0,4,0]) rcube([2,1,1],0.2,RCUBE_FLATX);
translate([5,4,0]) rcube([2,1,1],0.2,RCUBE_FLATY);
translate([10,4,0]) rcube([2,1,1],0.2,RCUBE_FLATZ);

translate([0,6,0]) rcube([2,1,1],0.2,RCUBE_FLATBOTTOM);
translate([5,6,0]) rcube([2,1,1],0.2,RCUBE_FLATTOP);

translate([0,8,0]) rcube([2,1,1],0.2,RCUBE_FLATFRONT);
translate([5,8,0]) rcube([2,1,1],0.2,RCUBE_FLATBACK);

translate([0,10,0]) rcube([2,1,1],0.2,RCUBE_FLATLEFT);
translate([5,10,0]) rcube([2,1,1],0.2,RCUBE_FLATRIGHT);

translate([0+1,14,0]) rcylinder(3,1.5,0.2);
translate([3+1,14,0]) rcylinder(3,1.5,0.2,false);
translate([6+1,14,0]) rcylinder(3,1.5,0.2,RCYLINDER_FLATBOTTOM);
translate([9+1,14,0]) rcylinder(3,1.5,0.2,RCYLINDER_FLATTOP);

The library code (I might later release it as a separate library):

// Title: rcube(), rcylinder() & torus()
// Author: Rene K. Mueller
// License: MIT License 2020
// Version: 0.0.2

RCUBE_FLATX = [false,true,true];
RCUBE_FLATY = [true,false,true];
RCUBE_FLATZ = [true,true,false];
RCUBE_FLATBOTTOM = [false,false,false,false,true,true,true,true];
RCUBE_FLATTOP = [true,true,true,true,false,false,false,false];
RCUBE_FLATFRONT = [false,false,true,true,false,false,true,true];
RCUBE_FLATBACK = [true,true,false,false,true,true,false,false];
RCUBE_FLATLEFT = [false,true,true,false,false,true,true,false];
RCUBE_FLATRIGHT = [true,false,false,true,true,false,false,true];

module rcube(a=1,r=0.1,rd=[true,true,true],center=false,$fn=32) {
    if(FAST_RCUBE)
       cube(a);
    else {
       x = len(a) ? a[0] : a;
       y = len(a) ? a[1] : a;
       z = len(a) ? a[2] : a;
       rd = len(rd) ? rd : [rd,rd,rd];

          if((len(rd)==3 && rd[0] && rd[1] && rd[2]) || (len(a)==0 && rd)) // rd=[true,true,true] or true
             hull() {
                translate([r,r,r]) sphere(r);
                translate([x-r,r,r]) sphere(r);
                translate([x-r,y-r,r]) sphere(r);
                translate([r,y-r,r]) sphere(r);
                translate([r,r,z-r]) sphere(r);
                translate([x-r,r,z-r]) sphere(r);
                translate([x-r,y-r,z-r]) sphere(r);
                translate([r,y-r,z-r]) sphere(r);
             } 
          else                                                        // anything else
             hull() {
                translate([r,r,r]) rcube_prim(r,rd,0);
                translate([x-r,r,r]) rcube_prim(r,rd,1);
                translate([x-r,y-r,r]) rcube_prim(r,rd,2);
                translate([r,y-r,r]) rcube_prim(r,rd,3);
                translate([r,r,z-r]) rcube_prim(r,rd,4);
                translate([x-r,r,z-r]) rcube_prim(r,rd,5);
                translate([x-r,y-r,z-r]) rcube_prim(r,rd,6);
                translate([r,y-r,z-r]) rcube_prim(r,rd,7);
             }
    }
 } 

module rcube_prim(r,rd,i) {
    a = len(rd);
    if(a<=3) {
       if(a && rd[0] && rd[1] && rd[2]) 
          sphere(r);
       else if(a && rd[0] && rd[1])
          translate([0,0,-r]) cylinder(r=r,h=r*2);
       else if(a && rd[1] && rd[2])
          translate([-r,0,0]) rotate([0,90,0]) cylinder(r=r,h=r*2);
       else if(a && rd[0] && rd[2])
          translate([0,-r,0]) rotate([-90,0,0]) cylinder(r=r,h=r*2);
       else
          translate([-r,-r,-r]) cube(r*2);
    } else 
       if(rd[i]) 
          sphere(r);
       else 
          translate([-r,-r,-r]) cube(r*2);
 }

RCYLINDER_FLATBOTTOM = [false,true];
RCYLINDER_FLATTOP = [true,false];

module rcylinder(h=2,d=1,r=0.1,rd=[true,true],$fn=40) {
    if(FAST_RCYLINDER)
       cylinder(d=d,h=h);
    else
       hull() { 
          translate([0,0,r]) 
             if(len(rd) && rd[0]) torus(do=d,di=r*2); else translate([0,0,-r]) cylinder(d=d,h=r);          
          translate([0,0,h-r]) 
             if(len(rd) && rd[1]) torus(do=d,di=r*2); else cylinder(d=d,h=r);
       }
 }

 module torus(do=2,di=0.1,a=360) {
    rotate_extrude(convexity=10,angle=a) {
       translate([do/2-di/2,0,0]) circle(d=di,$fn=20);
    }
 }

chainhull()

module chainhull() {
    for(i=[0:1:$children-2])
       hull() {
          children(i);
          children(i+1);
       }
 }

There is one drawback using chainhull() { } as you can’t use conditional if else with { } within as it combines them as a group and becomes a child structure and so it will act as hull(), so you only can list non-conditional pieces within chainhull() as of OpenSCAD 2019.05, perhaps at a later time this limit vanishes.

That’s it.

Parametric Part Cooler

by Rene K. Mueller · published December 27, 2020 Technology Chimera, Cyclops NF 2-in-1, Cyclops V2, E3D Chimera, E3D Cyclops, E3D Volcano, OpenSCAD, Parametric CAD, Part Cooler, Triple Extruder, Triple Micro Swiss, Volcano

Status: fully tested, but not yet released

Updates:

2020/12/27: individual renderings for each application
2020/12/21: improve documentation, with application variables
2019/06/16: design solidified, multiple variants tested (Triple Micro Swiss, Dual Micro Swiss, Chimera, Cyclops NF, Dual V6, Single V6)

Introduction

Back in May 2019 I started to customize dedicated printheads, e.g. combining CR10 hotends / Micro Swiss Hotends in dual and triple mode – and thereby required a dedicated Part Cooler. This lead me to develop my own Parametric Part Cooler in OpenSCAD, adapting the design of Radial Fan Fang by Lion4H as I used that one successful for E3D V6 – now a general approach coded entirely in OpenSCAD:

Part Cooler on Triple Micro Swiss (rough draft)

I started with the central heatsink fan in the geometric center, and route the pipes (symmetrically) around it, back to the nozzle; on top using 5015mm fan blower – after a couple of hours the basic form was defined.

As long I am in edit or tune mode, the part cooler is rendered with a few corners – yet, when exporting STL format, the pipe is calculated with refined spline and smooth surface:

Screenshot from 2019-06-17 07-21-14 — Parametric Part Cooler for Triple Micro Swiss Hotends

Screenshot from 2019-06-17 07-22-05 — Parametric Part Cooler for Triple Micro Swiss Hotends

Variables

part_cooler() takes following variables with their defaults:

m=40: size of heatsink fan
t=2: thickness of fan mount
zoff=17: z-offset of air outputs
yoff=8: y-offset of air outputs
ws=12: extra width space
wx=35: cutout width X at the bottom
sq2=0.6: relative squeeze Y-wise at air outputs
sq3=0.6: relative squeeze Z-wise at air outputs
zb=0.5: relative Z bend
smooth=false: switch of smooth pipe rendering (false: fast rendering / editing mode, true: export to STL)
name="noname": label on both sides
tscale=1: text/label x/y scale

Needless to say, to set or alter those variables you require the fan and the hotend as a model so you can model the part_cooler() around it.

Applications

After a couple of weeks the part_cooler() was designed for various hotends:

Parametric Part Cooler: Triple Micro Swiss, Chimera, Cyclops NF, Volcano, V6 Lite

Triple Micro Swiss (3x CR10 Hotends): largest part cooler, and first application
Chimera 2-in-2: two filament/material and two nozzles, yet, a small common heatsink with E3D V6 nozzles
Cyclops NF or Lerdge 2-in-1 V2: simple non-mixing 2-in-1 printhead – in use currently on the Ashtar C #1 (Core XY)
E3D Volcano: although designs exist, I just wanted to see how my cooler performs in comparison – in use currently on Ashtar K #1 (Prusa i3-like) with 0.6mm nozzle
E3D V6 Lite: just an excercise to make it work for this popular setup as well – in use currently on CTC DIY I3 Pro B Y3228

Application Variables

Triple Micro Swiss

name=”triple swiss”
m=50
wx=50
yoff=17
sq3=1
wx=54

* requires a dedicated fan mount: Triple Nozzle Printhead

Dual Micro Swiss

name=”dual swiss”
wx=50

* requires a dedicated fan mount: Dual Nozzle Printhead

Chimera 2-in-2

name=”chimera”
m=30
yoff=10
zoff=18
ws=18
wx=42

Cyclops NF

name=”cyclops nf”
m=30
wx=25
yoff=9

see Cyclops NF

E3D Volcano

name=”volcano”
m=30
wx=24
yoff=12
zoff=21
zb=0.3
tscale=0.9

E3D V6 Lite

name=”e3d v6″
m=30
wx=24
yoff=12
zoff=14
zb=0.2

Pros / Cons

Pros:

parametric, reusable design
source code available (OpenSCAD) [not yet]
modular/stack use:
- either use below or above existing heatsink fan
- e.g. add LED Strip Fan Mounts

Cons:

other parts must be available as models in order to determine parameters of the part cooler
heatblock(s) should wear silicon cover, as air outputs partially affect heatblock which should be avoided

Download

~~https://www.thingiverse.com/thing:3680198~~ (not yet released)

Currently all my parts reside in a single large parts.scad for all Ashtar 3D printers, it helps me to improve designs quickly, but hinders me to release part designs in OpenSCAD source individually – it’s all interconnected and therefore avoid split it into separate files for now. As soon it’s resolved I will release the OpenSCAD sources.

For now three part coolers I released in STL downloadable on the dedicated pages:

Impressions

I’m quite happy with the result and use this Parametric Part Cooler for all my planned use cases.

References

Radial Fan Fang by Lion4H

3D Printer Ashtar D: Classic XY, First Draft

by Rene K. Mueller · published December 25, 2020 Technology 2020, 2020 Alu Extrusion, Ashtar D, Ashtar D 3D Printer, Cubic Frame, RepRap

Updates:

2020/12/25: published

Introduction

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

Draft

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)

by Rene K. Mueller · published December 24, 2020 Technology 2020, 2020 Alu Extrusion, Ashtar D, Ashtar D 3D Printer, Cubic Frame, RepRap

Status: built, but not much tested yet

Updates:

2024/12/22: referenced in Multi Gantry Printer with MG-MIEX upgrade
2022/12/09: finally built it, and photos of first print done
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

Introduction

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

Draft

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

*ad_ymount(type=”pulley”) in the front, and ad_ymount(type=”motor”) in the back*

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

*Ashtar D: Y carriage with X motor mount and X pulley (on the other side)*
*Y motor mount and shaft extender and Y pulley*

Specifications

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

Gallery

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

Sharp edges of X & Y motor & pulley mounts

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:

*Reusing NEMA 17 shaft as axis for 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.

Gallery

Z Axis & Motors

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

Parts

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)

Enclosure

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

Printer Enclosure, parametric enclosure, 2.5mm thick acrylic

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.7Kcm³ / 57.7L) = 100%
Device Dimension: 590 x 650 x 620mm (237Kcm³ / 237L)
Build vs Device Volume: 4.11

Creality CR5

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

Ultimaker S5

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

Creality Ender 6

Build Volume: 250 x 250 x 400mm (25.0kcm³ / 25L) = 43%
Device Dimension: 495 x 495 x 650mm (159Kcm³ / 159L)
Build vs Device Volume: 6.36

Ashtar D and Ultimaker S5 device volumes are nearly the same, 237Kcm³ vs 225Kcm³, 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.

Building Ashtar D

It took a while to build the Ashtar D #1 as the other variants like Ashtar K and Ashtar C worked so well – here some of the early tests in 2022/12/09:

References

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

by Rene K. Mueller · published December 23, 2020 Technology 2020, 2020 Alu Extrusion, 3D Printer, Ashtar B, Ashtar B 3D Printer, Cantilever, OpenSCAD, RepRap

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

20×20 aka 2020 Alu Extrusion T-Slot Profile

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

by Rene K. Mueller · published December 14, 2020 Technology 2020 Alu Extrusion, 3D Printer, Ashtar M, Ashtar M 3D Printer, Draft, Moving Gantry, Moving Portal, Moving XZ Frame, OpenSCAD, RepRap

Updates:

2020/12/20: adding XZ arch option
2020/12/14: initial post

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.

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:

Side pieces “A” & “B” with Arch (lower X-beam removed)

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.

Pros

gain Z build space
reduce XZ gantry weight / inertia

Cons

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)

by Rene K. Mueller · published December 13, 2020 Technology 2020, 2020 Alu Extrusion, Ashtar M, Ashtar M 3D Printer, OpenSCAD, Prusa i3, RepRap

Status: just a draft

Updates:

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

Introduction

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)

Draft

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.

Specifications

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:

Side pieces “A” & “B” with full XZ Frame

~~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

Preliminary position of multiple extruders: X back beam, hence, very long Bowden tubes

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

Bed

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.

Gallery

Parts

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:

Printable

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

Non-Printable

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.

References

Jon Schone’s Moving Portal CR-10 Mod

AluX: Prusa i3 Clone

Ashtar X & W Series: Riding on Smooth Rods

Ashtar T Series: Riding Alu Profiles

Ashtar K Series: Riding Alu Profiles, Uni-Length Beams

Next Steps

Bill of Materials (BOM)

Building

Software

Hardware

Download

Applications

Direct Drive Extruder

References

See Also

Introduction

Deeper Roots of RepRap

The Genesis of RepRap

Limits of RepRap & Future

References

From Bulky To Elegance

Using Chained Hulls

rcube() & rcylinder()

chainhull()

Introduction

Variables

Applications

Application Variables

E3D Volcano

E3D V6 Lite

Pros / Cons

Download

Impressions

References

See Also (Ashtar Series & Parts)

Introduction

Draft

Introduction

Draft

Y Motor Mount

X Motor Mount

X & Y Motors / Axis

Specifications

Issues to Resolve

Gallery

Classic XY vs Core XY

Sharp vs Rounded Edges

Toward Elegance

IDEX Option

Gallery

Z Axis & Motors

Parts

Printable Parts

Non-Printable Parts

Enclosure

Building Ashtar D

References

See Also (Ashtar Series & Parts)

Frame: 6 vs 7 vs 9 beams

Z Carriage: 3 vs 4 wheels module

Different Sizes

Moving Portal / Gantry

First Draft

XZ Arch Option – Removing Lower X Beam

Further Development

Introduction

Reducing Moving Weight

Draft

XZ Arch Option

Specifications

Issues to Resolve

Bed

Gallery

Parts

Printable Parts

Non-Printable Parts

IDEX Option

Printable

Non-Printable

References

See Also (Ashtar Series & Parts)