Multi colour printing without using wipe or prime towers

Most of the problems with multicolour printing revolve around the fact that when switching from one filament to another there is still some of the old filament in the system that needs to be purged before the new filament can be extruded cleanly. The usual approach is to use some sort of wipe or prime tower which is wasteful both in terms of print time and filament usage, so this is an alternative approach to the problem.

I’ve marked this as a feature post. If you are interested in this, check my blog for the latest updates.

As I have promised on a couple of forums, this post will explain in detail the method I am developing to enable 3D printing of multi colour objects without resorting to the use of wipe or prime towers.

For those of you who haven’t been following my endeavours on any forums, here is a link to the video I posted on YouTube which shows the technique in action.

Now before we get too far into the details, I need to explain few things about myself. I was born in 1953 and left school/started work in 1969 at age 16. I learnt my maths using log tables and a slide rule. I’m a mechanical engineer by training but currently (career number 5) I have a small business make designing and building garden decks. What I know about computers, 3D printers, electronics, writing code etc is all self taught through a lot of internet searches and reading a few books and online tutorials so I’m no expert.

I started setting up this blog/web site on 4th January 2017 so I’m still finding may way around. Apart from a brief introductory post, this is the first blog post I have ever made. Therefore, the layout of this blog site may well change (and please excuse any typos)

That’s the excuses out of the way, now down to business…..

The rest of this post assumes that the reader has the tools and techniques available to generate or otherwise obtain a .gcode file for a multicoloured object. I plan to do a separate write up on the method I use, which involves separate .stl files (which I generate using OpenScad) and slic3r but that will have to wait.

There are a number of issues which have to be addressed when printing multicoloured objects and most of them revolve around what happens when switching from one filament to another. My first forays into multicolour printing were with a tricolour Mendel variant which used 3 separate hot ends. I found that there were 4 major drawbacks to this approach. Firstly it was very difficult to get all 3 nozzles at exactly the same height (within less than 0.1mm) and for this setting to be maintained in such a way that inactive nozzles didn’t drag across the printed part. Secondly, it was very difficult to set and maintain  X and Y offsets get the output from all 3 nozzles perfectly aligned. Thirdly, it was necessary to set unused nozzles to a lower standby temperature in order to prevent filament from oozing out and dragging on the print but this was never completely successful. Also, the waiting time for one nozzle to heat up and another to cool down significantly increased the print duration. Lastly, there was the problem of filament oozing from one nozzle as it cooled down and before it reached it’s standby temperature, or another nozzle as it heated up before it reached it’s active temperature.

All of the above problems can by overcome by using a single nozzle – i.e. a mixing hot end. For the purpose of this post, I will define a mixing hot end as one which has multiple filament inputs but a single output (nozzle). I am currently using a Diamond hot end but I am aware that there are other designs.

However, this approach generates a new problem which is that when switching between filaments, there is still some of the old filament left in the nozzle and/or mixing chamber which has to be purged before the next filament comes through. If the colour change coincides with a layer change, this is rarely an issue. Unless the object being printed is really small, what happens is that the purge occurs during the inner perimeter(s) so by the time the outer perimeters are being laid down, the purge has already been completed. Effectively the change over period is hidden inside the object and isn’t visible.

The real problem is when the colour change occurs within the same layer, as in the union flag example that is in the YouTube video, because there is nowhere to hide and any defects will be visible. The usual approach is to move the print head away from the main object, and print some sort of sacrificial tower or use some sort of wiping mechanism to purge out the old filament, then move back to the object and resume printing. This is wasteful both in terms of filament and time, and can lead to a less than satisfactory print finish if filament retraction and recovery are not fully optimised.

The technique I’m developing and which I am about to share here, simply moves the filament change point to a position earlier in the gcode file. The new position equates to the amount of filament that needs to be extruded in order to purge out the old. The method isn’t perfect because in theory, there is still a “transition” period where what is being extruded is a mixture of the old colour and the new. In practice, by observation I’d estimate this transition to be about 10% of the total “purge amount” and I have found that with the Diamond hot end the optimum purge amount is about 2.0 to 2.5mm of filament so there is around 0.2 to 0.25mm of “transition” filament which is hardly noticeable. Other designs of hot end may have larger mixing chambers, in which it may still be necessary to use some sort of wipe or prime tower. However, my technique could still be applied to take account of much of the purging so any further priming could be achieved by using a very much smaller tower or priming mechanism. One of my planned improvements is to build a small priming tower or similar mechanism into the post processing script, although as I have said earlier, the transition between one colour and the next with the Diamond hot end is really small and hardly noticeable.

As mentioned earlier, the only coding I know how to do is what I have been able to teach myself from internet searches, on-line tutorials and the odd book (some have been very odd). I have used Python just because I found it less of a pain to learn than some other languages that I’ve tried. I am aware that this might not be the best tool and I am deeply aware of my own shortcomings so I think the best approach is for me to post my work flow and explanation of what the code attempts to do. Others with more skill than I have can then use it as basis to write something more efficient (and probably less dangerous). I’ll make the python script available for those want to try it but please don’t blame me if it crashes your PC or worse.

So here goes.

The approach I’m taking is to leave the original file untouched and generate a new file with the colour change commands moved forward in the file but otherwise it’s an exact copy. This enables me to run the script several times on the same file but with a different “purge” setting in order to test and fine tune. The change from one colour to another in the gcode file is accomplished by selecting a new tool. It could be done by having a single tool and changing the mixing ratio but that’s not how slc3r works. So for the rest of this post colour changes will be referred to as tool changes. Note that the code could be adapted to look for M563 commands (mixing ratio changes) instead or as well as “Tn” (tool change) commands.

I haven’t yet figured out how to cut and paste the python text while retaining the font colours so I’ll change them manually – hopefully I won’t miss any. Comments are in red and start with a hash (#) String values are in green. My other comments are in blue to denote the fact that are not part of the script.

These first lines should be changed to suit the user. Hopefully the comments make them self explanatory.

sourceFile = “D:\RepRap\G Code Files Diamond hot end\Python test file.gcode” # The full path and file name of the file to be worked on
destinationFile=“D:\RepRap\G Code Files Diamond hot end\Python output.gcode” # the full path and file name of the destination (output) file
temporaryFile =“D:\RepRap\G Code Files Diamond hot end\Python temp.gcode” # A temporary file used to hold smallish sections of the original and which gets read into memory.
purgeAmount =2.5 # This is the amount of filament to be purged when a tool change is needed

The next thing I struggled with was how to detect the start of a print proper. Slic3r inserts all sorts of comments both before and after the actual print and I use quite a complex start gcode in my slic3r setting. In the end I decided to use flags in my start and end gcodes. So the last line of my start gcode is a comment “;begin” and the first line of my end gcode is the comment “;end”. The main reason for doing this is that the script simply looks for the text “T” to detect a tool change and as “T” can be found in comments and both pre and post print sections, I need to restrict the search.  

beginText=“begin” #string to look for to detect start of gcodes proper. This should be the last line of slicer start gcode
endText=“end” #string to look for to detect end of gcodes proper. This should be the first line of slicer start gcode
searchToolText=“T” # String to look for to detect a tool command (which is why we need to restrict the search to between “begin” and “end”
# Tool number could be anything after the “T” so we can’t can’t search for “Tnn” explicitly

Here are all the other variables that I have used. I know that I probably shouldn’t have declared them as global variables but at least they are all in this section so easy to find what they do. I also know that I’ve probably used a lot of unnecessary flags and that they could be boolean rather than integers etc etc.

beginFlag=0 # flag to detect if the word “begin” is present
endFlag=0 # flag to detect if the word “end” is present
#There is nothing to check that begin is indeed before end – maybe do this check too.
toolFlag=0 # flag to detect that tool changes are present
toolChanges=0 # number of tool changes in the file
currentTool=“T0” #default this to “T0”
lineText=“” # text read in from file
startLineNo=0 # the line number in the file immediately after the word “begin”
toolChangeLineNo=0 # the line number in the file where a tool change occurs

newToolPos=0 # the position where the tool command will be inserted
lastLine = 0 # the position of the last line in the temp file
lineToRead=0 # pointer to which line to read in the temp file
estart=0 # position in the line after the letter “E” which denotes the position of the start of digits for extrusion
estring=“” # the string of 7 digits following the letter E
EAmount=0.0 # estring converted to a number
totEAmount=0.0 # the sum of all EAmounts
EAmountNeeded=0 # the purge amount less the totEAmount
notEnoughFlag=0 # flag to set if the the totEAmount is less than needed for a full purge between tool changes

xStartPrev=0 # the position in the previous line where X is
xPrevString=“” # read the 7 characters after “X”
xPrevNum=0.00 # convert to number – First X value

xStartHere=0 # the position in this line where X is
xHereString=“” # read the 7 characters after “X”
xHereNum=0.0 # convert to number – Second X value

xMove=0 #xHereNum-xPrevNum

yStartPrev=0 # the position in the previous line where Y is
yPrevString=“” # read the 7 characters after “Y”
yPrevNum=0.0 # convert to number – First Y value

yStartHere=0 # the position in this line where Y is
yHereString=“” # read the 7 characters after “Y”
yHereNum=0.0 # convert to number – Second Y value

yMove=0 # yHereNum-yPrevNum

E1 = 0 # EAmount-EAmountNeeded
E2 = 0 # EAmountNeeded

X2 =0 # xHereNum
X1 =0 # PrevNum +(xMove/eAmount*E2)
Y2 =0 # yHereNum
Y1 =0 # yPrevNum +(yMove/eAmount*E2)

E1string=“” # used to build insertString1 – 1st E amount
E2string=“” # used to build insertString2 – 2nd E amount
X1string=“” # as above but X values
Y1string=“” # as above but Y values

insertCheck=0 # used in loop to check lines are valid for inserting text
firstInsert=0 # modified from newToolPos if that position contains something other than a normal XYE move
secondInsert=0# as above

insertString1=“” # 1st (new) move string prior to tool change i.e. “G1 Xnnn.nnn Ynnn.nnn En.nnnnn”
insertString2=“” # then the tool change
insertString3=“” # then the second move string

changesDone=0 #number of tool changes done

So now we start the script proper. This section should all be self explanatory. I don’t know how to indent individual lines within a paragraph using this WordPress thingy so I’m having to do it by starting a new paragraph wherever the text needs to be indented.  Therefore there are what look like a lot of blank lines in what follows but Python relies on indentation for the code to work so it’s important that I show it.

# Start by reading through the file to check that “;begin” and “;end” are present
startfile=open(sourceFile,‘r’) # Open file as read only
numLines=sum(1 for line in (startfile)) set to start of file (just in case)
print (“Checking File…”)
for x in range (0,numLines):

if endText in lineText:

break # exit loop on first instance of “end”

for x in range (0,numLines):

if beginText in lineText:

break # exit loop on first instance of “begin”

print (“Number of lines =”,numLines) # Just for info
if beginFlag>0:

print (“\”;begin\” text is present at line “,beginFlag) # Just for info – print a message to say that the search string was present.


print (“There is no \”begin\” statement in the file”) # If not print a different message to say that the string wasn’t found…….
print (“Add \”begin\” to the end of the start gcode in Slicer”) # ….and tell the user what to do about it.
print (“And/Or edit the file and start again”)
exit() pr# if there is no “begin” text string in the source file then end the script after printing the message and closing the file.

if endFlag>0:

print (“\”;end\” text is present at line “,endFlag) # comments as above


print (“There is no \”end\” statement in the file”)
print (“Add \”end\” to the end of the start gcode in Slicer”)
print (“And/Or edit the file and start again”)
exit()# if there is no “end” text string in the source file then end the script after printing the message and closing the file.

startfile.close() # I always like to close a file when an operation on it has finished – just in case.

This next bit is just for information really although the number of tool changes is used further on in the code and if there aren’t any tool changes found, it will print a message and exit. 

#so now read through and count the number of tool changes between begin and end

print (“Checking for tool changes…”)
for x in range (beginFlag,endFlag):

if searchToolText in lineText:


toolChanges=toolFlag-1 # the first occurrence will be the first tool, so take 1 off to get the number of tool changes.
if toolChanges>0:

print (“There are “,toolChanges-1,“tool changes in the file”)


print (“There are no tool changes in this file”)
print (“So no changes will be made.”)


Now I read through the file and copy everything up to the first tool change into the output file

# Now read through the file and copy everything up to the first tool change
startfile=open(sourceFile,‘r’) # open source file again for reading # make sure we start at the beginning
endfile = open(destinationFile,‘w’)# open the destination file for writing
print (“Reading file and writing lines up to first tool change”)
#start by copying everything up to the begin statement
for x in range (0,numLines):

lineText=(startfile.readline())#read line from input file
# uncomment the following line with caution – it really slows things down.
#print (lineText)
endfile.write(lineText) # copy line to output file

if beginText in lineText: #is there a tool string present in this line?

startLineNo=x # if so, set the variable StartLineNo to x which will be the text file line number

break #end the loop when the first tool line number has been reached

# end of for loop


# So now check for first instance of a tool (check gcode file for a “T”)
# also, append all the lines up to this point to the end file
# Start by opening the end file again in append mode

endfile = open (destinationFile, ‘a’) # open again in append mode

for x in range (startLineNo,numLines): # miss out the first lines from 0 to StartLine No

lineText=(startfile.readline())#read line from input file
# uncomment the following line with caution – it really slows things down.
#print (lineText)
endfile.write(lineText) # copy line to output file but this time we are amending it to the end of the file
if searchToolText in lineText: #is the string present in this line?
currentTool=lineText # if so, set the variable CurrentToolText to whatever this line holds (string value)
break #exit loopif


# *********** Now it gets tricky************

What I do next is copy chunks of the source file between tool changes into a temporary file. The reason for doing so is that I wanted to read this file into a list so that I can work on it. Maybe I could read the entire file into memory but potentially it could be a huge file and gobble up all the PCs resources. David Crocker (DC42 of Duet fame) has said that if he were doing this in firmware, he would have two streams – the original and the output with the a kind of buffer that would hold just the number of commands that make up the purge amount, rather than this approach which holds all the commands between one tool change and the next before they are written to the output file. Thinking about it, that would be a far better approach but the following is how it is now. So, to continue…

(Oh by the way, there are quite a few commented out print statements in what follows which were only used for debugging)

# Read lines from latest tool to next tool and stick them in a temporary file

for changesDone in range (1,toolChanges):# repeat the rest of this until we reach the end of the file

print (“Doing tool change “,changesDone)
totEAmount=0 # reset to zero
newToolPos=0 # reset to zero

tempfile = open(temporaryFile, ‘w’) # This will create a file if it doesn’t exist and/or overwrite.
print (“Writing to temporary file……”)
for x in range (toolChangeLineNo,numLines): # miss out the first lines from 0 to StartLine No

#print (“Tool change line number = “,toolChangeLineNo)
lineText=(startfile.readline())#read line from input file

# uncomment the following line with caution – it really slows things down.
#print (LineText)
tempfile.write(lineText) # copy line to temporary output file
if searchToolText in lineText: #is the string present in this line?

currentTool=lineText # if so, set the variable CurrentTool (Text) to whatever this line holds (string value)
toolChangeLineNo=x # so update the pointer to the current line number…
break #… and exit loop

if x==numLines: # if we reach the end of the file (we should never get here)
print (“No more tool changes”) # print message, close files and quit


#end of x loop – still in changesDone loop

tempfile.close()# Close the file for writing to

#now read the whole tempfile into a list so we can work on it
templines =f.readlines()
lastLine =(len(templines)-1) # Len is the number of lines in the file but the last line will be 1 less because the first line is indexed as 0.
#print (templines[lastline]) # just for debugging
print(“Calculating new tool position”)
#Start at the end of the file and work backwards
# read the 7 characters after the “E” in a line
notEnoughFlag=0 # Reset flag (start at zero)
for j in range(1,lastLine): # set range to the number of lines in the file so that it can’t go back beyond that

lineToRead=lastLine-j # read the line
#print (templines[lineToRead]) # for debugging only – comment out later
if “E” in templines[lineToRead]: # check that the line does actually have an E value

estart=templines[lineToRead].find(“E”) # find the position in the line where E is
estring=templines[lineToRead][estart+1:estart+8] # read the 7 string characters after the E
#print(estring) # just for debugging – comment out later
EAmount=float(estring)# convert the string to a number
#print (EAmount) # just for debugging – comment out later
totEAmount=totEAmount+EAmount # add this amount to the previous amount to get a total
#print (totEAmount) # just for dbugging – comment out later
if totEAmount > purgeAmount:

newToolPos=lineToRead #Set the new tool position to lastline -j (the point in the line where the sum of all the extruder commands excedes the purge amount).
#print(“new tool position “,j)
break #exit the loop

if j==lastLine: # if we go all the way back

newToolPos=lineToRead # then there aren’t enough moves to purge fully so set new tool pos to the earliest position
print (“WARNING Not enough extrusion between tool changes to fully purge”)


# so now we have the position for the tool where adding the Eamount from the line after excedes the amount needed to purge
# but it’s counting backwards from the end
print(“Splitting Gcode line at insert point”)
# so I want to use only the amount needed, therefore I have to split the line
#the amount needed will be the ToteAmount minus the purgeAmount
EAmountNeeded = totEAmount-purgeAmount
#get the x an y totals for the line that needs to be split

# ************Trap for the line not being a normal XYE move **************
# ************If it isn’t go back and keep going back until we find one **************

if notEnoughFlag==1: # skip the next bit if flag set


while insertCheck ==0:

if “G1 X” in templines[secondInsert]:



# Now get the x value from this line

xStartHere=templines[secondInsert].find(“X”) # the position in this line where X is
xHereString=templines[secondInsert][xStartHere+1:xStartHere+8] # read the 7 characters after “X”
xHereNum=float(xHereString) # convert to number – Second X value

# and do the same for the y value
yStartHere=templines[secondInsert].find(“Y”) # the position in this line where Y is
yHereString=templines[secondInsert][yStartHere+1:yStartHere+8] # read the 7 characters after “Y”
yHereNum=float(yHereString) # convert to number – Second Y value

#Now do it all again for the previous line

firstInsert=newToolPos-1 #take 1 away to get the previous line
if notEnoughFlag==1: # skip the next bit if flag set


while insertCheck ==0:

if “G1 X” in templines[firstInsert]:



xStartPrev=templines[firstInsert].find(“X”) # the position in the previous line where X is
xPrevString=templines[firstInsert][xStartPrev+1:xStartPrev+8] # read the 7 characters after “X”
xPrevNum=float(xPrevString) # convert to number – First X value

yStartPrev=templines[firstInsert].find(“Y”) # the position in the previous line where Y is
yPrevString=templines[firstInsert][yStartPrev+1:yStartPrev+8] # read the 7 characters after “Y”
yPrevNum=float(yPrevString) # convert to number – First Y value

#Now take one from the other

# Now split the values

E1 = EAmount-EAmountNeeded
E2 = EAmountNeeded

X2 = xHereNum
X1 = xPrevNum +(xMove/EAmount*E2)
Y2 = yHereNum
Y1 = yPrevNum +(yMove/EAmount*E2)

# Now convert the values back to strings

E1string=“{:.5f}”.format(E1)# 5 decimal places
#print (E1string)
#print (E2string)
X1string=“{:.3f}”.format(X1)#3 decimal places
#print (X1string)
#print (X2string)
#print (Y1string)
#print (Y2string)

#build strings to insert
insertString1=“G1 X”+X1string+” Y”+Y1string+” E”+E1string+”\n” # 1st (new) move prior to tool change
insertString2=currentTool # then the tool change
insertString3=“G1 X”+X2string+” Y”+Y2string+” E”+E2string+”\n” # then the second (new) move

#print (insertString1)
#print (insertString2)
#print (insertString3)

#determine the point where the lines need to be inserted
print (“Appending lines to output file”)
#now open the end file and append this lot to it.
endfile = open(destinationFile,’a’)
for x in range (0,insertPoint):


for x in range (insertPoint+1,lastLine):


print (“Tool change “,changesDone,“done”)
changesDone=changesDone+1 # so go back and do it all again for the next tool change

# End of changes Done loop

print(changesDone-1,“Tool changes moved”)
if notEnoughFlag==1: # skip the next bit if flag set
print(“WARNING there was insufficient filament extruded to fully purge between at least one of the tool changes”)

# So now all that remains is to append the rest of the source file to the output file

print (“Copying remaining lines to output file…”)
endfile = open(destinationFile,’a’)
for x in range (toolChangeLineNo,numLines):

lineText=(startfile.readline())#read line from input file

print (“Done..”)

And that my friends is it!!

I don’t suppose anyone will want to copy and paste all the above code so I’ve uploaded the file to my Google drive.

Edit. 24th Jan 2017. I have removed the link to the Python script because there were a number of bugs – see later posts.

Stepper motor and electronics cooling

I recently encountered a problem with my printed XY stepper mounts so thought I’d share my solution and also some other things I do to cool certain parts of my printer.

We all know that stepper motors run hot but they are mostly rated to run at around 80 degrees C so normally, cooling isn’t necessary. However, if you use a printed mount such as I do, then you may experience this.


I had read that this could happen but didn’t really give it any thought. What has happened is that repeated periods of 20 plus hours printing, the plastic has been softened by the heat of the motor, then the lateral force of the belt tension acting on the motor shaft has distorted the mount.

Of course, a metal mount would cure the problem but I use a sliding motor mount as a belt tensioner and not having access to metal working machinery, it has to be a printed part. It’s possible that a different type of plastic to PLA might have been more thermally stable but I decided to use a “belt and braces” approach.

The first thing I did was to buy a plumbers’ soldering mat which is made from Gold Silica and cut a couple of gaskets to go between the motor and the mount. I don’t know how effective this will be but it didn’t cost much so why not?


The next thing was to fit a heat sink and fan to the top of the motor. I used these heat sinks and used some thermal paste between the motor and the heat sink.

These were the quietest 40mm 24v fans I could find

To fit it all together, I had to remove two of the stepper motor screws and replace them with lengths of studding (it needs very long screws which I couldn’t find). Nyloc nuts and washers keep it all together. I would have preferred it if the heat sinks had been drilled in apposite corners, rather than two holes on one side.

Lastly, the Duet electronics mean that the printer is very quiet in normal use. So much so that fan noise start to become intrusive to me. I had already changed the power supply to a fan less design (my heated bed is mains powered so I don’t need a high current power supply). The hot end fan is set to run in thermostatic mode so that it only runs when the hot end is above 45 degrees C. Likewise the fans I use to cool the electronics. So when the printer is idle, no fans run at all and it is virtually silent apart from a faint buzz from the stepper motors once they have been energised. I have the Duex5 expansion board as well which gives me extra fan and heater connections so, I decided to do the same with these stepper cooling fans.

To monitor the temperature I stuck a bead thermistor to each stepper, close to the mount, with a small amount of epoxy adhesive. Here is how the installation looks.


Here is how it looks at the Duex5 end. The thermistors are the orange and green wires at the bottom and the fans are the red and blue coming out of each loom.


Just out of shot is the thermistor that I stuck to the topmost stepper driver chip but you can see the two white wires leading into a spare heater channel. I did the same on the main board  with one of the XY driver chips. These thermistors control fans which blow air on to the back of the boards.

Next I had to configure the new fans and heaters. A note of explanation is required here. With Duet electronics, temperature channels are called “heaters” regardless of whether they are actually used to switch physical heaters or, in this case cooling fans.

So here are the relevant lines from my config.g file for the “heaters” (actually thermistors).

M305 P2 T100000 B3950 R4700; Set thermistor + ADC parameters for heater 2 – this is used to measure stepper chip temperature on Duet
M305 P3 T100000 B3950 R4700; Set thermistor + ADC parameters for heater 3 – this is used to measure stepper chip temperature on Duex5
M305 P4 T100000 B3950 R4700; Set thermistor + ADC parameters for heater 4 – this is used to measure left XY stepper temperature
M305 P5 T100000 B3950 R4700; Set thermistor + ADC parameters for heater 5 – this is used to measure right XY stepper temperature

This is the fan section of my config.g

; Fans
M106 P0 S0.0 I0 F10 H-1 ; Set print cooling fan (3) value, PWM signal inversion (off)and frequency (10 hz). Thermostatic control is turned off
M106 P1 S255 I0 F500 H1 T45; Set hot end fan (1) value, PWM signal inversion(off) and frequency. Thermostatic control is turned on
M106 P2 S255 I0 F500 H2 T45; Set fan 2 value (Duet board fan), PWM signal inversion and frequency. Thermostatic control is turned on
M106 P3 S255 I0 F500 H3 T45; Set fan 3 (Duex5 board fan) to work thermostatically on H3 temp
M106 P4 S255 I0 F500 H4 T45; Set fan 4 (Left XY stepper fan) to work thermostatically on H4 temp
M106 P5 S255 I0 F500 H5 T45; Set fan 5 (Right XY stpper fan) to work thermostatically on H5 temp

Finally, I wanted to be able to actually display these temperatures on the web interface. The way I found to do this was to create “dummy” tools without any extruders associated with them. I started with defining tool numbers 99 then worked backwards.

Here is the ending part of my tool definition section.

M563 P99 H2; define this dummy tool just so dwc shows the temperature value for the thermistor that’s stuck to the stepper driver
M563 P98 H3; define this dummy tool as above for duex thermistor
M563 P97 H4; define this dummy tool as above for left xy stepper thermistor
M563 P96 H5; define this dummy tool as above for right xy stepper thermistor

This is how it looks on the Duet Web Interface.

Screenshot-2017-4-18 TallCoreXY

I just have to remember that Heater1 is the hot end thermistor (as normal), Heater 2 is actually the XY driver chip on the Duet main board, Heater 3 is the same for the Duex5 board, Heater 4 is the left XY motor body and Heater 5 is the right XY motor. I have posted a request on the Duet forums for a better way to display these temperature channels.

I understand that future versions of firmware will have the ability to control fans based on a temperature warning signal from the driver chip itself. This would negate the need for the thermistors that I have used but as I understand it, the temperature threshold at which the fan comes on will be quite a lot higher and not user configurable.

Finally, it was time to test my new cooling arrangement and I can report that it works like a charm. I started printing a simple 200mm square object. It takes quite a while (about 45 minutes or so) for the steppers to reach 45 deg C. This may be due to the heat sinks on their own – I have no data to compare with though. When the temperature reaches 45 deg C, the fan switches on, the temperature drops, the fan switches off and there is a bit more of a drop before the temperature come back up. The cycle time for the fans is about 1 minute on, 3 minutes off and after about 4 hours, the temperature was still being controlled at 45 deg C with the same hysteresis. What is interesting is that when doing diagonal infill on a coreXY one motor is stationary and I can observe one fan switching on and off while the other hardly runs until the next layer where the situation is reversed. So I’m glad that I decided to add control to each individual motor. Maybe I need to do the same with the driver chips…………



Setting up a Metrol positioning switch

This is a very quick post on how I installed a Metrol positioning switch for Z homing with my sliding hot end mount using the Duet Wifi electronics.

Metrol are a Japanese company who make high precision switches for industrial applications. Here is a link to their web site They seem to have a direct sales site called which is here It looks like you can buy from ToolSensor via their outlet too.

I couldn’t find a UK source so ended up going to Misumi  UK and buying one of their contact switches. It wasn’t until it was delivered that I discovered that it was in fact a Metrol switch. Misumi only sell to businesses but they don’t seem to care if the business is VAT registered (mine isn’t) and there are no  minimum order quantities. So how and where you source these Metrol switches will depend on what part of the world you live in.

These switches come in numerous configurations. The one I chose has a smooth body but there are threaded versions available too. If you can, buy one without the LED as then it can be connected to the E0 end stop connector in the normal way – i.e. just like any other micro switch. The instructions for connecting end stop switches are here

Unfortunately, the non-LED version was not available from Misumi so I had to buy the LED version. The Misumi part number of the one I chose was N-MSTK-ASD. The non LED version is the same part number but without the “D” on the end. There is a sleeve on the switch with the word “Metrol” (that’s how I know it is a Metrol switch) and then “CS06A -L” which I assume is the Metrol part number and I would hazard a guess that the hyphenated “L” denotes LED version.

The data sheet for this switch shows a stroke of 2.0mm, the switching point as being 0.3mm from tip and the repeatability to be 0.005 mm. Metrol do make switches with claimed repeatability of 0.001mm but IMO that would be overkill even for our Z axes.One down side is that the switch is normally open rather than normally closed so if a wire falls off, it won’t fail “safe”. As I mentioned in my other post, I installed a backup micro switch to trigger 1mm higher than the Metrol switch and initiate an emergency stop should the primary switch fail.

If you’ve managed to find a non-LED version of this switch, then you can stop reading now as the rest of this post is on how to install the LED version.

Because this switch has a series LED and the Duet electronics also has an LED with a pull up resistor, it has to be treated as an analogue switch rather than a digital switch (this was what confused me at first). So following David Crocker’s advice (DC42) I connected the switch between the In and Gnd pins of the Z probe connector, with a pull up resistor (about 220 ohm to 1 K) between in and +3.3V. The resistor value isn’t critical as long as it is within that range – lower makes the series LED shine brighter when the switch is triggered.

Here is a link to the Duet Wiring diagram. NOTE. Unless you have a very early prototype board, the diagram to use is the one at the top entitled “………v1.0, v1.01,v1,02” The lower diagram is for PROTOTYPE – don’t let the “V2” fool you into thinking that its is later than the production V1.0 versions. This is important because the Z probe pins are different.

Having got the switch connected, we now need to “tell” the Duet board what type of switch it is. In this case, it is probe type 1. The relevant gcode command is M558 and the settings can be found here So my M558 line looks like this. M558 P1 X0 Y0 Z1 F180 T6000 I1. I don’t use and form of bed probing other than for homing so the “T” parameter is irrelevant in my case.

Note that unlike the mini height sensor, the “analogue” voltage from the Metrol switch does not change gradually as the sensor gets close to the bed. Instead it simply switches from one value(zero) to another. So you cannot use the facility whereby the probing speed will slow down as the sensor gets closer to the bed so you may need to drop the Z homing speed (180 mm/min works well for me).

The last thing to do is check that the switch is working and set the trigger value and trigger height.Again, it should be noted that I don’t use any form of bed compensation so I’ve only ever used G31 for homing. If you do detailed probing, you may be using G30 or G32 but the principle will be the same.

I currently have a problem with my printer and am unable to connect using the web interface so I’ll have to do the rest of this post from memory. Apologies in advance if what you see is not what I say you will see.

This is where I discovered another command that I wasn’t previously aware of. One can use M119 to report the end stop status. With the switch open as normal, send M119 via the web control and observe the switch status in the console. Then manually close the switch and send M119 again to check that it is closed. The console on the web interface may indicate that the probe is close to the bed but not actually at the bed. This is because the trigger value may not be correct, especially if you have previously been using the IR probe. So, with the switch open, observe the probe value (top right hand corner of DWC) and should read zero. Then with the switch closed, observe the probe value again. With a 500 Ohm resistor, I had a reading of 474 and my G31 was still set for the mini IR probe with a trigger value set to 500 which is why the web interface console showed that the probe was close to the bed. The actual value will depend on the resistor you used, so set the trigger value to be about half way between zero (when the switch is open)  and the reported value when the switch is closed. In my case I used 250 so my G31 ended up as “G31 P250 X0 Y0 Z-0.8”. The “Z” value is the trigger height and is set in the usual way by using a thin piece of paper between the probe and the bed or whichever method works best for you.






Tool free swappable, bed probing hot end mount.

Like many things in life, this printer modification evolved into something much more than my original intention. By way of introduction, this picture shows my original hot end mount and X and Y axes.


As readers of my blog will know, I use a Diamond mixing hot end. This is a rather ungainly beast with 3 heat sinks sticking out at 28 degrees taking up quite a lot of space and weighing in at around 250gms (excluding any extruders). Because of the weight, the engineer in me decided that the best way to mount it would be to fix it between two parallel rails, rather than having it hanging over the side of a single rail, which is why I ended with a such a huge X carriage. It was heavy too. The X carriage including the hot end weighed 690gms and the Y carriage with the X rails fitted weighed in at 1,210gms so my combined Y axis weight was a whopping 1,900gms. Having said all that, I regular used to print at 90mm/sec with non print moves set to 350mm/sec with accelerations set to 1200mm/sec^2 and the thing was absolutely rock solid. It was impossible by hand, to “flex” the hot end in any way.

My issue was that I have another Diamond hot end, fully assembled but with a 0.9mm nozzle that I intend to use with Taulman T glass filament, and changing the hot end was a complete pain. So I set out to make a new mount that would enable me to quickly swap hot ends, preferably without the need to use any tools. I also decided to abandon the dual X rail setup and replace the two 2020 extrusions with a single 2040 extrusion. Part of me still thinks this was bad idea from a rigidity point of view, but there are other benefits such as weight savings and increased range of movement which I hope will outweigh the negatives.The next two pictures are Open Scad images of the new X carriage.



The red part is the new Diamond hot end mount. Effectively, the mount has a sort of Dovetail slot around the two sides and the bottom, into which the mount slides.This is a close up of the actual Diamond hot end mount.


At this point, I realised that I could solve another minor issue that I had. That is, I use an IR mini height sensor but I also use 3DLac on my my glass build plate, and the 3DLac can alter the reflectivity of the glass, meaning that I often had to make adjustments to my Z axis homing. The other problem I have with the IR sensor is that, because of the shape of the Diamond hot end, it is very difficult to mount it anywhere close to the nozzle.So I thought, rather than locking the hot end into place, I could hold it against it’s seat using springs which would allow it to slide up and down. I could then mount the height sensor above the hot end, rather than below it. This would mean that the hot end is itself the height probe. In the event, I discovered a Metrol positioning switch with a claimed repeatability of 0.005mm  and decided to use that above the mount but retain the mini IR sensor below the mount if the sliding arrangement doesn’t work out. I’ll cover the Metrol switch in a separate post.

It took me a few attempts to print the parts such that they would slide easily but at the same time have no “wobble”. It wasn’t too hard though because the bottom of the mount is also a “Dovetail” shape and when the springs act down on the mount, the effect is to pull the two faces together.

Of course, I have reservations about how well these plastic printed parts will last over time but I am optimistic because now that I have installed and set it all up, I have only 0.8mm of movement before the switch triggers and can probably reduce this further. The worst case scenario is that if the sliding\probing\homing aspect proves to be unreliable, I will change the design slightly to clamp the hot end in place and go back to using the mini IR probe for homing.

At least I will be able to quickly change hot ends without using any tools. Here is a little video I made showing how that all works.

As with all these things, the update was much more involved than I first though. The entire upper section of the printer has to be disassembled, including the motor mounts, idlers, and of course the X and Y rails………


………but I got it all put back together.

back together

So in practice, what happens for Z homing is that the bed rises, the nozzle touches the glass then the mount gets lifted off it’s seat and slides up until the switch triggers (currently 0.8mm) and my configuration file is set so that Z=0 is 0.8mm below the point where the switch triggers. The switch has 2mm of plunger travel but triggers at 0.3mm so there is a further 1.7mm of plunger travel available. I made use of this by building in a fail safe which is just a micro switch acting on the bed and set to trigger an emergency stop at 1mm after the point where the homing switch should trigger.


If using the nozzle itself as a means of Z homing proves to be unreliable, I have still achieved my original objective which was to have a means of quickly swapping hot ends. As a bonus, I have gained an extra 50 mm of movement in X  (now 375 mm instead of 325 mm) and 30mm in Y (now 350mm instead of 320 mm). Also, the new X carriage weighs 520gms instead of 690gms and the new Y axis (without X) weighs 820gms instead of 1,210gms giving me a total weight saving in Y of 560gms ( 1,340gms instead of 1,900gms).

The downside is that I can now “flex” the nozzle in the Y direction if I push and pull hard enough, whereas the old design was rock solid. However, I’ve just finished my first print and there is no sign of and “banding” that I would expect to see if the nozzle was moving around during a print. Also, the Z homing is working like a charm and thus far, is consistent and repeatable.

One last thought. With this mounting arrangement, I could fairly easily change to a completely different design of hot end, by making a suitable adaptor. By way of illustration. here is an adaptor that I’ve just made so that I can fit a dial gauge to level the bed.


I’ll give an update in a few weeks or months when I am able to asses how reliable and/or repeatable this turns out to be.


Late edit. I’ve just finished printing this object which is 133mm tall.


There is no sign of banding and the dimensional accuracy is pretty good. The smaller diameter should be 45mm and it measures at between 45.3 and 45.2 throughout the height. The inner square should be 21mm and measures at between 20.96 and 21.02 and the overall height measure at 132.8mm now that it’s cooled. So although it is possible to flex the hot end in the Y direction by applying force by hand, I’m reasonably confident that there is no movement during normal printing (at least in the centre of the bed).


Dual function LED ornament stands

As a change from printing lots of test pieces with no practical value, I thought it was about time I made something useful. I’ve given step by step instructions and a list of materials in case anyone else want to make any of these.

My wife has a growing collection of miniature glass and plastic Christmas trees (one or two of which I have made using Taulman T glass) which come out every year. They look more effective when lit from below so we have one or two of those led stands that one can buy. The trouble is, some of these ornaments are plain glass and look best with coloured light while others are already coloured so look best with white light. The other issue with some of the stands one can buy is that they take those really small button cells which make them expensive to run compared to using say, rechargeable AA or AAA batteries. So I decided to make some that would take rechargeable batteries and that could be switched between colour changing or white.

Initially, I had planned to use rechargeable PP3 9V batteries. These would have been easier to fit inside the base and would have meant that I could run 2 or 3 LEDs in series with a single current limiting resistor. However, when I looked into the capacity of these batteries, the amp hour rating is very low which would have meant that they would only have lasted about 8 to 10 hrs between charges. So, I decided to use AA size cells instead, which have a much higher capacity. The voltage drop across the super bright white LEDs is 3 volts and for the colour changing it was 2.4 volts (variable depending on which colour is being produced) so I needed at least 3 batteries to give me 4.5 volts and the LEDS would have to wired in series, each with it’s own current limiting resistor.

The colour changing LEDs are not as bright as the white LEDs so I decided to use 4 colour changing ones and 2 white ones.

In addition to the LEDS, I also needed a switch. I had hoped to use a miniature ON-OFF-ON slide switch but was unable to find one. The best I could find was On-On which would switch between colour changing and white but had no centre “OFF” position so I ended up using two switches. One for ON-OFF and the other for Colour – White. If you can find an ON-OFF-ON version, it would simplify the wiring quite a bit.

Then I needed clips to hold the batteries and provide electrical contact, some wire and some strip board.

The complete list of materials for one of theses stands is as follows.

2 off super bright white 5mm LEDS (one could also use 3mm)

4 off slow colour changing 5mm LEDs (or 3mm)

1 off piece of strip board 25mm x 25mm

3 off Keystone AA (-ve) contact part No 209. These are the dimensions


3 off Keystone AA (+ve) contact part number 228 as below


2 off switches PIC part number SS-22f25-G dimension as below


Printed parts – Base, Top and Insert. These can be found on Thingiverse here Printed parts files

The first thing was to make up the strip board LED modules. Each LED has it’s own current limiting resistor, the value of which will depend on the specification of the LEDs. In my case I used 220 Ohm and 180 Ohm. The +ve input to all 4 of the colour changing resistors are connected together as are the 2 +ve inputs for the white resistors. The -ve side of all the LEDS are connected together.  Here is a picture of one of the made up boards.


The 4 colour changing LEDS are on the outside and the 2 white ones are on the inside. The red wire is the +ve for the white LEDs and the Orange is the +ve for the colour changing LEDS. The black wire is the common -ve.

A quick note about using these slow colour changing LEDS. When they are first turned on, they are all the same colour and start to slowly fade to the next colour. However, they don’t all change at the same rate. So after a period if time they get “out of sync”. This results in many more combinations of colour which are more subtle than just RGB and in my opinion, give some quite pleasing effects.

The next thing was to design and print the base which holds everything together. Here is one of those bases.


And here is one with everything wired up.


The pictures should be self explanatory. The base is designed to take the switches which are a snug fit but slide in from the top. The clips for the batteries are a press fit from the top. NOTE, solder the wires to the clips before fitting the clips otherwise the heat will melt the plastic. The lower right hand battery clip is the +ve terminal which goes to the centre terminal of the ON-OFF switch which is at the top. One side of this switch goes to the centre terminal of the changeover switch which is on the right. The red wire from the LEDs goes to one side of the changeover switch and the orange wire goes to the other side of the switch. The black -ve LED wire goes to the -ve battery clip which is the top right one. The batteries are then connected in series -ve to +ve as shown by the blue wires. As I mentioned before, life would have been a lot easier if I could have found a miniature ON-OFF-ON switch rather than having to use two ON-ON switches.

Here is a finished base with batteries installed. For testing, these are just ordinary A batteries, not rechargeable. The LED board sits in a recess but I used a couple of spots of silicone sealant to hold the LED board in place (but any glue will do).


I forgot to take a picture of the top but here is an image from OpenScad


It is designed to just clip on and has 2 “prongs” which locate it and also hold the switches in place. The rectangular cut out takes a clear insert which I printed separately.


I printed the inserts using Taulman T glass clear. They simply press in and I used some clear silicone sealant to hold them in place. Here is a picture of three of them.


I actually made 10 of these. One was a working prototype so “er in doors” has 9 useful ones.


Here is a picture of one of them in white. The featured image at the top shows it in colour mode. Sorry about the reflections of my window blind which show on the top but you’ll get the idea.


I put all the files including the OpenScad file on Thingiverse so you can play around with the design as you see fit – maybe you’ll be able to find an On-Off-On switch to simplify things. Here is that link again Printer parts files







Z axis lead screws.

I just wanted to share my thoughts about lead screws and the like for Z axis motion. I have read numerous posts on various forums by people claiming that threaded rod isn’t accurate or that it is only suitable for holding things together and never for linear motion. They will then go on to say that one should use “proper” lead screws.

So my first observation is that, by definition a lead screw is a threaded rod. However, I don’t really want to enter into this endless debate, except to say that I am comfortable with my own decision to use threaded rods which were not specifically branded as being “lead screws”.

What I do have a bit of a problem with is multi-start lead screws for use on Z axes. It seems that people buy them because they are labelled “lead screw” and therefore must be superior. Many machines are built using them too – probably because the manufacturer thinks they will sell more if they can say they use “lead screws”.

One very important thing to think about is “lead” (pronounced leed not led). This not the same as pitch although often people think that it is the same thing. It happens to be the same thing for single start screws but for multi start screws, it is completely different.

To illustrate the point I have been playing around with OpenScad, wrapping a helix around a cylinder to simulate what a screw thread might look like.

Here are two images of a rod 8mm tall.



The pitch of a screw thread is the distance between two “peaks”. As you can see, there are 4 of these peaks over the length of the 8mm rod in each picture so the pitch is 2mm in both images.

This next image is the same as the top one but looking more from the top.


If you trace a line from the top of the rod and follow it around anticlockwise for 1 full turn, you’ll see that you end up exactly 1 pitch distance (2mm) below where you started. This is the lead and it means if a nut was held on the rod so that it couldn’t rotate, in revolution the nut would move 2mm. This is a 2mm pitch single start screw so also happens to have 2mm lead.

Now let’s look  at the top of the second image.


Here we can see that it is completely different and that is because it is a 4 start screw, with each helix offset by 90 degrees. Now what happens if you trace the line as before? To make it easier, I’ve taken away 3 of the threads and left just one……….



………and from the side it looks like this


As you can see, an 8mm single start screw wouldn’t have much contact area between  the screw and a nut which is why they are made with 2 or 4 threads offset by either 180 or 90 degrees to each other.

So now we can see that tracing a line for 360 degrees as before moves us the full length of the rod (8mm) so the lead is 8mm. This is a 2mm pitch 4 start lead screw and people buy them because they think that 1 revolution will mean a linear movement of 2mm when in fact 1 revolution will give 8mm of linear movement.

Why is this not a good idea for our Z axis? Firstly look again at the angle of the helix and compare it with the top picture which is a single start screw. You’ll see that it is much steeper. Therefore, a heavy Z axis bearing directly down on the rod could exert enough force such that the bed would fall under it’s own weight as soon as power to the motor is lost. Also, it will require more torque to drive the rod because it has to move the load a greater distance for a given angular movement (in the case 4 times greater). So we’ll most likely need a bigger motor.

But most importantly it will have an adverse effect on accuracy, which is ironic when people buy lead screws because accuracy is their main criteria.

To elaborate on this, I need to do a little maths. An average stepper motor moves 1.8 degrees between steps (I am aware that one can buy 0.9 degree stepper motors but they are more expensive). So, I revolution will be 200 steps assuming we have 1:1 gearing and are not using asymmetric pulley sizes. For our 2mm single start screw which has a lead of 2mm we can say that 200 steps = 1 revolution = 2mm. Or it’s 100 steps per mm which means that for a resolution of 0.1mm layer height, it will be 10 steps, 0.2mm will be 20 step, 0.3will be 30 steps etc.

Now for the 4 start, 2 mm pitch lead screw which has a lead of 8mm, 200 steps = 1 revolution = 8mm. So instead of 100 steps per mm we now have 25 steps per mm and for our 0.1mm resolution we have 2.5 steps, for 0.2mm it’s 5 steps and for 3mm it’s 7.5 steps. Which means we will be relying on micro stepping for positional accuracy for anything other than our 0.2mm layer height. And micro stepping does not improve accuracy. In general, stepper motors are quoted as having a non accumulative positional error of +-5% which for a 2mm lead screw, equates to about 0.01 mm but for an 8mm lead it becomes 0.04mm which may start to become significant with 0.1mm resolution layer height.

So, multi start lead screws are designed to give a large linear movement for a given angular movement. They require more torque to drive them and provide less holding power than a single start screw of the same pitch. Basically designed for speed which would be fine for our X and Y axes but not what we want for our Z axis.

In my opinion 2 start, 2mm pitch screws are just about acceptable or 4 start but with 1:2 gearing. Finally, this is an image representing what I use.


It’s 8mm diameter, 1mm pitch single start trapezoidal threaded rod. It gives me 20 full steps per 0.1mm and requires very little torque enabling me to use 3 of them to lift my 7.3 kg bed with a single Nema 17 stepper motor. If you look at my other posts, you’ll see that I can print 300mm x 300mm with no bed compensation (despite the fact that these screws didn’t have the “lead screw” label) so I’m happy with the accuracy. Maybe they will only last 30 years instead of 50 but who cares – they are cheap enough to replace (much cheaper then “lead screws”).

That was just my twopence worth……….






The “stripey toothpaste” effect of the Diamond hot end.

As readers of my bog will know, I have been using a Diamond hot end for quite some time. One of the issues with this hot end is that it doesn’t actually mix colours all that well. What happens is that the filament exits the nozzle somewhat like stripey toothpaste. The featured image above shows how this manifests itself. This was a simple hollow cylindrical container that I created by using a custom script to alter the mixing ratios in 1% increments at every layer change. So, the colours “fade” from 100% Red and 0% Blue to 0%Red and 100% Blue then from 100%Blue and 0% Yellow to 100% Yellow and 0%Blue and finally from 100%Yellow and 0%Red back to 100% Red and 0% Yellow.

The three pictures above are the same object viewed from different angles. The one on the left is roughly at the angle where the Blue filament enters the hot end, the one in the middle is roughly where the Yellow enters and the one on the right is roughly where the Red enters. You can see that the colour is biased towards the inlet position in the hot end for that particular filament.

The effect can be largely negated by using translucent filaments.

Or, it can be exploited. To explore this a bit further, I created a simple pyramid and orientated it on the build plate such that each face was in line with each of the filament inlet positions. I defined a single tool with mixing ratio of equal proportions for each of the 3 filaments. In this case, the filaments that happened to be loaded at the time were Red, Black and Gold. So the tool was using roughly 1/3rd of each colour. Then I printed the object just as one would using a “normal” hot end and took three pictures, each at 120 degrees around the object. Here they are:




As you can see, each face is a different colour although they were all printed at the same time, using the same tool with no fancy tool changes or post processing. The top picture shows mostly Black on the left and mostly Red on the right. The next picture down with the object turned 120 degrees shows mostly Red now on the left and mostly Gold on the right. The last picture is with object turned another 120 degrees so the mostly Gold is now on the left and mostly Black is on the right. I say “mostly” because there is some mixing of the colours on each face but they are strongly biased towards the position where each filament enters the hot end.

I just wanted to show this as an illustration that sometimes what may be seen as defective or unwanted behaviour, can be exploited to ones advantage. (That is of course if one has a need for a 3 sided object with each face being a different colour).

Now on to the next picture and one that had me baffled for some time.


I was printing something else when I came across this issue (always an issue – never a problem). So I made a simple rectangle with two holes in it, so that I could evaluate what was happening. As you can see, there is a distinct colour shift. Some sections are darker than others (or lighter depending on your point of view). It was printed mixing two filaments, Blue and White in equal proportions. It is consistent and reproducible. It will happen with any combination of extruders. i.e. extruders 0 and 1, extruders 1 and 2 or extrudes 0 and 2. There is no change in layer height or any sign of over or under extrusion. The extruder gears all appear to rotate at the same speed.

After a lot of head scratching and a lot of testing, I finally realised what was causing it. When it is printing, the infill is at 45 degrees and the head starts just below the left hand hole and moves diagonally in the direction of top left to bottom right whiles traversing toward the right hand side. This is the dark section. So it goes all around the bottom of the hole, then it reaches the right hand side of the hole after which it goes all the way to the top of the print. Then it reaches the right hand side of the right hand hole, and goes around it.

So for all of these moves, each new line of filament (apart from the first line) is supported by or squashed up against, the previous line on the left but has free space on the right.

Once the print head reaches the top right corner of the print, it then moves to the nearest unprinted section which is the top of the right hand hole, nearest to the right hand corner. To continue the print, the head still moves in the same direction diagonally but this time it is traversing from right to left instead of from left to right.

So now, for all these moves each new line of filament is supported by or squashed up against, the previous line on the right but has free space on the left.

Going back to what we now know about the filament coming out as stripey toothpaste, it is reasonable to deduce that the colour of the “mixed” filament changes depending on whether the filament is supported and/or squashed on the left with free space on the right compared to being supported on the right with free space on the left. To put it another way, it seems that the newly extruded filament rolls or twists either towards or away from the previous line of filament thus giving a predominance of one colour over another depending on the direction that the head is traversing.

At least that is my theory. It explains what I have observed happening but like a lot of theories that come up in the world of 3D printing, it isn’t actually proven. The only way to do that would be to put the prints under a microscope.

Looks like that might have to be something to add to my tool box…….watch this space……..




Latest update to blog 6th Jan – multi colour printing without wipe and prime towers.

Before I launch into this, it occurs to me that people not familiar with mixing hot ends might be confused when I talk about tool changes. I explain how to define tools in another post, so I won’t go into it again here. Just be aware that a tool change and a colour change are one and the same thing, so I apologise if might use the terms interchangeably.  Also of course, “colour” and “color” are the same thing but I’m English so to me it’s “colour”.

As I reported earlier, I found an issue with the original script when tool (colour) changes were close together. Having looked again at my feeble attempt to write code, I did find the problem – in fact I found a few.

The main issue was that the script would not move a tool change to a position earlier than the previous tool change. On the face of it, that seems logical. However, the script didn’t “remember” that the previous tool change itself had been moved to an earlier position in the file. One way to think about it is a stream of commands with tool changes at various points and we need to move all these tool changes forward in the file by an amount equivalent to, (for the sake of argument) 2.5mm of extruded filament. It shouldn’t matter if there is only 1.0mm of filament between some of these tool changes as they will all be shifted by the same amount.

That was the main thing I needed to fix but while I was looking at the code, I found a couple of other problems. The first was that the way I segmented the moves was incorrect. That is to say that the new tool position is almost invariably somewhere in an existing “XYE” move so that move has to be split, the tool change inserted and then the rest of the move completed. So one line is replaced by two lines with a tool chnage command inserted between them. The amount of filament extruded (the “E” number) was correctly apportioned to each line but the corresponding X and Y amounts were not correctly apportioned.

The other thing I found was that the new lines could be inserted in the wrong place in certain circumstances. As an example, my machine is set to do very fast “non-print” moves so it might have a line something like “G1 X170.329 Y165.990 F21000.000” (a feed rate of 21,000 mm/min or 350mm/sec) followed by “G1 F4800” which sets the speed back down, in this case to 4,800 mm/min or 80mm/sec for normal printing. I discovered that in some instances, the script would put the new segmented moves and tool  change command after the fast non-print move but before the speed change back to normal command. This would have resulted in those two print moves being executed at 350mm/sec which would have been interesting to watch!

So I have deleted the link in the original post to the Python script and here is my latest feeble attempt. It does actually get the job done but I know any professional code writer will probably burst into tears if they see it.

To save a lot of copying, pasting and formatting of text, I’ve take a number of screen “snips” of the code. The comments should make it clear as to what I’m trying to do.









I haven’t included a link to the script this time but I’ll make it available if anyone is interested. Just leave a comment if you want me to do this.