Monthly Archives: February 2021

3D Printing: Conic Slicing for Rotating Tilted Nozzle (RTN) / 4 Axis

State: early draft, mostly simulations with a few tests with 3-axis printer only

Conic sliced overhang model with two overhangs, printing with Rotating Tilted Nozzle (RTN) 90° overhang structure without support structure


  • 2021/03/22: slicer4rtn released, see dedicated page Slicer4RTN
  • 2021/03/16: removing details on slicer4rtn as a new dedicated page is in the working (coming soon)
  • 2021/03/08: slicer4rtn 0.2.3 reached (still unreleased), better prints, documenting various settings in more details
  • 2021/03/05: added proper ZHAW reference in the introduction and a few notes
  • 2021/02/27: removed some redundant illustrations and remade some of them, outside-cone vs inside-cone mode & printing
  • 2021/02/26: added inside-cone printing example for inner overhang mode, also early information of slicer4rtn; more animations to observe details of produced G-code, using now also OpenSCAD to simulate G-code and actual nozzle position
  • 2021/02/24: better tests with 20mm cube and overhang structure, included two short G-code simulations as videos, added 20mm sphere and 3D Benchy and discover first issues with volume decomposition and overhang recognition
  • 2021/02/23: first write up, pseudo code and first attempt to conic slice 20mm cube

As I progress I will update this blog-post.


The main idea is to utilize existing 3D printing slicers but create conic slices for the Rotating Tilted Nozzle (RTN) 4 Axis Printer. ZHAW published in their announcement in 2021/01 something about utilizing existing slicers, but the details remained concealed and later published as a paper but I did not want to wait and pondered on the problem, and came up with a solution. In its current state it’s purely theoretical and untested for now (2021/02) barely tested yet.

Michael Wüthrich confirmed my solution is comparable with their solution. ZHAW planned their paper to be published sometime 2021. So, the main credit goes to ZHAW and the researchers (Prof. Dr. Wilfried Elspass, Dr. Christian Jaeger, Michael Wüthrich, Maurus Gubser, Philip Bos and Simon Holdener) there, I was just impatient and tried to find a solution with the information available.

I also adapted some of the notions Wüthrich introduced in the Novel 4-Axis 3D Printing Process to Print Overhangs Without Support Material paper, e.g. “outside-cone” and “inside-cone” printing as featured in an earlier blog-post already.

Non-Planar Conic Slices

The 4-axis Rotating Tilted Nozzle (RTN) physical setup implies its slices are of non-planar conic shape, allowing to print overhangs without support structure, such as:

Conic slices of an overhang model

I also like to master the conic slices properly as they promise to become a subset of 5 axis printhead (PAX) features too – so it’s worth the effort even if the RTN itself might be too limited in its application with its fixed tilt – we will see.


In a nutshell the steps are following:

  1. sub-divide faces of the model (fine-grained)
  2. map model to inverse conic space
  3. send to slicer
  4. remap G-code to conic space
  5. adding Zrot to G-code

Conic Space Mapping

(x1,y1,z1,rot) = conicSpaceMapping(cx,cy,x,y,z,dir);


  • cx, cy are the conic axis coordinates
  • x, y, z are the input coordinates
  • x1, y1, z1 are the output coordinates
  • rot the rotation angle x,y vs cx,cy
  • dir is either direct (default) or inverse
function conicSpaceMapping(cx,cy,x,y,z,dir='direct') {
   dx = x-cx; 
   dy = y-cy;
   d = sqrt(dx*dx + dy*dy);
   rot = atan2(dy,dx);
   return (x,y,dir=="direct" ? z-d : z+d,rot);


The entire procedure goes like this:

m = loadModel("cube.stl");
m = subDivide(m,5);
for(p of m.vertices) {
    m.vertices[i] = conicSpaceMapping(cx,cy,p.x,p.y,p.z,'inverse');

gcode = sliceModel(m);

foreach(line of gcode) {
   (code,x,y,z,e) = extractCoordsExtrusion(line);
   (x1,y1,z1,zrot) = conicSpaceMapping(cx,cy,x,y,z,'direct');

Note: the pseuco-code is incomplete as extrusion E is not yet taken care of, as soon I found a definitive solution I will write it up.


I implemented the pseudo-code with some more details like taking care of G-code E extrusion as well and fine-step linear extrusion – here some early tests using OpenSCAD as STL & G-code viewer and Slic3r as actual slicer:

20mm Cube Conic Sliced

Snapshots of progress of conic sliced 20mm cube:

20mm cube conic sliced G-code
20mm cube conic sliced with rotating tilted nozzle simulation

Overhang Conic Sliced

Snapshots of progress of conic sliced Overhang:

Conic sliced overhang model
Conic sliced overhang model including rotating tilted nozzle simulation

Gallery of Conic Sliced Models

Detailed snapshots of overhang nr 3

Detailed snapshots of model nr 6 (table-like)

Some more models with their in-between states, using Cura as model and G-code viewer:

Issues to Resolve

  • test actual G-code in real life
  • find good pre-processing face sub-division strategy
    • in its current form the algorithm requires fine-grained sub-divided faces otherwise inaccurate G-code is created which cannot be recovered
  • slice more complex parts
    • 3D Benchy: requires more thorough examination, e.g. volume decomposition to segment roof apart:

  • document all details
  • release source code to public


Some close-ups of conic sliced models:

Outside- vs Inside-Cone Printing

As pointed out in the previous blog-post, the RTN has two main modes of operation, outside-cone and inside-cone printing to cover outside overhangs and inside overhangs – the slicer must recognize those and switch operation mode. Further, these two modes cannot easily be mixed, and need to be segmented or separated, hence speaking of volume segmentation.

This poses significant grow of complexity from just planar slicing, the 4 axis RTN provides features to print 90° overhangs without support structure, but only when the part can be properly analysed and segmented so that those operational mode can be applied.

The difference between inside- and outside-cone printing is to change the order of conic mapping for the model and post slicing:

outside-cone mode

  1. map model inverse conic
  2. slice model
  3. map G-code direct conic

inside-cone mode

  1. map model direct conic
  2. slice model
  3. map G-code inverse conic, Zrot + 180°


The pseudo-code turned into an actual application I named slicer4rtn and is a command-line tool, slicing STL into G-code:

% slicer4rtn --subdivide=5 --recenter cube.stl
== Slicer4RTN 0.4.1 ==
processing 'cube.stl':
   1/5 read stl
      1/5 subdivide (44 vertices)
      2/5 subdivide (188 vertices)
      3/5 subdivide (764 vertices)
      4/5 subdivide (3068 vertices)
      5/5 subdivide (12284 vertices)
   2/5 map vertices
   3/5 write temporary stl
   4/5 slice (slic3r) stl
=> Processing triangulated mesh
=> Generating perimeters
=> Preparing infill
=> Infilling layers
=> Exporting G-code to ./temp-603919.gcode
Done. Process took 0 minutes and 1.362 seconds
Filament required: 710.9mm (5.0cm3)
   5/5 remap gcode to 'cube.gcode' (16214 lines)
== took 3 secs total, done.

I gonna released Slicer4RTN eventually 2021/03/22, in its early version the model currently can only be sliced for outside-cone or inside-cone printing, so the volume decomposition or segmentation needs to be done separately. For now it helps me to verify some of the 4-axis and 5-axis printer designs I work on.

Ashtar K RTN printing conic sliced 20mm cube (close up, animation)
Ashtar K RTN printing conic sliced overhang model without support structure (close up, animation)
Ashtar K RTN printing conic sliced overhang model nr 6 (table-like) without support structure (close up, animation)

Test Prints

As soon I built the RTN printhead on one of my printers I will post photos of the first prints. For now (2021/03) I only printed conic sliced pieces on a 3-axis 3D printer.


With conic sliced G-code there are many first layers . . .

That’s it.

3D Printing: Ashtar Series Printhead Options 2021/02

The past weeks (2021/02) I worked on various printhead designs, to summarize and provide an overview by mounting them on Ashtar K:

Also improved the display controller to simulate Marlin firmware and list heads and tool selection (MSE), coordinates (IDEX) or rotation angles (RTN & PAX).

So far all options are available for Ashtar C, D and M as well, but currently (2021/02) are just in draft and mostly untested.

RTN and PAX promise printable support-free overhangs, yet no public available slicing software exists to really take advantage of those two designs, as new algorithms of volume decomposition, sub-volume sequencing, collision detection are required and mostly debated in scientific papers as 2021/02 and only few companies, e.g. HAGE and VSHAPER, implemented new 5-axis 3D printing procedures, and DotXControl advertises a 5 Axis Slicer.

That’s it.

3D Printing: Penta Axis (PAX) / 5 Axis Printing Option – Draft

Status: very early draft, inverse kinematics resolved


  • 2021/02/28: added animation PAX printing a 4-axis/RTN sliced overhang model
  • 2021/02/17: added two brief animations of inverse kinematics
  • 2021/02/08: inverse kinematics working, printhead mounted on Ashtar K as draft
  • 2021/02/06: machine vs nozzle coordinates, forward/reverse transformation requirements, heatsink fan and part cooler added
  • 2021/02/04: starting with collecting ideas and first drafts


After I saw 5- and 6-axis printers at Formnext 2019 and particularly seeing the belt printers able to print 90° overhangs in one direction without support, and then RotBot by ZHAW, a Rotating Tilted Nozzle (RTN) printer, where the 90° overhangs in different directions (given some conditions) can be printed without support – so it was more natural to consider to make the tilting nozzle angle (trot) flexible as well, 0 – 180°.

  • 0°: nozzle looking down, ordinary orientation with Z sliced layers 3D printing
  • 45°: belt printer or rotating tilted nozzle (RTN) printer, printing 90° overhangs in one or more directions *)
  • 90°: printing horizontally outward
  • 135°: printing upward 45°
  • 180°: printing upward entirely

*) Rotating Tilted Nozzle capability printing 90° overhangs depends on location and symmetric alignments, no slicing software yet available.

Flexible Tilting

2 Axes with NEMA 17

Let’s look at bit closer to the new rotating axes implemented with direct drive NEMA 17 stepper motors:

  • Z rotation (aka Zrot) with
    • NEMA 17 39/40mm long (45Nm) or
    • NEMA 17 25mm/180g (13Nm)
  • Tilt rotation (aka Trot) with
    • NEMA 17 20mm/140g (16Nm) or
    • NEMA 17 25mm/180g (13Nm)

both provide 1.8° (or optionally 0.9°) resolution per full step, or

  • 8 microsteps (20% force) 0.225° @1.8°step (0.1125° @0.9°step) per microstep
    • Z rotation 9 Nm (or 2.6Nm)
    • T rotation 3.2 Nm
  • 16 microsteps (10% force) 0.1125° @1.8°step (0.0565° @0.9°step) per microstep
    • Z rotation 4.5 Nm (or 1.3Nm)
    • T rotation 1.6 Nm

For now, for sake of simplicity, both axes are in direct drive – if precision requirements dictate a simple reduction gear 1:4 or 1:5 (see below for some more details).

Taking Advantage of 5 Axis

In 5 axis CNC context there are multiple configurations possible such as table/table, head/head and table/head – as I came from the Rotating Tilted Nozzle (RTN) the extra 2 axis are added to the head, hence head/head configuration.

Tilt rotation 0 .. 180°

The Trot of 0° is the equivalent of ordinary 3D printer with top/down oriented nozzle, the 45° the belt printer or RotBot/RTN, and 90° printing vertical walls with the nozzle perpendicular, and 90-135° printing up-side down – I’m not sure if 135-180° is that useful, perhaps making underlying structures really smooth. For now I keep the tilt rotation from 0° to 180° even though I think I’m going to use 0-135° in real life application when the actual print procedure is developed, planar or non-planar slicing.


5 Axis Kinematics

LinuxCNC 5 Axis kinematics describes the notations and provides a starting point and I realized quickly that in CNC context the 5 axis operations is quite thoroughly explored, but much fewer focus on 5 axis additive manufacturing yet (see below at References).

In order to reflect the rotation per axis, the notion A, B and C are adopted, which can be described in OpenSCAD as

translate([X,Y,Z]) rotate([A,B,C]) ...
X,Y,Z (tool coordinate) and I,J,K (tool vector)

Further the CNC notion I, J and K are used as tool vector, the way the nozzle points away. G-code supports natively G1 X Y Z I J K which is machine independent. The machine specific firmware then computes the machine coordinates and rotating angles so the machine tool tip reaches those coordinates with that particular tool vector.

Tool/Nozzle vs Machine Coordinates

Absolute coordinates X, Y, Z of the nozzle tip and angles Zrot, Trot and given the Z rotation arm there is a mapping required to Xm, Ym, Zm with same Zrot, Trot.

The forward transformation in OpenSCAD:

translate([Xm,Ym,Zm]) rotate([0,0,Zrot]) rotate([Trot,0,0]) translate([0,0,-45]) sphere(0.1); // nozzle tip at X, Y, Z with I, J, K
45mm vertical offset of tilt axis to nozzle tip

or expressing it as a list:

  1. at 0, 0, 0 (origin)
  2. translate([Xm,Ym,Zm])
  3. rotate([0,0,Zrot])
  4. rotate([Trot,0,0])
  5. translate([0,0,-45])
  6. at X, Y, Z

The -45 is the 45mm vertical offset of the tilt rotation to the tip of the nozzle.

In OpenSCAD it’s the reverse order, and enumerate matrices (used further below):

  1. at X, Y, Z
  2. translate([0,0,45]) aka M1
  3. rotate([-Trot,0,0]) aka M2
  4. rotate([0,0,-Zrot]) aka M3
  5. translate([ Xm, Ym, Zm ]) aka MR, by inverting matrix the Xm, Ym, Zm can be extracted
  6. at 0, 0, 0 (origin)

Each transformation can be represented by a 4×4 matrix, the sequence of transformations are the multiplication of such, and when multiplying symbolical a single 4×4 matrix will result. When keeping the symbolical notion the inverse transformation can be obtained with one operation and getting Xm, Ym, Zm from X, Y, Z, Zrot, Trot, and that very computation needs to be done in the firmware and controller in order to process X, Y, Z, Zrot, Trot as G1 X.. Y.. Z.. A.. B.. and the internally Xm, Ym, Zm is processed to achieve that tool coordinate; A = Zrot, B = Trot .


G1 X.. Y.. Z.. A.. B..


Zrot = A
Trot = B
Xm, Ym, Zm computed via reverse/inverse transformation on the controller

Numerical Inverse Transformation

Just for sake of confirming the reverse/inverse transformation utilizing m4.scad:

include <m4.scad>

Zrot = 45;
Trot = 45;

M1 =       [ [ 1, 0, 0, 0 ],
             [ 0, 1, 0, 0 ],
             [ 0, 0, 1, 45 ],
             [ 0, 0, 0, 1 ] ];

M2 =       [ [ 1, 0, 0, 0 ],
             [ 0, cos(-Trot), -sin(-Trot), 0 ],
             [ 0, sin(-Trot), cos(-Trot), 0 ],
             [ 0, 0, 0, 1 ] ];

M3 =       [ [ cos(-Zrot), -sin(-Zrot), 0, 0 ],
             [ sin(-Zrot), cos(-Zrot), 0, 0 ],
             [ 0, 0, 1, 0 ],
             [ 0, 0, 0, 1 ] ];

MR = m4inv(M1 * M2 * M3);
// or MR = m4inv(m4tr([0,0,45])*m4rx(-Trot)*m4rz(-Zrot));

which outputs

ECHO: [[1, 0, 0, 0], [0, 0.707107, -0.707107, 31.8198], [0, 0.707107, 0.707107, -31.8198], [0, 0, 0, 1]]

so MR contains the inverse matrix of the previous transformations, so I can extract the translation vector, the 4th column [ MR[0][3], MR[1][3], MR[2][3] ] or m4trv(MR) to compensate X, Y, Z, Zrot, Trot -> Xm, Ym, Zm:

Testing Inverse Kinematics (IK)

PAX printhead on Ashtar K, inverse kinematics tested: X=150, Y=0, Z=0, Zrot=0..180°, Trot=0..45° (animated)

Perhaps it’s worth to actually calculate symbolical forward and inverse transformation matrix using e.g. Matlab or alike to have transformations in one operation instead multiplying three matrices and inverting it – depending what hardware is used as controller multiplying individual matrices is faster than trying to have a complex single step matrix construct.

Although Marlin firmware supports Delta printer with complex delta inverse kinematics, not sure I can add mine as well, or I have to go with Duet RepRap firmware which seems more suitable (see notes below).

Nozzle Precision from Trot

The 45mm offset of the last rotation massivly contributes to the loss of nozzle position resolution:

s = 2 π * r / 360 = section length per degree

s = π * 45mm / 180 = 0.785mm/° which means:

  • 8 microsteps with 1.8° full step: 0.225°/microstep => 176.7μm/microstep
  • 16 microsteps with 1.8° full step: 0.1125°/microstep => 88.3μm/microstep
  • 8 microsteps with 0.9° full step: 0.1125°/microstep => 88.3μm/microstep
  • 16 microsteps with 0.9° full step: 0.0565°/microstep => 44.4μm/microstep

so the direct drive using the shafts of the NEMA 17 will provide OK resolution, but for anything a bit more serious, a reduction gear might be worth to use.

G-code & Firmware

As I likely will generate machine independent G-code as G1 X Y Z I J K, the slicer stage will likely operate in X, Y, Z and Zrot and Trot as well – so we end up with a data pipeline like this:

  1. Slicer: X, Y, Z, Zrot, Trot
  2. G-code: G1 X Y Z I J K
  3. Firmware: X Y Z I J K => Xm, Ym, Zm and I J K => Zrot, Trot

Alternatively, instead using I J K notion use the G-code A and B as two rotational axes as Duet RepRap Firmware offers G1 X Y Z A B then it’s a bit simpler:

  1. Slicer: X, Y, Z, Zrot=>A, Trot=>B
  2. G-code G1 X Y Z A B
  3. Firmware: X Y Z A B => Xm, Ym, Zm and A=>Zrot, B=>Trot

Reviewing existing slicer/printing software to see which notion is more suitable, and perhaps cover both to stay flexible.

From Xm, Ym, Zm, Zrot, Trot to X, Y, Z

Issues to Resolve

  • Bowden tube- & cable management: properly resolve it, guides etc.
  • Develop the transformation/inverse kinematics X, Y, Z, Zrot, Trot <=> Xm, Ym, Zm, Zrot, Trot as well X, Y, Z, I, J, K <=> Xm, Ym, Zm, Zrot, Trot as required for slicing, and firmware stage, done
  • Calculate the precision of X, Y, Z in relation of Xm, Ym, Zm and Zrot, Trot, whether or how the motor resolution affect axes => getting a grasp how the overall precision of the final setup
  • Direct drive mechanical precision with 8/16 microsteps, repeatability, and heat dissipation from motor (see tweet)
  • Slicer/print software supporting 5 axis nozzle
    • Duet RepRap Firmware: supports ABCD rotational axes
    • Marlin firmware capabilities, as it support Delta printers, inverse kinematics (IK) calculations seem supported well, question is how simple to add my own custom IK as well
    • printing: recognize model features or base design on seams or boundaries, like OPENCASCADE (STEP/IGES support)
    • printing: use vertical slicing as fallback, given no other printing method is suitable
    • explore different print modes like RotBot/RTN
      • recognize rotational objects: print from inside out like with a lath but adding material
      • detect steep overhangs, find proper way to print them
    • collision detection, e.g. tilt rotation becomes available at a certain Z level as below the upside looking nozzle will touch the build plate with the opposite end – the slicing/print software must be aware of the printhead geometry to calculate what’s possible to print and how



  • many new ways to print in (almost) all directions
  • hopefully print 90° and more overhangs without support at all


  • significant mechanical complexity
    • mechanical limitations arise with new freedom of rotation of printhead
    • collision detection becomes essential which in Z sliced layers is not an issue at all
  • significant software complexity, no current 3D printing software available to take advantage of 5 axis printing

Ashtar K with 5 Axis (PAX) Printhead

Experimental mounting on Ashtar K to see how it looks, including display showing rotations of Zrot (A), Trot (B) too.

Note: the display shows original tool coordinates, whereas the firmware does tool translation aka inverse kinematics as shown in the screenshots with the display readable.

PAX printhead on Ashtar K with virtual Marlin firmware display (animated)

With all the freedom to angle the nozzle, all of the sudden the part cooler air nozzle shape becomes an issue, and has to become narrow as well; and overall geometry of the printhead becomes quite relevant when planning print sequences (collision detection).

PAX can operate in 4-axis mode, e.g. printing a conic sliced (4-axis RTN) overhang model (without support structure) in 4-axis Rotating Tilted Nozzle (RTN) mode (45° titled nozzle):

Ashtar K PAX printing 4-axis/RTN sliced overhang model (animation)

PAX Tilt 180 vs 90

The PAX which tilts up to 180° will be referenced further as PAX or PAX 180, the 360° Z rotation is implied then too, as comparison of PAX 90 tilting to 90° only with shorter arm:

As the slicing strategy isn’t determined, it’s not yet clear if tilt 90..180° is required or not. In case only 0..90° is sufficient, the Z rotation arm can be shortened.


5 Axis

4 Axis

As I progress I will update this blog-post.

That’s it.