Category Archives: Technology

3D Printing: Ashtar C IDEX (Independent Dual Extrusion)

Status: just a draft

Updates:

  • 2021/01/14: quick start with a rough draft

Introduction

Well, after the IDEX option designs – still as drafts – worked for Ashtar K (Prusa i3), Ashtar M (Moving Gantry) and Ashtar D (Classic XY), I thought, why not also target Ashtar C (Core XY).

Ashtar D IDEX is definitely a narrow design, so I thought to reuse two parts of it for Ashtar C as well, and hopefully the A and B belts route around – and well, it seems mechanically to work out.

On the firmware part it seems this CoreXY plus additional X motor is called CoreXYU and supported by Duet RepRap firmware – but details need to be researched in more depth. On the first glance the “traditional” CoreXYU setup routes the U belt off the X beam and not place a motor on it as I do, but routes at the end of the frames so the motor is stationary – definitely something also to look at.

Draft

Gallery

Issues to Resolve

  • Firmware supporting CoreXY IDEX:
    • E1: X & Y provided through CoreXY by motors A & B
    • E2: X provided by X motor, Y provided by CoreXY where X=0 remains (both motors A & B have to operate to provide X=0 while Y is moved)
    • Duet RepRap firmware provides CoreXYU support, and it seems it would cover my use case here
    • Marlin firmware as of 2.x does not support CoreXYU yet
  • Moving the X motor – or U motor as in CoreXYU context – off the X beam and route a much longer belt and place the motor stationary like the motors A & B of CoreXY
  • Ooze prevention (same issue as with Ashtar D IDEX)

As I progress I will update this blog-post, and summarize also the developments in the Ashtar C project page.

References

  • CoreXYU: Dual Head for CoreXY, another more complex approach where 3rd motor is also stationary

That’s it.

3D Printing: Ashtar D IDEX (Independent Dual Extrusion)

Status: just a draft

Updates:

  • 2021/01/14: starting the draft, very experimental

Introduction

After just few hours working on IDEX option for Ashtar K and Ashtar M, I thought to try myself on doing IDEX on the very delicate Y carriage on Ashtar D – and after an hour roughly I realized, perhaps it is doable.

The main idea is to reuse the NEMA17 shaft as axis for the idler of the 2nd belt, and use 3mm diameter shaft with 5-10mm length as extension, and stabilize the extension in the idler itself likely the shaft seems long enough by itself – the most space saving option:

If possible, rotate entire X motor mount / carriage and mount it on the other X side.

Draft

I had to color the belts and V modules, as I otherwise get confused while fine-tuning the design within such narrow margins:

  • X1/E1 in green
  • X2/E2 in red

I just love symmetry!
I just love symmetry!

Gallery

Issues to Resolve

  • X motor-mount isn’t fully Y symmetric yet, it’s off by a few mm; needs some further fine-tuning until X2 motor-mount mounting holes align with V module, resolved
  • V module belt mount for X2 needs be adapted, as I can’t mirror it as that “back” mirrored is the “front” side where the printhead is mounted and occupied already, a new piece is required which mounts within the V module
    • dedicated piece ad_xcarriage_beltmount(idex=true) required
  • ooze prevention in rest position: some sort of metal sheet close by where the printhead’s nozzle can rest
  • mature Ashtar D design sufficiently beyond draft stage

As I progress I will update this blog-post, and update the Ashtar D project page as well.

That’s it.

3D Printer: Ashtar K IDEX (Independent Dual Extrusion)


Status
: verified design

Updates:

  • 2021/07/30: design printed and mounted
  • 2021/01/19: improved 2nd X motor mount
  • 2021/01/15: removable/replaceable ooze prevention
  • 2021/01/14: Ashtar M (Moving Gantry – Draft) also with IDEX option now
  • 2021/01/13: ooze prevention at rest position added, mechanical conflict resolved
  • 2021/01/12: starting with a first draft, one mechanical conflict to be resolved

Introduction

I have been pondering on a dual independent X axis upgrade or option for a while, but the other designs of the Ashtar Series I wanted to do first (Ashtar D and Ashtar M) those matured by now (2021/01), so I decided to get back to IDEX upgrade for Ashtar K:

For now I like to keep single 2020 V slot alu extrusion for the X beam where the X carriage rides, and route the 2nd belt above for the 2nd X carriage – and this was a quick solution as earlier version of Ashtar K had the belt routed above the alu profile so I just reused the old pieces again.

“Above routed belt” option with its pieces are weaker and possibly need enforcement improved the strength, so it’s a fast start – just took me 2 hours – but needs definitely some fine-tuning. Alternatively the 2nd belt could be routed at the back of the X carriages, but fastening the 2nd X motor would be challenging.

For now I use the same code base of Ashtar K and introduce IDEX = true flag, and enhance a few existing pieces in parts.scad and optionally add those new pieces when rendering printer-ak.scad.

As I progress with this option or upgrade I update this blog-post.

Draft

Issues to Resolve

  • X carriage #1 belt mount conflicts mechanical with belt 2: redesign xcarriage_beltmount_2020 piece, make it shorted in Z or fasten it inside V module: resolved, shifted 2nd belt a bit Y off, and shorten xcarriage_beltmount_2020(idex=true) by 2mm.
  • “Above routed belt” pieces are weaker: enforcement required, resolved: piece strengthened (2021/01/19):
    • xcarriage_short_hmount_motor_2020 which is the base piece which routes the belt within the 2020, with idex=true option provides idler holder on top
    • X motor #2 is mounted on a x-mirrored version of xcarriage_hmount_motor(20,"left",idex=true) but definitely needs reinforcement, added ooze prevention in case of idex set
  • Nozzle drip prevention:
    • using a piece of sheet metal which the nozzle moves over when in rest position left or right, first attempt done (see below)
    • and/or use purge box with brush to clean nozzle after and before use
    • make extending “nose” detachable/replaceable as it’s expected to break or overheat otherwise entire X motors mount needs replacement, resolved
      • xcarriage_nose-idex-left and xcarriage_nose-idex-right with 10mm wide sheet metal insert
    • how dealing with long resting hot nozzle?
      • drop temperature by 5-10°C in rest position, and heat up when in use again
      • heat creep possible weakening extending printed nose – heat insulation required attaching sheet metal

Gallery

Ashtar M IDEX

And since Ashtar M (Prusa i3 Moving Gantry – Draft) shares much of the Ashtar K design it took me a few mins to add the IDEX upgrade option as well:

References

3D Modeling: Random Snapshots 2020

3D Printer: Ashtar K History 2018-2020

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

Ashtar Series Genealogy (2018-2020)

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

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:

Download

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

includes STLs and OpenSCAD source code of the module

Applications

Direct Drive Extruder

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

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

See Also

RepRap Principle

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:

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

References

Continue with 3D Printer History or RepRap Blog Archive.

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

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

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:

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:

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

or

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

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.