A graphical overview of all the efforts featured on the site as of 2021/07:
A graphical overview of all the efforts featured on the site as of 2021/07:
The past few months and weeks I focused on the non-planar slicing, and the first tests with sub-volume segmenting and thereby mixing planar and non-planar sliced G-code worked as simulation, and now in actual prints.
One of the benchmarks are 90° overhangs in different directions, and I printed with vertical nozzle on an ordinary 3-axis FDM printer, therefore I prepared the G-code with a new tool (in-development) which coordinates segmenting and planar/non-planar slicing of sub-volumes, and the conic sliced segment was sliced with 25° conic angle so it remains printable with the vertical nozzle unlike the simulation where a 4- or 5-axis FDM printer is required:
The simulation as reference:
and the actual print process with vertical nozzle on a low-cost 3-axis FDM printer:
Excerpt of the actual printing process with brief annotations:
Just for sake trying out, instead of conic sliced overhang segment, tilt sliced and 45° Z rotated to nicely extend to the maximum overhang position:
and the actual print of a slightly lower model but with the same features:
And revisiting the Overhang In/Out Model, which features ingoing and outgoing overhang, segmented into 5 sub-volumes:
1) when dealing with conic slicing, the direction of overhang matters when deciding the mode of conic slicing, e.g. outside-cone or inside-cone.
and the actual print, a half of the model so the printing of inner overhang on the lower part of the model is visible:
It took me a few days to tune the 3-axis FDM printer to print in acceptable quality of this Overhang Model No 5 and also Overhang In/Out Model. A strong part-cooler was mandatory, well adjusted print temperature and slow perimeter as those extrusions align horizontally without vertical support; and it worked: the main idea is to segment and limit the overhang part to ~2mm thickness – a quasi “balcony” – which still allows a classic vertical nozzle with part-cooler to print such, and then switch back to planar printing again.
Detail settings: the conic overhang was sliced with Slicer4RTN with following settings
slicer4rtn --slicer=cura-slicer --speed_wall=10 --speed_wall_0=10 --speed_wall_x=10 ... and since the Z-axis motion is limited to 4mm/s (M6 threaded rod, 1 rotation => 1mm) the overall printing speed is slow enough to provide acceptable print quality.
In order to take advantage of 4- and 5-axis non-planar FDM1) printing (e.g. tilted, conic, cylindrical, spherical) the model may be segmented and then dedicate slicing methods can be assigned to such sub-volumes.
A few basic examples combining planar and non-planar slicing methods on sub-volume segmented models illustrating the possibilities printing without support structures:
Conic slices can be printed with 4-axis Rotating Tilted Nozzle (RTN) although printing the Z-planar sliced part might not give goods surface results but rather using a 5-axis Penta Axis (PAX) printhead to cover both cases easily.
Using non-rotating but tilted sliced (like used with belt-printers) but in two distinct directions:
Tilted slices can be printed with 4-axis Rotating Tilted Nozzle (RTN) but the first Z-planar part, as mentioned above, might not provide sufficient surface quality, whereas a 5-axis Penta Axis (PAX) printhead can print both segments easily.
A more classic planar approach but with different planes as reference, first Z-planar then twice X-planar in different directions:
X-planar printing requires either 5-axis Penta Axis (PAX) printhead or the ability to tilt the bed.
Lower part is sliced with conic slicing with inside-cone mode to print in-going overhang, whereas the upper part is sliced with outside-cone mode to cover the out-going overhang:
This model covers the classic case of 4-axis Rotating Tilted Nozzle (RTN) application: rotating 45° tilted nozzle printing in two different modes (outside-cone and inside-cone); a 5-axis Penta Axis (PAX) printhead also can print such.
Another overhang piece, stretching out into one direction; the lower part Z-planar, and the overhang conic (outside-cone mode) with an offset to align better with the lower segment:
Perhaps a more realistic approach using the conic part as a “balcony” just for the overhang part sufficiently thick to carry next segment and switching back to Z-planar:
Early tests have shown the thickness of the conic overhang “balcony” depends on the actual length of the in-air overhang, where print speed, part-cooling capacity and extrusion consistency determine the geometrical accuracy. More examples with “balcony” printed with 3-axis FDM printer followed.
Unlike with ordinary Z-planar slicing, it may be suitable to dedicate a particular slicing method and orientation for sub-volumes in order to take advantage of the possibilities like avoiding support structure, particular strength properties or surface quality.
This of course opens a wide-range of possibilities and complexity therefore:
but I think it’s worth it, in particular when a piece is printed more than once like with small series manufacturing / production.
The examples have been produced with various slicers and combined with a new application coordinating the segmenting and dedicated slicing methods, which currently (2021/04) is in development; it also involves a new file-format describing the segmenting and its slicing settings. The segment positioning was done manually as a start, but I expect with more experience and research some cases can be detected automatically.
Sub-volume segmenting is just one approach to take advantage of 5-axis FDM printing, another is continuous slicing along the form.
PS: All animations I combined in a short 3min video: Mixing Planar & Non-Planar Slicing Methods for 3D Printing Overhangs without Support Structure (YouTube)
Example of non-planar G-code:
Note: I opened a Pull Request (PR) but not sure if it’s accepted.
After discovering the 4-axis Rotating Tilted Nozzle (RTN) and its prototype of RotBot as developed by ZHAW and their conic slicing method, it became clear to me a 5-axis 3D printer with variable tilting nozzle is the way to go as it is a superset of 4-axis and 3-axis 3D printing.
With that in mind, I realized there was time to explore non-planar slicing with planar slicers in more details.
Let’s provide an overview of various slicing methods:
Vertical slicing creates horizontal slices, the traditional aka planar slicing method, so issues and limitations are well known:
Tilted slices are kind of new(er) and became known with belt printers, usually 45° tilted:
Transformation is [ x, y, z – y ]
There are patches for Cura available to slice for belt printer, additional the experimental Slicer4RTN also provides tilted slicing.
Transformation is [ x, y, z + sqrt(x2 + y2) ]
I implemented a conic slicer named Slicer4RTN in 2021/03. There are more complex conic transformations possible, e.g. map the x/y angle via atan(y/x) but just adding sqrt(x2 + y2) to z does achieve a conic slice.
Early tests using planar slicers to slice also cylindrical, like this:
Transformation is [ atan(y/x), z, sqrt(x2 + y2) ]
It can be printed on a fixed vertical rod, with a rotating and tilting nozzle, or horizontal rotating rod (like a lathe) and vertical nozzle then:
I came up with this way by myself based on the study on conic(al) slicing but I was made aware researchers Coupek, Friedrich, Battran, Riedel back in 2018 published a paper on this method already.
Early tests using planar slicers to slice also spherical, like this:
Transformation is [ sqrt(x2 + y2 + z2), atan(y/x), atan(z/sqrt(x2 + y2)) ]
It can be printed with a 5-axis like PAX printhead, it’s main advantage is to getting close to print continuous overhangs of any angle.
I suspect at least one more suitable and simpler sphere transformation, as soon I came up with such I add it on this blog-post.
It is possible to slice non-planar with planar slicers by mapping to and from the space of the slicing you like to have; yet in the slicing procedure some margins are introduced which need to be compensated – the planar slicer needs to work reliable, Slic3r 1.2.9 and CuraEngine 4.4.1 / cura-slicer perform reliable, whereas PrusaSlicer 2.1.1 makes assumptions of the printability and exits when no printable G-code can be produced, not recommended for this case therefore.
The simpler the transformation forward and backward, the more precise G-code can be obtained, e.g. tilted and conic slices provide precise G-code, whereas cylindrical and spherical slices are harder to tune with the planar slicer.
--binary=..to change binary name
I’m a great admirer of the Ultimaker Cura slicer since years, yet I predominantly have been using CuraEngine on the command-line via Print3r, which hides all the tedious configuration. But it came the point (2021/03) when I needed to have a simpler interface than CuraEngine – hence I wrote Cura CLI Wrapper, the executable
cura-slicer looks like
slic3r and has similar usage.
Speciality is to query all the settings from
% cura-slicer --help acceleration_enabled = 0 (default) acceleration_infill = 3000 [mm/s²] (default) acceleration_ironing = 3000 [mm/s²] (default) acceleration_layer_0 = 3000 [mm/s²] (default) acceleration_prime_tower = 3000 [mm/s²] (default) acceleration_print = 3000 [mm/s²] (default) acceleration_print_layer_0 = 3000 [mm/s²] (default) acceleration_roofing = 3000 [mm/s²] (default) acceleration_skirt_brim = 3000 [mm/s²] (default) acceleration_support = 3000 [mm/s²] (default) acceleration_support_bottom = 3000 [mm/s²] (default) acceleration_support_infill = 3000 [mm/s²] (default) acceleration_support_interface = 3000 [mm/s²] (default) acceleration_support_roof = 3000 [mm/s²] (default) ...
which lists ~570 settings as of CuraEngine 4.4.1 and its defaults and from where the defaults come from (definition defaults, config or cli), and you can query also a term e.g. like ‘brim’:
% cura-slicer --help brim acceleration_skirt_brim = 3000 [mm/s²] (default) brim_gap = 0 [mm] (default) brim_line_count = 0 (config) brim_outside_only = 1 (default) brim_replaces_support = 1 (default) brim_width = 8 [mm] (default) jerk_skirt_brim = 20 [mm/s] (default) prime_tower_brim_enable = 0 (default) skirt_brim_line_width = 0.4 [mm] (default) skirt_brim_material_flow = 100 [%] (default) skirt_brim_minimal_length = 250 [mm] (default) skirt_brim_speed = 30 [mm/s] (default) support_brim_enable = 0 (default) support_brim_line_count = 20 (default) support_brim_width = 8 [mm] (default)
-v switch you even get a more descriptive output:
% cura-slicer --help brim -v == acceleration_skirt_brim (Skirt/Brim Acceleration) == The acceleration with which the skirt and brim are printed. Normally this is done with the initial layer acceleration, but sometimes you might want to print the skirt or brim at a different acceleration. acceleration_skirt_brim = 3000 [mm/s²] (default) == brim_gap (Brim Distance) == The horizontal distance between the first brim line and the outline of the first layer of the print. A small gap can make the brim easier to remove while still providing the thermal benefits. brim_gap = 0 [mm] (default) == brim_line_count (Brim Line Count) == The number of lines used for a brim. More brim lines enhance adhesion to the build plate, but also reduces the effective print area. brim_line_count = 0 (config) == brim_outside_only (Brim Only on Outside) == Only print the brim on the outside of the model. This reduces the amount of brim you need to remove afterwards, while it doesn't reduce the bed adhesion that much. brim_outside_only = 1 (default) ....
Essentially it makes Cura and CuraEngine easy to use on the command-line and provides a way to learn of the hundreds of settings available.
USAGE Cura-Slicer 0.0.7 aka Cura-CLI-Wrapper (CuraEngine 4.4.1): [<opts>] <file.stl> ... options: -v or --verbose increase verbosity -vv or --verbose=2 " " --version display version of this program and exit --load=<config> load config file --load <config> " " --output=<fn> set output filename --output <fn> " " -o <fn> " " --binary=<exe> set executable of CuraEngine (default: CuraEngine) --version=<v> set version of CuraEngine (default: 4) --<k>=<v> set CuraEngine settings (keys with '-' will be converted to '_') -h or --help display all settings -h or --help <term> .. display settings matching term examples: cura-slicer --help cura-slicer --help retract cura-slicer -hv retract cura-slicer sphere.stl cura-slicer overhang.stl --output=sample.gcode cura-slicer overhang.stl --layer-height=0.1 --support-enable=true -o sample.gcode
The user settings reside in
~/.config/cura-slicer/base.ini and will not be overwritten when upgrading
Cura-CLI-Wrapper, make your changes there.
The system-wide settings reside in
/usr/share/cura-slicer/base.ini and should not be be changed as it will be overwritten when upgrading
% cura-slicer cube.stl == Cura-Slicer 0.0.3 aka Cura-CLI-Wrapper (CuraEngine 4.4.1) == processing cube.stl, slicing to cube.gcode took 0.62 secs total, done. % cura-slicer --support-enable=true overhang-inout.stl == Cura-Slicer 0.0.3 aka Cura-CLI-Wrapper (CuraEngine 4.4.1) == processing overhang-inout.stl, slicing to overhang-inout.gcode took 0.99 secs total, done.
Whereever I used CuraEngine before in my existing software packages I will switch to Cura-CLI-Wrapper with
Just for sake of completeness a blog-post: I just released the source-code for Slicer4RTN. All developments will be documented there.
% slicer4rtn --subdivide=5 --recenter cube.stl == Slicer4RTN 0.4.5 == https://github.com/Spiritdude/Slicer4RTN 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 ./tmp-204390.gcode Done. Process took 0 minutes and 1.313 seconds Filament required: 758.4mm (5.4cm3) 5/5 remap gcode to 'cube.gcode' (18932 lines) == took 4 secs total, done.
When dealing with a lot of G-code it comes handy to have a small thumbnail preview in the file browser under GNOME, hence I coded this package.
It supports Slic3r, Prusa Slicer and Cura.
The package includes
gcode2png which can be used standalone as well.
USAGE gcode2png 0.0.7: [<opts>] <file.gcode> ... options: --version print version and exit --autolevel level Z minimum to 0 (default: off) --output=<fn> override .gcode -> .png conversion --size=<w>x<h> set size of image (default: 512x512) --rotate=<x>,<y>,<z> rotate model (default: 30,0,-20) --dist=<d> set distance multiplier (default: 1) --color=<r>,<g>,<b> set color (default: .1,.8,.1) --grid=0 or 1 set grid (default: 1) --grid_size=<s> set grid size (default: 10) --nozzle=<d> set nozzle diameter (default: 0.4) --complete=<i> set completeness: 0..1 or 0%..100% examples: gcode2png gcube.gcode gcode2png --output=cube-normal.png cube.gcode gcode2png --color=1,0,0 3DBenchy.gcode gcode2png --complete=50% 3DBenchy.gcode
I thought to compose a summary of the features of 3 types of 3D printers I currently work on, and its relations to print 90° overhangs – main motivation to go beyond 3-axis 3D printing:
A well tuned and well designed part-cooler is prerequisite to print conic-sliced models at cone angle of 20-25°, and currently there is no conic slicer which can properly segment sub-volumes yet (2021/03) to switch from horizontal- and conic-slicing (with two modes of outside/inside cone) where suitable.
Conic- or angled slicing is recommended in order to print with Rotating Tilted Nozzle (RTN) or post-processing of existing horizontal sliced G-code is required to provide additional Zrot information to print in good quality.
and nearly the same with PAX90 (tilt angle 0..90° only) with shorter arm:
A 5-axis Penta Axis (PAX) supports other slice methods than horizontal-, angled- or conic-sliced, but any variable build-orientation, but will make the slicing software very complex to recognize those sub-volumes suitable for advanced slicing methods.
This also means, a 5-axis PAX slicer with proper settings can produce G-code for 5-, 4- and 3-axis 3D printers with combining the horizontal-, angled- and cone slicing for sub-volumes or segments.
Slic3r 1.2.9 and Ultimaker Cura 4.8 as comparison:
slicer4rtnreleased, see announcement
slicer4rtn(not yet released)
slicer4rtnat 0.2.4 (still unreleased) resulting in better prints, blog-post linked at hackaday
slicer4rtnas disovered printing more complex pieces, supporting
prusa-sliceras well aside
slic3r, pushing the limits with overhangs
It has been target of many efforts to print 90° overhangs without support on 3-axis 3D printers as with ordinary Z slicing, each layer requires a support underneath; hence, every overhang then needs a support structure if the model itself doesn’t provide it.
But if . . . one slices non-planar? That’s what I thought about for a couple of years and kept it in the back of my mind. In January 2021 I came across Rotating Tilted Nozzle (RTN) aka RotBot as developed by ZHAW University of Applied Sciences Zurich (Switzerland). I began to design my own approach of the printhead and then started to code my own conic slicer
(slicer4rtn), as the paper which might explain it wasn’t published yet by ZHAW.
While reflecting on the output of the 4-axis conic sliced models, I thought what if I simply make the cone angle flatter than 45° but 15-25° so the vertical nozzle can print it?
A simple overhang model (nr 3) conic sliced at 25° for 0.4mm nozzle, 0.2mm layer height:
The same overhang model (nr 3) tilt sliced at 25° for 0.4mm nozzle, 0.2mm layer height (like with belt printer):
And on the afternoon of March 1st 2021 I ran my G-code for the first time on an ordinary 3-axis printer, a cheap CTC DIY I3 Pro B (Prusa-i3 like), in the attempt to print 90° overhangs, with a conic sliced overhang model:
Wow – it seems to have worked! There were still some issues, like the nozzle without extrusion moved into the print as I forgot map linear motions without extrusion also to conic coordinates as well, and some other minor things.
You may consider this a “backport” of 4-axis slicing procedure back to a 3-axis 3D printing procedure.
The print is still pretty ugly due to the obvious under-extrusion, but the geometry seems to work overall. The overhang on the left-front isn’t evenly, as the outer wall print speed is still too high.
Very clean print so far but the overhang is limited to one direction (see below of overall considerations).
Well, it works, but here are some limitations of using non-planar slicing:
slicer4rtndoes a simple/poor interpolation causing rough top surfaces (under- vs overextrusion)
slicer4rtn 0.1.2 (0.1.1 was broken)but often refuses to slice model, e.g. cube fails in inverted cone space
Trying out an overhang model which extends -Y and Y (as side-ways the part-cooler comes into the way)
There are still inconsistencies with extrusion calculation, but the prints getting cleaner.
Sample print comes soon as I need to redesign my part cooler so I can print this piece.
Long 40mm overhang, just 4mm thick extending nose . . .
Long 40mm overhang, just 2mm thin extending nose, let’s push the limits of what’s possible:
OK print so far, better than anticipated, but still a way to improve it. Reprint with a newer version of
Just trying more overhang, let’s see.
Obviously there is more than 95° overhang possible, so let’s try …
Even steeper overhang, let’s see.
This is truly promising, up to 100° overhangs printable with vertical nozzle as mounted on most 3-axis 3D printers . . .
As of the publication of this blog-post (2021/03) no slicer is available but
will be made available soon which was released 2021/03/22.
--angle=20is a good start, you may go as low as 15°, and perhaps at max at 30° depending on your nozzle and heatblock, if you aim to print 90° overhangs
--layer-height=0.2is a good start too, the thinner the layers the better overhangs can be printed
--erate=f as extrusion-rate tuning, whereas f = 0.5..1.5 or so, if you have to go below or above, something else is wrong.
slicer4rtndoes not yet support volume segmenting to support multiple centers
slicer4rtnrequires manually entered conic slicing center
--subdivide=5or higher for simple pieces, e.g. like a cube or low-poly models in generals
Following changes are recommended:
..with an actual number) to increase speed of Z-axis
Z6, or higher, so the motion speed comes close to X- and Y-axis to improve print quality
M203 Z8, 8mm/s => 8 revolutions/s => 1600 full steps/s: FAILED (blocked motor)
M203 Z6, 6mm/s => 6 revolutions/s => 1200 full steps/s: FAILED (stuttering motor at times, mechanical not reliable)
M203 Z4, 4mm/s => 4 revolutions/s => 800 full steps/s: OK
M203 Z3, 3mm/s -> 3 revolutions/s => 600 full steps/s: OK
--external-perimeter-speed=20%or a bit more, it prints overhangs better, leave it at
50%if prints look good
solid-infill-below-area = 10(make infill work at small(er) pieces too)