Sunday, 12 April 2015

Duex4 V0.2a - Minor Updates

I have made a slight revision to the Duex4 v0.2 4 extruder expansion board for the Duet 3d printing electronics, the revised design is the Duex4 v0.2aThe revision is to add analogue GND to the expansion board input header connected by either a fly lead (Duet v0.6) or directly (later Duet versions).

Analogue GND should have been used from the beginning but I left it out by mistake. This omission lead to noisier temperature readings on the expansion board than on the Duet (as documented, with a fix, by David Crocker). This was annoying but I did not see a drop in performance as the thermal mass of the hotends was enough to cancel out any temperature swings commanded by this noise. None the less it needed to be fixed, but in a way that allowed the Duex4s to still be compatible with the Duet 0.6 expansion header.

In the schematic you can see that pin 39 of the expansion header how connects to a jumper, and then on to VSSA (analogue GND) within the expansion board.

AD 12 used to be on pin 39 however it will be used later Duet versions for the probe input on a header on the main duet board.

This allows for analogue GND to be fed in via pin 2 of the header on a Duet v0.6 or for a jumper to be used on later duet boards.The pictures below show the Duet v0.6 and Duex4 v0.2a with the analogue GND fly lead connected to the heated bed thermistor GND.

This fly lead can also be connected to the hotend thermistor ground screw terminal:

or VSSA Pin 38 on the 40 pin motor loom header:

All V0.2a Duex4s will be supplied with the necessary fly-lead for hooking up the analogue GND as described above.

The updated KiCAD source files are available on our Github, licensed under the CERN OHL v1.2

Sunday, 8 February 2015

RepRapFirmware config files

Unlike Marlin and most other firmwares, RepRap Firmware does not require recompilation for different printers. The changes that you would normally make to configuration.h in Marlin are now all made with gcode. At the most basic level you can type gcode commands into pronterface each time you want to setup the printer - however that would quickly get very tedious. Instead the printer configuration is set within /sys/config.g on the SD card.

This tutorial will walk through the common parts of config.g for a Mendel90 style printer with dual extruders. If you have a single extruder printer then the comments will highlight what to leave out. It is assumed you are using DC42's fork of the RepRap Firmware and was written while version 1.00f was the most current version.

It is helpful if you refer to the gcode page on the reprap wiki as you follow along.

The order of the commands is not always strictly important however in some cases it is, for example you should define your tools before setting their offsets.

Gcode format

in general gcodes are formatted in the following manner:

[gcode_letter][number] [switch][information] [switch][information]


G1 X10 F3000

So its a "G" command, number "1", with the first switch being "X" with the information "10", the second switch being "F" with the information "3000". This command moves (G1) 10mm in X (X10) at 3000mm/m (F3000)

Another example is

M550 PMendel90 

Where The command is an "M" command, with the switch "P" and the information "Mendel90". This sets the printer name to "Mendel90".

Name and Networking

Much of this is similar to the RepRap Ormerod at this point as it is the same for most machines:

; Configuration file for Mendel90 Example
M111 S0                             ; Debug off
M550 PMendel90                      ; Machine name (can be anything you like)
M551 Preprap                        ; Machine password (currently not used)
M540 PBE:EF:DE:AD:FE:ED             ; MAC Address
M552 P192.168.1.14                  ; IP address
M553 P255.255.255.0                 ; Netmask
M554 P192.168.1.1                   ; Gateway
M555 P2                             ; Set output to look like Marlin
G21                                 ; Work in millimetres
G90                                 ; Send absolute coordinates...
M83                                   ; ...but relative extruder moves

You should set the IP address to be within the same subnet as your network, and not to an address that could be allocated to something else (eg, outside of your DHCP range). The MAC address should not be the same as one already on your network.

M83 sets the extruder to relative extruder moves which is intuitive when sending gcode commands by hand to move the extruder - for example when doing calibration. Cura (and Slic3r by default) expect gcodes to be absolute, rather than relative so I add M82 to the start.gcode to ensure when printing the firmware is in absolute gcode mode.

Set Axis and drives

;axis & drives setup
M906 X800 Y800 Z800 E800:800  ; Motor currents (mA) (Extruder set below)
M92 X80 Y80 Z4000             ; axis steps/mm
M92 E649:639                  ; Set extruder steps/mm
;set axis/drive directions
M569 P0 S1                    ;x axis +'ve
M569 P1 S0                    ;y axis -'ve
M569 P2 S0                    ;z axis -'ve
M569 P3 S0                    ;E0 drive -'ve
M569 P4 S1                    ;E1 drive +'ve
M201 X800 Y800 Z15 E2000            ; Accelerations (mm/s^2)
M203 X15000 Y15000 Z180 E3600       ; Maximum speeds (mm/min)

M566 X600 Y600 Z30 E20              ; Minimum speeds mm/minute

The Duet and Duex4 have digital control of the stepper current - this is set with M906, note the extruder parameter is delimited with a colon ":", this allows for different currents to be set of each extruder drive. This same delimitation is used for M92, allowing different extruder steps/mm to be set for each drive.

M569 sets the axis direction, in this example the printer is wired up in such a manner that X and E0 move in the +'ve direction when a positive movement is send, however Y,Z and E1 move in the negative direction. To correct that the switch "S0" is used, after this command a positive movement to Y,Z or E1 will move them in a positive direction.

M566 is the minimum or instantaneous speed change numbers, they are referred to as X,Y or E Jerk in Marlin. In all these cases I have used a single number for E, that sets the same for all extruders. if your extruders have different designs then you may want to set different speeds and accelerations for each one.

Thermal Settings

;Thermal Settings
M305 P1 R1000 B4267.0          ;1K bias resistor, B value  for Semitec 104-GT2
M305 P1 T100000                ;100K thermistor
M305 P2 R1000 B4267.0          ;1K bias resistor, B value  for Semitec 104-GT2
M305 P2 T100000                ;100K thermistor       
M305 P0 R1000 B4540            ;1K bias resistor,B value for Epcos B57861S104F40
M305 P2 T100000                ;100K thermistor  
M140 S0 R0                     ;set the bed to "0,0" at start up

M305 sets the heater thermistor information. P1 = hotend 0, P2= hotend 1, P0 = Heated bed. R1000 = a 1K bias resistor, if you are using a RepRapPro Duet then use R4700 as they use a 4.7k bias resistor. T100000 = 100K @25C thermistor. Finally all heaters are set to -273C by default so the M140 sets the bed to 0 active, 0 standby at startup which helps when using a control panel such as the PanelDue to control the printer. The hotend stat values are set later.

Define Tools

M563 P1 D0 H1                       ; Define tool 1
M563 P2 D1 H2                       ; Define tool 2
M563 P3 D0:1 H1                     ; Define tool 3

RepRap Firmware modifies the concept of a "Tool". No longer does the tool change commands "T0", "T1" etc, select an extruder drive and hotend combination that is designed into the printer with no easy way to change it, other than change the hardware. A tool now consists of any number of extruder drives, and heater combinations. The first line above

M563 P1 D0 H1                       ; Define tool 1

defines a tool (number 1, "P1")  that uses drive 0 (the first extruder drive, E0), and the second heater ("H1"). It is important to remember that the Heated Bed is the first heater configured in firmware, so the extruder 0 heater is H1. In a similar manner the second line

M563 P2 D1 H2                       ; Define tool 2

defines tool number 2 which uses the second drive (D1) and the third heater, which is the E1 heater (H2).

The third tool define is where it gets interesting and shows off the potential power of this method of defining tools.

M563 P3 D0:1 H1                     ; Define tool 3

This defines tool 3 to use both drive 0 and drive 1, but just heater 1. This sort of tool would fit a hotend like e3d's Cyclops.

Set offsets

RepRap Firmware can use G10 to set temperature and position offsets.

G10 P1 S0 R0                        ; Set tool 1 operating and standby temperatures
G10 P2 S0 R0                        ; Set tool 2 operating and standby temperatures
G10 P2 X18                          ; Set tool 2 offset on X axis

The first line sets the active and standby temperature of Tool 1 to 0, the second does the same for tool 2. The third sets the X offset to +18 for Tool 2, the second nozzle on an e3d Chimera is in line on Y but +18 on X, an alternative would be:

G10 P2 X-9                          ; Set tool 2 offset on X axis
G10 P2 X9                          ; Set tool 2 offset on X axis

Which would keep the hotends centered around 0,0 - better for a delta printer.

That concludes the config.g settings required for a standard cartesian printer.

Other files within the /sys/ directory

The concept of using gcodes to perform all printer functions, rather than precompiled routines extends to homing, probing and tool changes. Also within /sys/ on the SD card are the following files as standard


Homing routines are galled in the notmal manner (G28 X for home x for example) however when that command is set, the RepRap Firmware uses the gcode within the relevant "home__.g" file to perform the homing. For example homex.g:

G90                 ; absolute movement
G92 X0              ; set X to 0
G1 X300 F6000 S1    ; move  fast to a large +'ve value, stop when an endstop is hit
G92 X200            ; set X to value of X max
G1 X195 F200        ; move back 5 mm
G1 X205 F200 S1     ; move forward again, slowly stop when endstop hit
G92 X200            ; set X to value of X max

This routine will home quickly until the endstop is reached, the back away and home slowly until its reached again. It makes use of the addition "S1" to the G1 command which stops when an endstop is triggered. Note that our mendel90s home to Max on all axis.

"homeall.g" would normally be a combination of homex.g, homey.g and homez.g:

G90                 ; absolute movement
;home X
G92 X0              ; set X to 0
G1 X300 F6000 S1    ; move fast to a large +'ve value, stop when an endstop is hit
G92 X180            ; set X to value of X max
G1 X175 F200        ; move back 5 mm
G1 X185 F200 S1     ; move forward again, slowly stop when endstop hit
G92 X180            ; set X to value of X max

;home Y
G92 Y0              ; set Y to 0
G1 Y300 F6000 S1    ; move fast to a large +'ve value, stop when an endstop is hit
G92 Y190            ; set Y to value of Y max
G1 Y185 F200        ; move back 5 mm
G1 Y195 F200 S1     ; move forward again, slowly stop when endstop hit
G92 Y190            ; set Y to value of Y max

G1 X100 F6000       ; center the X carriage before homing Z to clear the bowden tubes

;home Z
G92 Z0              ; set Z to 0
G1 Z300 F200 S1     ; move fast to a large +'ve value, stop when an endstop is hit
G92 Z200.85         ; set Z to value of Z max
G1 Z195 F200        ; move back 5 mm
G1 Z205 F60 S1     ; move forward again, slowly stop when endstop hit
G92 Z200.85         ; set Z to value of Z max

Note the "G1 X100 F6000 line before the Z home. This means that the X carriage will be centered before homing Z, ensuring that the bowden tubes pass easily out of the enclosure. 

The "Tfree1.g" etc are called on tool change in the following way:

TfreeN.g is run when tool N is freed
TpreN.g is run before tool N is set active
TpostN.g is run after tool N is set active

so for example in Tpost1.g you may have:

M116 P1

to wait for tool 1 to get to temperature before continuing with the print.

Or you may have

G1 X10 Y10 F6000

in Tfree1.g to move the extruder outside of the object being printed before changing tools. 

DC42 is working on further macros, specifically for Delta printers and probing. Examples of these can be seen here.

Web Interface Upload

You can use the web interface to upload all the modified files so changes are very quick and easy to make and save:

You can also view the current config.g contents in the web interface.

Tuesday, 28 October 2014

Mendel90 with e3d v6 hotend

The next generation (version 2) of the Lasercut Mendel90 is a work in progress. Currently we are planning on having from 1 to 5 bowden extruders to allow for a single extruder printer as a starting point that is then easily upgradable to as many extruders as required. I will post more information as I finalise the design, for now I wanted to share a X carriage, hotend mount and modified print cooling fan to fit an E3D V6 bowden hotend.

e3d V6 1.75mm bowden hotend mounted on a Lasercut Mendel90, view from below without the print cooling fan
Hotend mount

The hotend mount is designed to accommodate Nophead's ribbon cable connection PCB. 

The e3d v6 fits snugly into a groove mount.

After assembly:

Modified X Carriage

This X_Carriage is a further development on the one made for the Kraken hotend, in fact it was designed to allow the V6 and Kraken to be swapped out without dismounting the carriage. Unfortunately the Kraken is too large for that however at least only one carriage design is required for both.

With the V6 from above

and the Kraken from below

Modified Print Cooling Fan Duct

The V6 is too big for the original fan duct, also this method of mounting places the print tip almost in the center of the carriage. I redesigned the fan duct to take this into account:

I am interested to see how well this design operates "in the wild", I think it may be time to move to bowden in most applcations as a stepping stone to multi material and multi colour printing.

As always Think3dPrint3d designs are open hardware. The design files are available on github and as a Youmagine design.

Follow this blog or @Think3dPrint3d to be alerted to further developments! 

Monday, 20 October 2014

PanelOne on Sanguinololu

The PanelOne LCD display and control panel was originally designed for RAMPS1.4, and that is still the most sensible way to use it as it uses two 2x5 IDC cables that are readily available. The PanelOne circuit board is designed to work with 3.3V and 5V electronics and this weekend I tested it with Sanguinololu (effectively going full circle back to the original Panelolu - just a lot easier to put together and use!)

This works fine, although you do need to be careful to plug the pins in correctly:

The correct pins for Sanguinololu are:

Wire number    PanelOne             Sanguinololu
1                       5V                         5V
2                       GND                     GND
3                       EN B                     Rx1
4                       EN A                     Tx1
5                       LCD DB7              A4
6                       LCD RS                PWM
7                       LCD DB6              A3
8                       LCD E                  SDA
9                       LCD DB5              A2
10                     LCD DB4              A1
1 Not Connected
2 Not Connected
3                       CS                        A0
4                       CLK                      SCK
5                       DO                        MOSI
6                       DI                          MISO
7                       EN SW                  SCL
8                       VCC                      5V
9 Not Connected
10 Not Connected

This blog post has a good image of the location of each pin on the Sanguinololu, re-posted below:

The IDC cables are numbered with wire 1 being the red coloured wire.

This will work out the box with the T3P3 version of Marlin by enabling #SDSUPPORT and #ULTIMAKERCONTROLLER in configuration.h

The process followed can be adapted to use the PanelOne on any electronics that runs Marlin and has enough free pins. Do let me know if you get it working on another board!

Wednesday, 24 September 2014

More Mini Kossel Updates

After nearly 4 months of supplying Mini Kossel kits we have had a lot of fantastic feedback from all the makers who have put the kits together. This is the third post on additions, changes and improvements (the first one is here, and the heated bed one here).

Simple second extruder fan mount

We have had a number of requests for a solution to allow a second, PWM controlled fan to blow on the part being printed, so I designed this modified J_head extruder mount:

This mounts on the end effector plate in the same way as the original one, with the exception that it is rotated by 60 degrees (one hole) to allow the z-probe to clear the second fan:

To minimise the air blowing on the heated bed from the existing, always-on, fan cooling the thermal break on the J-head, I added a strip of aluminium tape to the bottom of the always-on fan mount. The tape can withstand the hot-end temperature so I sealed all the way to the hot-end heater block insulation.

As the fan mount has to be rotated 60 degrees to allow the probe to clear the fan, one of the probe mount screws needs a nut adding:

The second fan is prepared with a male connector pin so it can be plugged and unplugged at the same point as the rest of the end effector wiring loom. In the long run the end effector wiring loom may move to a 2x5 pin plug.

The screws self tap into the plastic of the mount.

The fan wiring follows the same route as the remainder of the end effector/hotend wiring loom, with a plug lined up with the existing plug:

It connects to the RAMPS via screw terminal D9, between the extruder and heated bed (not connected in the picture below), allowing for PWM control when Motherboard number 33 is selected within Marlin configuration.h.

No firmware changes should be required from the standard setup and the cooling settings within Slic3r and Cura will turn the fan on after a specified number of layers.

The source files for the updated hot-end fan mount are on Github. and its also a "thing" on Youmagine!

New PSU for Heated Bed

After an issue with sourcing reliable and economical high current laptop power supplies, James Clutterbuck suggested the Dell DA-2; a 12V 18A power supply:

This beast is capable of providing enough power for the whole printer and heated bed so from now on complete printer kits ordered with heated beds will be supplied with just this power supply. Unfortunately although the DA2 is supplied with what appears to be a 2x4-way Molex Minifit plug, the housing doesn't mate correctly with the standard Molex 2x4 Minifit socket, and so needs to be changed (part numbers below).

Roland designed a new face plate that accommodates the Molex socket along with a power switch and the USB plug.

The power supply cable is wired to both sides of the RAMPS plug:

The assembled faceplate installed:

The documentation will be updated shortly. The source files are available on our Kossel Mini Repository on Github (USB-power-8way-V2). If you want to source the parts for the upgrade, along with the printed plate, you need:

Dell DA-2 Power supply (12V 18A)
8 way connectors: Molex 39-01-2080 and 39-01-2081
16AWG crimp pins for molex 39-00-0078 and 39-00-0082.
Standard case rocker switch such as this one.

Marlin improvements

The Think3dPrint3d Kossel fork of the Marlin firmware is available on github and comes pre-configured as a good starting point for Marlin on a Mini Kossel. I have recently implemented a couple of improvements. Firstly David LapeŇ° pointed out this feature request/ bug fix for the main version of Marlin which allows for negative position numbers to be correctly displayed on the PanelOne screen:

The second change is to add 4 menu items for filament management. Within the "Prepare" menu you can now choose to prime or retract the filament by a small amount (default 3mm) as well as either load or unload the filament completely (default 560mm).

The default values can be changed within configuration.h, line 399 onwards:

#define EASY_LOAD
#define BOWDEN_LENGTH 560


You can also set the feed rate for each action (in mm/minute)

This based on Lajos's changes to Marlin for the Tantilus printer, I changed his implementation to make it work with the delta firmware and simplify the options a bit.

You can upgrade to these changes by downloading the Think3dPrint3d version of Marlin and uploading it. Make sure you copy across any changes you have made to configuration.h such as the Z height and delta radius after calibration.

Sleeker cable management

Mark Burton has added "Go Faster" stripes to his Kossel mini in the form of these extrusion insets, which nicely hide away the endstop cables.

4 of the strips fit in each extrusion tower. The scad and stl files are on github.

 Thanks to everyone who has sent feedback and design improvements!

Sunday, 31 August 2014

Slicing software printed support review - evaluating Slic3r, Cura and Meshmixer

Support material options for single extruder printers have come on significantly recently and I have run a series of test prints to evaluate three contenders:

Meshmixer, by Autodesk - adding support structures to meshes is a small subset of the processing it can do on stl files. (version 2.5)

Cura, by Ultimaker. A capable slicing program with super fast path generation. (version 14.07)

Slic3r, by Alessandro Ranellucci and others. The go-to slicing software for much of the reprap community with a great amount of configurability. (version 1.2.0 experimental)

This is not intended to be a tutorial on how to use these three programs as excellent tutorials already exist, I will simply expose the settings and processes I used for support generation.

I chose two models as test pieces: low poly Fennec Fox, uploaded to thingiverse by Physics_Dude. I scaled this model to 120% for the tests.

Printed as one piece it requires significant support to print properly.

Also the bonsai planter by createdbygordon

Which has some tricky internal overhangs when sliced without infill to make a pot.

Support generation


The meshmixer support generation is semi automatic - it is automatically generated but I found it needed a bit of tweaking to fully support this model.

After importing the model into meshmixer, go to analyse, overhangs and select Ultimaker2 (Dizingof's settings) as the start point, then "Generate Support":

Meshmixer support automatic generation
The support is generated over all the area highlighted in red, you can modify how thick you want the columns and the interface points. I have gone for 2mm columns with 0.8mm interface points (where the support narrow just before touching the model).

Meshmixer support - starting from the fox's foot rather than the build surface.

One of the more annoying "features" is the autogeneration choosing to start a support pillar from a surface of the model (as shown in the picture above) rather than from the build surface.

Meshmixer support - long fragile support columns
Another issue I found were quite long support pillars that were too fragile to consistently support themselves. This is where you can add additional support pillars to shore them up as shown below.

Meshmixer support - adding additional support pillars
Clicking on the point you want the support to be on either the model or an existing support will drop a pillar down to the build surface (or you can click and drag for finer control). I found this was required for the taller support columns.

Meshmixer support automatic generation - made solid
Finally you click "convert to solid before exporting the model as an .stl. this can then be sliced without support with Slic3r or Cura as you like.

On the bonsai planter the issue of generating support that builds on the object rather than the build plate is even more pronounced:

Also it was difficult to manually add support columns that go down to the build plate - they insisted on snapping to the object instead. An issue with all the slicers: when using the solid object there is obviously no way to generate support inside for overhangs.


Slic3r's support generation settings I used are:

Slic3r support settings
The pillars pattern is relatively new and should provide a good compromise between strength of support and use of material. I did not see a noticeable difference in the support generated with "support bridges " checked or unchecked - probably because the foxes body and the overhangs on the bonsai planter have a slope to them.

The fox support looks like this in gcode visualisation:

Slic3r Support gcode - visualised in pronterface
The pillars are interconnected with lines - seemingly at random.


The basic setting allow you to select support that is only touching the build plate, this is a good feature as its often provides enough support and prevents the top of lower parts of the model getting messed up:

In expert settings you can tweak the support which allows you to put space between the support and the sides of the object - another good option to reduce the occasions that the support messes up parts of the print that do not need support.

Cura has built in gcode visualisation:

With the line option you get far less retracts than the other software a Dizingof mentions:

Although I have not had a print jam due to retractions using any of the support options.

Printed examples

All these examples were printed on the Mini Kossel printer, in generic ABS at 0.2mm layer height.


The support printed well (however the autogenerated support struts definitely needed the manually added additional bracing)

Meshmixer support of Fennec Fox

Meshmixer support in detail
The picture in detail shows the support columns narrowing to a nominal 0.8mm at the top.

I did not try the bonsai planter print with meshmaker support.


This support turned out to be much more intrusive on the model than meshmixer or cura

Slic3r support of Fennec Fox

Slic3r support in detail
The support itself consisted of columns with wispy bits between them - maybe there is no retraction with the support? Also note how the support is partially encasing the front legs.

With the bonsai planter the support generated by both Slic3r and Cura was only external to the object - even though the object was printed with no infill and thus might require 
support internally. This is rather an unusual case though so I am not surprised it was not generated. this issue is evident on the roots where they are bridging over the top as shown below:

Bonsai planter with no infill showing the perimeters failing to bridge properly
I tried to reduce this issue by using 6 perimeters which improved some areas but was not enough.


Cura's support is laid down thicker by default than Slicer but it nicely avoids the vertical parts of the object it is next to

Cura support of Fennec Fox

Cura support in detail - notice the support warping
Due to the long straight lines and printing in ABS the support warped quite a lot as shown in the photo, however it did not affect the print in any noticeable way.

Cura had the same issue with the internal unsupported areas of the bonsai planter that Slic3r did - in addition it showed quite a bit of stringing internally, I wonder if it does not retract for internal, no perimeter crossing, moves. While in general this is probably fine if there is no infill the inside should be treated in the same manner as the outside so this is an area for improvement.

Bonsai planter - internal stringing

Support removal

In all cases I removed the support by hand, assisted by a pair of small side cutters for finishing off. I spent no more than 5 minutes on each fox model so more support could be removed by further work, ie by filing/sanding.


The meshmixer support was the easiest to remove from the fox model. Having only 0.8mm contact points as dots along with the lever arm of the printed pillar ment they broke off very close to the model but not always exactly at the interface - sometimes a couple of 0.8mm layers were left on the model

Meshmixer support removed

As can be seen the remaining support marks are quite obvious, however the support did a good job of ensuring the supported layers printed well.


The Slic3r support was variably easy to remove - the tail and head support came away in one piece with no effort, leaving an extremely clean finish:

Slic3r support removed - fox head very clean

Slic3r support removed - fox tail similarly clean
The fox body was a different story - here the support was tangled up with the top of the legs and it was difficult to remove the last few layers. 

Slic3r support removed - fox body with support remaining

Slic3r support removed - fox leg with support marks
As there was no gap between the support and the front legs there were support marks along the sides of the legs.

With the bonsai planter the support came away relatively easily - with similar issues where it unnecessarily touched the model walls. The supported surface in this case though was not that well supported and looked rough.

Slic3r support removed - bonsai planter with support marks


The cura support was almost as easy to remove as meshmixer, leaving noticeable lines that none the less looked better than the meshmixer spots.

Cura support removed - minor marks remaining

Cura support removed - lines visible on the tail
Cura proved to be the most consistent across the whole model and the support only touched the model where it was required.

For the Bonsai planter the support was similarly easy to remove and left minimal marks overall. It did a better job than Slic3r in supporting the model however it left one area unsupported that arguably should have been. This lead to the perimeters curling up and the white filament being discolored by the nozzle.

Cura support removed - discolouration due to unsupported area curling up



This support was the most efficient in material use however it required the most manual tweaking to print properly. In addition the marks it left once removed were more noticeable than Cura and (sometimes) Slic3r. While the settings could probably be further modified to improve the performance this support type appears the most limited for future improvements.


The support's performance was variable - by far the best in some situations (fox's head and tale) however the worst to remove with the most obvious marks in other areas of the same model. This may be down to my chosen settings and with some more tweaking I may get better results. The most obvious general flaw is that it does not leave a big enough gap between the support and the unsupported areas of the model (like the foxes legs or the lower roots of the planter)


While some of the support left marks, overall it was the easiest to generate support which performed consistently well. Once again though slight tweaks could improve this further for specific models. 

Overall Cura wins my "no time to tweak - got to make it work now" award.

Last word

Over the last few years the support generation in Slic3r and Cura has improved a huge amount (no idea bout Meshmixer as I only just started using it). All three of these programs are under constant development and frequently get improved so this blog post is definitely not the last word! I would welcome other people's experience with the support functions and tweaks to make them work better in specific situations. I have also left out at least one commonly used (but not free/OSS) program in KISSlicer - one to evaluate in the future.