Category Archives: Technology

3D Printing: Diamond Hotend or Mixed-Color Deep(er) Dive

20190502_133621It has been a few weeks with the color mixing Diamond Hotend 3-in-1 (there is also an 5-in-1 option) – a few notes:


  • affordable, various sources available for 3-in-1 ~10-15 EUR (although the 5-in-1 only from 100-250 EUR)
  • simple setup with 3 (or 5) E3D V6 heatsinks and 3 (or 5) extruders with Bowden setup
  • lightweight mixing color approach using Cyan/Magenta/Yellow for 3-in-1 (plus Black/White for 5-in-1)


  • complex prints with a lot retraction voids proper mixing
  • mixing not perfect, depends on material and orientation (front and side might have different degree of mixing)
  • delicate heating procedure: keep it hot between prints or let it cool down to 50C before reheating to 180C or higher again
  • all 3 (or 5) filaments must be present to print even if they aren’t printed but provide resistance to pressure within the nozzle

Starting Properly: Building Up Pressure

Alike with single extruder, with Diamond Hotend one must build up pressure within the hotend so the print is successful:

20mm XYZ Hollow Calibration Cube: Left: No Pre-Pressure, Right: Pre-Pressure Preparation

This procedure worked for me:

  • extrude from each individual filament 15mm
  • extrude from all filaments together 10mm

The Gcode looks like this:

G91                    ; relative positioning
M165 A1                ; color A
G1 E15 F100            ; extrude 15mm
M165 B1                ; color B
G1 E15 F100
M165 C1                ; color C
G1 E15 F100
M165 A0.33 B0.33 C0.33 ; all colors each 1/3
G1 E10 F100            ; extrude 10mm
G90                    ; absolute positioning
G92 E0                 ; reset extruding position (to be sure)

Hue Wheel to CMY

Hue Wheel (Creative Commons CC)

Hue wheel is a simple way to remember the colors, and is part of Hue Saturation Lightness (HSL) representation covering entire human color spectrum (more natural than remembering RGB values).

  • h: 0 .. 360 degrees
    • 0 = red
    • 60 = yellow
    • 120 = green
    • 180 = cyan
    • 240 =  blue
    • 300 = magenta
  • s: 0 .. 1 (ignored)
  • l: 0 .. 1 (ignored)
function hsl2cmy(h,s,l) {
   r = ((h+180)%360)/360;
   c = r < 1/3 ? 1-r*3 : r >= 2/3 ? (r-2/3)*3 : 0;   // 1..0..0..1
   m = r < 1/3 ? r*3 : r <= 2/3 ? 1 - (r-1/3)*3 : 0; // 0..1..0..0
   y = r >= 1/3 && r < 2/3 ? (r-1/3)*3 : r >= 2/3 ? 1 - (r-2/3)*3 : 0; // 0..0..1..0
   return (c,m,y);

So, in case you use Cyan, Magenta and Yellow filament, you are able to cover some of the Hue wheel – I say “some” as getting Magenta filament seems not that easy – e.g. I used Glowing Magenta (less pigments) vs Rose/Magenta filament, here the two as comparison:

Glowing Magenta (top row) vs Rose/Magenta (bottom row)

A proper color space mapping is required, e.g. accounting the different pigment density and thereby consider the strength how one color might dominate another in the mixing.


Usually the first print of the day, cooling up from 15-20C room temperature, gives me not a good print, even using my pressure building Gcode, the 2nd and 3rd print color mixing becomes more reliable. Yet, as you can see, color blending/mixing isn’t fully consistent:


No 1 was 1st print heating up from 15C ambient to 205C – including pre-pressure preparation. No 2-4 were printed with nozzle kept at 205C and not cooling off.

Some wider strips also single layer about 0.25mm thick with 0.4mm nozzle printed with various extrusion multipliers (0.5 – 1.0x):

Single Layer Wide Strips with various extrusion multipliers: 0.5, 0.75, 0.9 and 1.0 printed at 0.25mm height and 0.4mm nozzle

Partial Mixing: Orientation Matters

top-viewLooking from the top of the Diamond Hotend, you have 3 (or 5) filament intakes, and in case of 3-in-1:

  • front (A)
  • back right (B)
  • back left (C)


diamond-hotend-sketch-with-filament-wkrand the following examples I use

  • white PLA (A/front),
  • black PLA (B/back right) and
  • red PLA (C/back left)

and you clearly see that color mixing is highly dependent on the orientation, using my xyz 20mm Hollow Calibration Cube printed with 0% infill, 2 perimeters, 0.4mm nozzle, 0.25mm layer height:

Front vs Side

Let me focus on three cases more detailed:

A=50% white, B=50% black

As you can see, white PLA fed 50% through A (front), gives the X face predominent white, whereas the black PLA fed 50% through B (back right) gives the “Y” face predominent black. Ideally, this cube should be mix 50/50 white/black, a shade of grey, but obviously isn’t. The same with red (C) and black (B):

B=50% black, C=50% red

although the mix in front of “X” face is ok, And looking at A (front) 50% white and C (back left) 50% red PLA:

A=50% white, C=50% red
Close Up: A=white 1/3, B=black 1/3, C=white 1/3

And looking at the 20mm Hollow Calibration Cube with A=0% white, B=50% black and C=50% red:

each side has another shade of red, even though 50/50 red/black is defined.

Another example with 50/50 cyan/yellow which should give green:

each side has another shade of green (the opposite sides of X or Y have a dot on the right upper corner for orientation).

Back Pressure: Delayed Color Change

diamond-hotend-sketch-with-filament-wkrThis issue is a bit more complex so let me explain in a few steps:

  • whenever a mix of filaments is pushed out, it pushes out of the nozzle, but also pushes partially back to the passive or non-printed filament(s)
  • eventually when the passive or non-printed filaments gets activated, a pushed back former mix comes out first, before the actual wanted filament(s) come out of the nozzle

Here the single layer mixing examples, where you can see it clearly:


The width of the strip is 20mm, length is 150mm, making A/B – B – C – A/C transition (equals to Hue wheel to CMY 0..360 degrees transition) where A=white, B=black and C=red PLA, you can see how long the transition is, 2-3 lines equals to 40-60mm printed, which is about 2-3mm filament (ratio is 20x: 0.4mm nozzle vs 1.75mm filament, calculating ratio with circular areas).

Possible remedy is to extrude all filaments with a minimum, e.g. 0.5%, 1%, 1.25%, 1.5%, 2% and 5% as examples:

Various Minimum Extrusion: 0%, 0.5%, 1%, 1.25%, 1.5%, 2% and 5%.

In essence you compromise the purity of the colors, but you gain cleaner color change.

So, if color change (without purge tower) is important for the print, and you don’t need pure colors, you may set the minimum for each involved filament to 0.5%, for example:

M165 A0.005 B1 C0.005

Note: If Marlin sees A+B+C > 1, and rescales all parameters to normalized sum of 1.0, I don’t know how other firmware behaves.

0% vs 0.5% Minimum: Hue Range with CMY filaments: with 0.5% the color change is softer, and back pushed color change delayed (green strip after the blue)

CYW & CYK instead of CMY

Some more tests, using white (W) and black (K) (Netco, purchased via Ebay) on the 3-in-1 to have some idea how 5-in-1 Diamond Hotend will behave:


White blends quite well to Yellow or Cyan, given the limitations of the Diamond Hotend as illustrated earlier in this post.


Black dominates very strongly and doesn’t seem to mix well: Dark Yellow didn’t work well as it seems the limited mixing shows Yellow and Black aside of each other; where as Dark Blue worked better.

Magenta Alternatives

Using Rose filament (Noveste, purchased via Ebay) as “Magenta” gives very good transitions with Cyan and Yellow, yet, no classic Red from the mix, which magenta would or should provide:

CMY transitions with Rose as “M”: 4 phases, Hue wheel, and Cyan/Yellow, Yellow/Magenta and Cyan/Magenta transition

Using Raspberry Rose filament (OWL Filament, Germany, purchased via Ebay) blended or mixed with Cyan and Yellow:

CMY transitions with Raspberry Rose as “M”: 4 phases, Hue wheel, and Cyan/Yellow, Yellow/Magenta and Cyan/Magenta transition

Quite good results with this single layer strip: so far much closer to red than before, rather deep saturated Orange, not quite Red, and when I printed calibration cubes, I saw the Raspberry Rose filament dominates Yellow and doesn’t properly mix: the change between Yellow and “Magenta” is rather abrupt:

Abrupt change between Yellow and Magenta (Raspberry Rose), due different pigment density.
20mm XYZ Hollow Calibration Cube, CMY transition (C=Bright Blue, M=Glowing Magneta, Y=Yellow; from Sienoc)

I will try to acquire better “Magenta” filament, as I haven’t achieved proper Red color by mixing Magenta and Yellow. The Cyan/Yellow mixing works quite well, given both filaments come from the same supplier (Sienoc), one who doesn’t provide Magenta unfortunately, only Glowing Magenta which blends well, but lacks strong color, too translucent.

That’s it.


3D Printing: Ashtar K #2 with Diamond Hotend (Multi-Color) with RAMPS 1.4


  • 2019/04/17: more photos of examples incl. macro closeups
  • 2019/04/15: 16 palette mixed colors from cyan, yellow and glowing magenta (CMY) photo added, best result of mixing colors
  • 2019/04/12: added Firmware Retraction changes in Marlin, updated Trinary Color Palette
  • 2019/04/10: initial post

I print with Ashtar K #1 and #2 since a couple of months and since about 4 months with Ashtar C #1 successfully, and thought to convert Ashtar K #2 (300×300 build-plate) with a Diamond Hotend with 3 colors/extruders, renamed to “Ashtar K E3“:


Producing stuff like this:


Cyan, Yellow, Glowing Magenta, Cyan Z-transition

Firmware (Marlin) & Hardware (RAMPS 1.4)

In the Marlin following settings are required:


#define EXTRUDERS 1

Counter intuitively using 3 extruders with single nozzle in mixing operations, keep EXTRUDERS 1 and do not enable SINGLENOZZLE but leave is disabled.


 * "Mixing Extruder"
 *   - Adds a new code, M165, to set the current mix factors.
 *   - Extends the stepping routines to move multiple steppers in proportion to the mix.
 *   - Optional support for Repetier Firmware M163, M164, and virtual extruder.
 *   - This implementation supports only a single extruder.
 *   - Enable DIRECT_MIXING_IN_G1 for Pia Taubert's reference implementation
  #define MIXING_STEPPERS 3        // Number of steppers in your mixing extruder
  #define MIXING_VIRTUAL_TOOLS 32  // Use the Virtual Tool method with M163 and M164
  #define DIRECT_MIXING_IN_G1    // Allow ABCDHI mix factors in G1 movement commands

Use E0 for Extruder #1, E1 for Extruder #2, and use an Stepper Extender for Extruder #3:




#define MIN_AUTORETRACT 0.1 // When auto-retract is on, convert E moves of this length and over
#define MAX_AUTORETRACT 10.0 // Upper limit for auto-retract conversion
#define RETRACT_LENGTH 3 // Default retract length (positive mm)
#define RETRACT_LENGTH_SWAP 13 // Default swap retract length (positive mm), for extruder change
#define RETRACT_FEEDRATE 45 // Default feedrate for retracting (mm/s)
#define RETRACT_ZLIFT 0 // Default retract Z-lift
#define RETRACT_RECOVER_LENGTH 0 // Default additional recover length (mm, added to retract length when recovering)
#define RETRACT_RECOVER_LENGTH_SWAP 0 // Default additional swap recover length (mm, added to retract length when recovering from extruder change)
#define RETRACT_RECOVER_FEEDRATE 8 // Default feedrate for recovering from retraction (mm/s)
#define RETRACT_RECOVER_FEEDRATE_SWAP 8 // Default feedrate for recovering from swap retraction (mm/s)


Add following lines below E1_CS_PIN:

#define E2_STEP_PIN 58
#define E2_DIR_PIN 57
#define E2_ENABLE_PIN 59
#define E2_CS_PIN -1

In case the Extruder #3 (E2) runs reverse, invert it in Configuration.h:

#define INVERT_E2_DIR true

Mixed Colors Prints

Two ways to print mixed colors:

  • M163/M164: define mixing ratio palette and define a virtual tool per mixing ratio which can be used as “T<n>” in Gcode later
  • M165: define mixing ratio right away

Virtual Tools Color Palette

Within ~/.config/print3r/printer/ashtar-k-2-e3.ini I added in start_gcode different palettes:

Trinary Palette

A general palette of 19 mixed colors using 3 colors defined in Gcode:

M163 S0 P1 
M163 S1 P0 
M163 S2 P0 
M164 S0

M163 S0 P0 
M163 S1 P1 
M163 S2 P0
M164 S1

M163 S0 P0 
M163 S1 P0 
M163 S2 P1
M164 S2

M163 S0 P1 
M163 S1 P1 
M163 S2 P0
M164 S3

M163 S0 P0 
M163 S1 P1 
M163 S2 P1
M164 S4

M163 S0 P1 
M163 S1 P0 
M163 S2 P1
M164 S5

M163 S0 P1 
M163 S1 P1 
M163 S2 P1
M164 S6

M163 S0 P2 
M163 S1 P1 
M163 S2 P0
M164 S7

M163 S0 P2 
M163 S1 P0 
M163 S2 P1
M164 S8

M163 S0 P2 
M163 S1 P1 
M163 S2 P1
M164 S9

M163 S0 P1 
M163 S1 P2 
M163 S2 P0
M164 S10

M163 S0 P0 
M163 S1 P2 
M163 S2 P1
M164 S11

M163 S0 P1 
M163 S1 P2 
M163 S2 P1
M164 S12

M163 S0 P1 
M163 S1 P0 
M163 S2 P2
M164 S13

M163 S0 P0 
M163 S1 P1 
M163 S2 P2
M164 S14

M163 S0 P1 
M163 S1 P1 
M163 S2 P2
M164 S15

M163 S0 P2 
M163 S1 P2 
M163 S2 P1
M164 S16

M163 S0 P2 
M163 S1 P1 
M163 S2 P2
M164 S17

M163 S0 P1 
M163 S1 P2 
M163 S2 P2
M164 S18

After that, the virtual tools T0 – T18 are available, printing different mix ratios.

Full Saturated True Color (Hue) Palette

The following (source) defines 16 different mix ratios of common colors with Cyan, Yellow and Magenta:

; Cyan
M163 S0 P1
M163 S1 P0
M163 S2 P0
M164 S0

; Ocean
M163 S0 P5
M163 S1 P1
M163 S2 P0
M164 S1

; Blue
M163 S0 P1
M163 S1 P1
M163 S2 P0
M164 S2

; Violet
M163 S0 P1
M163 S1 P5
M163 S2 P0
M164 S3

; Magenta
M163 S0 P0
M163 S1 P1
M163 S2 P0
M164 S4

; Raspberry
M163 S0 P0
M163 S1 P5
M163 S2 P1
M164 S5

; Red
M163 S0 P0
M163 S1 P5
M163 S2 P1
M164 S6

; Orange
M163 S0 P0
M163 S1 P1
M163 S2 P1
M164 S7

; Yellow
M163 S0 P0
M163 S1 P0
M163 S2 P1
M164 S8

; Spring Green
M163 S0 P1
M163 S1 P0
M163 S2 P5
M164 S9

; Green
M163 S0 P1
M163 S1 P0
M163 S2 P1
M164 S10

; Turquoise
M163 S0 P5
M163 S1 P0
M163 S2 P1
M164 S11

; Cyan-Brown
M163 S0 P2
M163 S1 P1
M163 S2 P1
M164 S12

; Magenta-Brown
M163 S0 P1
M163 S1 P2
M163 S2 P1
M164 S13

; Yellow-Brown
M163 S0 P1
M163 S1 P1
M163 S2 P2
M164 S14

; Brown
M163 S0 P1
M163 S1 P1
M163 S2 P1
M164 S15

After that, the virtual tools T0 – T15 are available, printing different mix ratios.

I used following code to purge 30mm (10+10+10mm) filament from all 3 colors at once at the very beginning (start_gcode):

M165 A0.33 B0.33 C0.33  ; 1/3 for each filament
G92 E0
G1 E30 F100     ; extrude 30mm
G92 E0

Additionally, define the firmware retraction:

M207 F3000 S4 Z0.3   ; set firmware retraction 50mm/s 4mm, 0.3mm zhop
M209               ; use firmware retraction


For test purpose I have:

  • Extruder 1 (E0 or A): glowing magenta PLA
  • Extruder 2 (E1 or B): violett PLA
  • Extruder 3 (E2 or C): white PLA

As such I prepared 16x 20×20 plates with 1 layer height:

print3r --printer=ashtar-k-2-e3 --slicer=cura --random-placement --scad --multiply-part=16 --output=plates-16.gcode slice 'cube([20,20,0.2])'

which gave me plates-16.gcode which I edited and inserted the “16 colors palette” Gcode, and after each “WALL-INNER” lines I added T0, T1 etc. T15 to switch to another tool (mixing colors ratios) for each plate:

There is no purge block, but I wanted to see how fast the switch is possible. Some issues are once the mix changes the first 10-20mm extrusion may come out under-extruded.

16 mixed colors from 3 colors (Glowing Magenta, Violet, White)
16 mixed colors from 3 colors (Light Blue/Cyan, Yellow and Glowing Magenta)

With light-blue/cyan, yellow and glowing magenta gave decent results: the green turned out well, the orange as well, even the violet and darker blue came out well.

And finally some cubes with 2- and 3-color transitions in the Z axis:


where I used print3r directly, using --layer-gcode=... feature (I just added 2019/04/10):

2-color 2 phases: use variables a2 (fades 1..0), and b2(fades 0..1):

  • fade A->B: '--layer-gcode=M165 A${a2} B${b2}'
  • fade B->C: '--layer-gcode=M165 B${a2} C${b2}'
  • fade A->C: '--layer-gcode=M165 A${a2} C${b2}'
Violet to White, Glowing Magenta to White Z-transition

3-color 3 phases: use variables a3 (fades 1..0 first half), b3 (fades 0..1..0), and c3 (fades 0..1 for second half):

  • fade A->B->C: '--layer-gcode=M165 A${a3} B${b3} C${c3}'
  • fade A->C->B: '--layer-gcode=M165 A${a3} B${c3} C${b3}'
Glowing Magenta, White, Violet and Cyan, Yellow, Glowing Magenta Z-transition

3-color 4 phases: use variable a34 (1..0..0..1), b34 (fades 0..1..0..0) and c34 (fades 0..0..1..0)

  • fade A->B->C->A: '--layer-gcode=M165 A${a34} B${b34} C${c34}'
  • fade A->C->B->A: '--layer-gcode=M165 A${a34} B${c34} C${b34}'
Cyan, Yellow, Glowing Magenta, Cyan Z-transition
Cyan, Yellow, Magenta, Cyan Z-transition: Cyan, Green, Yellow, Orange, Pink/Magenta, Violet, Blue

Partial Mixing

20190410_200839At closer inspection, the Diamond Hotend doesn’t perfectly mix the filament:

  • left/back: white PLA
  • front/center: glowing magenta PLA
  • right/back: violet PLA


Now, let’s rotate the XYZ Hollow Cube around the Z axis:

In front with “X” the violet prominently comes soon, the “Y” (right-hand side) looks OK, whereas the back side the white/violet transition is not smooth, the same for the left-hand side.


Quickly after trying more complex and longer prints, I experienced filament jamming:


I chose Violet -> Magenta -> White Z-axis transition, and the jamming occured with the Magenta PLA about 5-6min after the start, not always the same height; I tried several things like feeding a minimum of 5% of each filament, but then lower the print temperature from 205C to 198C, and things worked:

LowRes-Minecraft and LowRes-LowPoly Easter Eggs (35mm height, 0% infill, no support)

I print with first layer (layer 0) 210C usually on cold bed, and dropping to 195C for the rest usually let the nozzle temperature sink below 190C, sometimes even 185C before reaching 195C again due the thermal mass of the Diamond Hotend, and below 190C risk of under extrusion is high (layer 2-3), therefore I now use 195-198C to limit that risk.

It’s recommended to increase printing temperature with Diamond Hotend to achieve better mixing of the filament, yet, it seems also increases the risk of clogging/jamming of filament as in my case. Although, I currently use an 40mm fan on top of the Diamond Hotend instead of 50mm fan – the heatsinks left/back and right/back are warm, whereas the center/front (with magenta) is cooler. So, I might use a bigger fan and see how things behave then.

That’s it.

CAD: CSG Operation exclusive()

Historically Constructive Solid Geometry (CSG) covers three main boolean operations:

  • union
  • difference
  • intersection

like with Set Theory or more known when using Venn diagrams.

Brian Spilsbury started to look at 3D meshes for his JSxCAD library and how to process them: much closer to actual use cases of composing solids together and incorporate physical reality that two solids cannot occupy the same space at the same time while still unite or combine their shapes somehow.

He came up with the concept disjointed assembly of solids, which has the advantage of preserving the solids integrity in order to maintain individual information of material or colors per solid, and only change their shapes to align seamless to each other.

Disjointed Assembly or Exclusivity

The disjointed assembly or exclusive series of a, b and c like

a = sphere().color(red)
b = cube(1.5).color(green).translate([0.5,0.5,0.5])
c = cube(1).color(blue).translate([0.5,0,0])

may be written as

exclusive(a,b,c) = [ difference(a,b,c), difference(b,c), c  ]

The parts no longer intersect any space of each other, and seamlessly can be fused now together. The order of such exclusivity matters now: the first solid in line is changed by all succeeding solids, and each next solid in the disjointed assembly the same, whereas the last solid remains untouched, hence, exclusivity with ascending order, the last dominates most.

Alternatively, exclusivity with descending order:

exclusive(a,b,c) = [ a, difference(b,a), difference(c,b,a) ]

and then a remains untouched, and all succeeding parts are dominated by the preceding ones.

While union(), difference() and intersection() are base functions handling solids, exclusive() introduces a lightweight approach to handle grouping of multi-material CSG solids by having the parts accessible individually afterwards.


Last update 2019/04/19:

  • OpenSCAD:  exclusive() may be written as a module:
module exclusive(order="asc",explode=[0,0,0]) {
   for (i = [0:1:$children-1]) 
            difference() {
            difference() {

exclusive(explode=[3,0,0]) {
   color([1,0,0]) sphere($fn=32);
   color([0,1,0]) translate([0.5,0.5,0.5]) cube(1.5,center=true);
   color([0,0,1]) translate([0.5,0,0]) cube(1,center=true);

Screenshot from 2019-04-19 10-45-31

  • OpenJSCAD: not yet, you can easily write a function to handle an array of solids, and creates difference() operations to each other.
  • JSxCAD: assembly() with ascending order implied, means, the last object is most dominant.
  • Unreleased/Unnamed CAD (which I currently work on 2019/04): exclusive() available, with optional last argument options with order: either "asc" (default) or "desc" like:
    • exclusive(a,b,c);
    • exclusive(a,b,c,{order:"desc"});

Screenshot from 2019-04-10 08-48-11

That’s it.

3D Printing: Print3r 2.x: Networked Printing

A brief post of my local network for 3d printing with several 3d printers, using print3r CLI (Command Line Interface) tool.


Physical Setup

20190302_164919Orange Pi Zero (single board ARM-based computer) named printhub running Armbian (Debian-like).

  • Ethernet Port connecting to Ethernet/Wifi Hub with its own subnet (192.168.4.x)
  • External USB 4x Hub connecting 3d printers via USB:
    • Ashtar K 1 (Prusa i3-like, 400 x 300 build plate, 330mm height), 0.5mm nozzle (/dev/ttyUSB2)
    • Ashtar K 2 (300 x 300 build plate, 330mm height), 0.4mm nozzle (/dev/ttyUSB1)
    • Ashtar C 1 (CoreXY, 400 x 400 build plate, 380mm height), 0.4mm nozzle (/dev/ttyUSB0)
    • CTC DIY I3 Pro (Y3228), 0.4mm nozzle (/dev/ttyUSB3)

The workstation from which I print from (design and slice) is also connected via Ethernet. The printed violet PLA case I published a while ago on Thingiverse: Orange Pi Zero Case.


On printhub (Orange Pi Zero) starting all the network clients processes:

% print3r /dev/ttyUSB0 client &
% print3r /dev/ttyUSB1 client &
% print3r /dev/ttyUSB2 client &
% print3r /dev/ttyUSB3 client &


On my workstation (a laptop), referencing printer profiles and devices:

% print3r --device=tcp:printhub:0 --printer=ashtar-c-1 print cube.stl
% print3r --device=tcp:printhub:1 --printer=ashtar-k-2 print cube.stl
% print3r --device=tcp:printhub:2 --printer=ashtar-k-1 print cube.stl
% print3r --device=tcp:printhub:3 --printer=y3228 print cube.stl

See Print3r Wiki: Remote Printing for more details.

The CTC I3 Pro B Y3228 low cost printer still runs Marlin 1.0 and 250,000 baudrate which won’t work with ser2net which print3r uses internally to print in network environment, so it needs to be flashed first with newer firmware, so it can be networked as well with common baudrate like 230,400. I upgraded the ~1 year old “CTC DIY I3 Pro B” 3d printer to Marlin 1.1.8 finally, first burning a bootloader with an Arduino Uno, and then properly configured Marlin, and now runs with 115,000 baudrate as well, so it can be networked as well.

Otherwise I stopped using Cura GUI or Slic3r GUI completely, and solely use print3r to first preview the Gcode, sliced with CuraEngine or Slic3r, and then print the parts, and because it runs on the command line, all the previous calls in the terminal are stored as history therefore I can scroll back (cursor-up/down) and repeat a job with slightly changed settings by editing the command line – something which GUI doesn’t offer, unless you save a printjob as .3mf and reload it and click around and change settings and save again as .3mf etc.

Command Inline OpenSCAD

Further, I often code OpenSCAD code directly with print3r for simple parts, e.g. caps for M6 threaded rods, something like:


% print3r --device=tcp:printhub:0 --printer=ashtar-c-1 --random-placement --scad print 

and if the print came out well, I add --multiply-part=3 or so.

Download & Install Print3r


That’s it for now.


3D Printing: Ashtar C Printer: 1st Prints

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


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


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

residing on 2020 T-slot alu extrusions.

Z Axis

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




Following challenges came up in the first test prints:

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


That’s it for the moment.

3D Printing: Ashtar C Printer: CoreXY Belt Routing

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

Belt Routing

CoreXY belt routing of Ashtar C

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

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



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

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

and X and Y direction worked correctly.

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

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

X & Y Endstops

The preliminary positions of the endstop are:

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

Z Axis

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

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


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

3D Printing: OpenSCAD Sketches #1

A few OpenSCAD sketches I’m currently work on, and later will publish as well:

Simple Compact Extruder

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 and adapted the overall design but coded it from scratch again:


It’s “right handed” by default, but filament can go both directions. The handle is pushed from “inward” 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.

simple_compact_extruder() takes following parameters:

  • type:
    • "base": the base attached to the Nema 17 stepper motor
    • "handle": the push handle with the spring
    • "indicator": small indicate 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: 0mm), if 4mm is used, then Bowden tube can be inserted on both sides as guides for flexible filament close to the hobbed gear as shown below.

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:

Later I likely will integrate this design, once proven reliably working, with a Direct Drive Extruder design as well.

Dual E3D V6 Mount on 30mm X Carriage

My X carriage maintains 30mm horizontally distanced M3 mounts x 3 rows 20mm apart – the v_plate() (3 wheels) and h_plate() (4 wheels) as example:

and wanted a parametric dual E3D V6 hotend mount to print dual colors or materials for the Ashtar C #1:


dual_e3d_mount(): there are plenty parameters, but the most important ones:

  • type: "base" (left) or "clamp" for the clamp (right)
  • yoff: Y offset (when mounted the Z offset up), default: 0 (front one), 20 (middle and top)
  • nd: nozzle distance (Y-wise), default: 22 (most close possible), 35 (top one)


First attempt to use it:

This design has been not yet printed but not yet in use, but soon as alternative to Chimera (dual hotends) or Cyclops (dual to one / mixing) hotends – two main issues:

  • part cooler needs to be narrow enough to sit aside of each other
  • part cooler should extend too much Y-wise too much, as the routing belt of the Ashtar C come into the way

The “Dual E3D V6 mount” was derived from preview designs as used for the Ashtar K:

The first one used two pairs of M3 screws, whereas the other more simple one requires in its base version just one pairs of M3 to mount the E3D V6 hotend and the mount itself to the X carriage; in case a slight Y offset is used, two pairs of M3 are required again.


I will update this post once the designs are published, after thorough testing in real life.

3D Printing: Ashtar K Printer: Electronics


  • 2018/12/05: added MKS Gen L as alternative, for Ashtar C #1
  • 2018/11/25: added RAMPS 1.4 as alternative, for Ashtar K #2
  • 2018/08/28: initial version with CTC DIY I3 Kit

Sourcing Parts

The past months (2018/08) I began to use Aliexpress for ordering electronics – even prior going into 3d printing – and the past weeks my development cycles pretty much were depending on the 20-25 days delay until items arrived from China to Switzerland – and one develops some skill to anticipate what one would require as next – but some things only become known once you really tested parts thoroughly.

Anyway, the CTC DIY I3 Pro B (Geeetech DIY I3 Pro B clone) was still sold via Ebay (2018/08), at a price as low as EUR 80 incl. shipment, which is a true bargain.

Aliexpress (2018/08):

  • MKS Gen L mainboard (incl. drivers) with LCD (with dialer), 200×200 heatbed, end stops, cables: EUR 50
  • PSU 12V 240W: EUR 20
  • 5x Nema 17 45Nm stepper motors: EUR 35
  • Total: EUR 105 (without endstops and various cables to connect all together)

CTC DIY I3 Pro B Kit (2018/08):

  • Anet 1.0 mainboard, with 2 Lines LCD (4 buttons), 200×200 heatbed, end stop, cables, PSU 12V 240W, 5x Nema 17 45Nm stepper motors
  • Total EUR 80 (all cables included)

So I decided to get another CTC DIY to source the parts in one go, and likely upgrade later with individually sourced parts to have dual extruder motors (two color or material printing).

In 2018/11, when I started to build a second Ashtar K 38x30x33 #2 I checked Ebay with following prices:

Ebay (2018/11):

  • MKS Gen L: EUR 28
    • MKS Gen L mainboard: EUR 16
    • 5x A4988 drivers: EUR 6
    • RepRap Full Graphic LCD: EUR 11
  • RAMPS 1.4 with Arduino Mega, 5x A4988 drivers, Full Graphic LCD: EUR 28
  • 5x Nema 17 40-50Nm stepper motors with cables: EUR 26-35
  • PSU 12V 240W: EUR 20
  • Total EUR 74 – 83 (missing: endstops and various cables to connect all)

Burning Bootloader on Anet 1.0 Board

For now I use an “Anet V1.0” controller board (Atmel 1284P), as part of a “CTC DIY Kit” as mentioned, and it required some preparation:

  1. using Arduino Uno R3 (clone) and upload “Arduino ISP”
  2. attach Anet V1.0 board (detach all other cables) to Uno R3 bootloader-burning
  3. run “Burning Bootloader” with “Arduino as ISP” as writer
  4. downloading Marlin and edit main Configuration.h (not yet published) to match my specifications
  5. upload new firmware Marlin to “Anet V1.0” via USB upload

RAMPS 1.4 with RepRap Discount Full Graphic LCD

RAMPS 1.4 Schematic + PinoutFor the 2nd Ashtar K 3D Printer I used (2018/11) RAMPS 1.4 combo with Arduino Mega, which was easy to upload new firmware. RAMPS 1.4 is Open Hardware, the entire schematic and pinout is available or download diagram with pinout as one image (same as on the side) – but it’s also a hassle to plug correctly as the board plug descriptions are tiny or covered by parts so one has to consult documentation in details, and there many ways to do wrong (reverse or misalign plugs) and most of these can and do damage either the RAMPS 1.4 shield and/or the Arduino Mega beneath, including misaligning the endstops.


  • using C and NC on the endstop and the board (power connector on the left) above the 2x Z motor connectors: XMIN, XMAX, YMIN, XMAX, ZMIN, XMAX, each:
    • top (Signal) -> C
    • middle (Ground) -> NC
    • bottom (5V) -> empty

while waiting for proper endstops to arrive, I salvaged microswitches from a faulty computer mouse to work as endstops

Marlin Firmware Changes

  • Configuration.h:
  • Configuration_adv.h:
    • commented out #define MENU_HOLLOW_FRAME so selected item is inversed
  • pin_RAMPS.h:
    • see #if ENABLED(REPRAP_DISCOUNT_SMART_CONTROLLER) and the following #if ENABLED(CR10_STOCKDISPLAY) after the #else check BTN_EN1 and BTN_EN2 and reverse the pins (31 <-> 33) so clockwise dialing goes down (and not up).



  • Configuration.h:

As far I can tell the end-stops take DuPont females and pin order is the same as with RAMPS 1.4, but orientation is crucial – otherwise the GND and VCC is shorted.

The plan is to use this board for Ashtar C #1.


I update this post as I go along.

3D Printing: Print3r 0.1.6 Release

Following major changes of 0.0.9 to 0.1.6 regarding Print3r (command line tool for 3d printing):

Multiple Slicers Support

Now print3r natively supports 4 different Open Source slicers:

  • Slic3r (slic3r)
  • Slic3r PE (Prusa Edition) (slic3r-pe)
  • CuraEngine Legacy (15.04) (cura-legacy)
  • CuraEngine (3.5.x) (cura)

which can be set with --slicer=<slicer> on the command line.

Slicer Independent Settings

Starting with 0.1.0 print3r provides a slicer-independent layer with a growing list of settings:

  • temperature
  • nozzle-diameter
  • filament-diameter
  • bed-temperature
  • etc.

Full list of settings you find at Print3r Github Wiki.

Slicer Specific Settings

Yet, if you must, you can still use slicer-specific settings to fine-tune settings according your print needs and printer capabilities.

Macros (other Profiles)

For often used settings like print quality, or filament settings, you can gather those settings and reference them in the command line like:

% print3r @filament/prusament @thin @hollow cube.scad

Quality Presets:

  • @coarse
  • @medium
  • @fine

Infill/Wall/Perimeter Presets:

  • @heavy
  • @light
  • @feather

OpenSCAD Integration

print3r already supported to print or slice .scad files,

% print3r print cube.scad

and now since 0.1.6 also following command line code integration is possible:

% print3r --scad print "cube(20)"
% print3r --scadlib=washer.scad --scad print "washer(5)"
% print3r --scadlib=parts.scad --scad "c_2020()" "edge_idler()"

Arbitrary Baudrate

Since 0.1.0 also arbitrary baudrate like 250000 (default of Marlin) is supported (Linux only, other platforms not yet), aside the common 115200.


As external Gcode viewer for preview command yagv is used, a very basic viewer – at a later time it might be replaced.

% print3r preview cube.scad

which converts, slices and preview the Gcode.

Extensive Documentation

Since the functionality of print3r is growing steadily, the requirement for proper documenation demanded its own Print3r Wiki where you find up-to-date information.


3D Printing: Networked Printing with Print3r

Note: The information is outdated as print3r natively supports networked printing, see 3D Printing: Print3r 2.x: Networked Printing (2019/02/27), but this information is still useful bridging USB to TCP in general.


The moment you deal with more than one single 3d printer, but multiples – you want to access those with a single host: creating a cloud 3d printing facility.

After a few minutes researching the net for USB to network bridge, I realized the overhead to print via network is possible without Octoprint or some other solution, but simple ser2net and socat alone, thanks to this Github Issue by Marco E explaining his steps, so I reiterate his solution with some changes:

  • create USB to network bridge with ser2net per printer
  • create network to virtual serial per printer with socat on the host


Each printer you like to network has to have:

  • Linux OS (like Debian, Ubuntu or alike), e.g. Raspberry Pi or OrangePi or any kind of lowcost ARM-based board
  • USB connectivity where the 3d printer is wired
  • Wi-Fi (wireless) or Ethernet (wired) connectivity


As next install ser2net serial to tcp bridge per printer:

% sudo apt install ser2net

Create a file named client.cfg, you may have to change the baudrate and/or the USB device:


Start ser2net on each printer:

% ser2net -c client.cfg


As next prepare the host, where all the printers will be controlled from:

  • UNIX OS like Linux (Debian, Ubuntu, *BSD, macOS should work too)
  • Wi-Fi (wireless) or Ethernet (wired) connectivity
  • Print3r


First make sure you have socat installed:

% sudo apt install socat

For each printer you are creating network back to (virtual) serial port – replace with the IP of your printer(s):

% socat -d -d pty,raw,echo=0,b115200 tcp:
2018/10/07 10:08:16 socat[31821] N PTY is /dev/pts/29
2018/10/07 10:08:16 socat[31821] N opening connection to AF=2

The first line reports the new virtual serial port, e.g. /dev/pts/29  or enforce a link of the new device:

% socat pty,raw,echo=0,b115200,link=/tmp/my-printer tcp:

you can reference /dev/pts/... or the link you defined with Print3r then:

% print3r --device=/tmp/my-printer --scale=2 --random-placement --fill-density=0 --perimeters=1 print xyzHollowCalibrationCube.scad
== Print3r 0.0.8 ==
print3r: conf: device /tmp/my-printer, bed 380x300mm, nozzle/d 0.5mm, layer/h 0.4mm, filament/d 1.75mm
print3r: scad to stl: done.
print3r: slice part to gcode: position 272,118, filament usage 2.38m, done.
print3r: print: 0h 03m elapsed, eta 0h 16m, 18.9% complete, z=0.60mm, layer #2, filament 0.42m

So you end up with something like this:


So, that’s it, with ser2net on the printers, and socat on the host you have a rather simple and straight-forward cloud 3d printing facility.

I likely will extend Print3r to support networked printing with a simple all-in-one setup. Implemented since Version 2.0.0, see 3D Printing: Print3r 2.x: Networked Printing.


  • 2018/11/01: there is a slight drawback using ser2net: only takes common baudrates, but doesn’t support 250,000 which is the default baudrate for Marlin, 115,200 does work though. So, in case you plan to use ser2net reflash the firmware to use 115200 as baudrate.