Measuring temperature the easy way

I have been asked for more details on my temperature measurement scheme so I have consolidated some of my previous articles :-

The objective is to measure temperature from room temperature to about 250°C using a thermistor. The thermistor resistance is a extremely non linear. It is approximated by a negative exponential of the reciprocal of absolute temperature.

Ro is resistance at known temperature To, in this case 25°C, expressed in Kelvin. Beta is a second parameter of the thermistor which can be calculated if you know the resistance at two different temperatures or can be found on the data sheet.

The RepRap thermistor is an Epcos B57540G0103+, data sheet here. R₂₅ is 10KΩ and beta is around 3500. Several values are given on the datasheet for different temperature ranges illustrating that the above equation is only an approximation. Here is a graph of its resistance against temperature :-


This can be made more linear by putting a fixed resistors in parallel. The magic value to use appears to be the value of the thermistor at the middle of the temperature range. In this case it is about 470Ω. Here is the resulting combined resistance, the formula for two resistors in parallel is :-

1/R = 1/R₁ + 1/R₂

I.e. the total conductance is the sum of the two conductances.


The resulting resistance is a lot more linear, however to measure temperature with an ADC we need a voltage rather than a resistance. This is easy, instead of wiring the resistor in parallel connect it in series to a voltage source equal to the full scale voltage of the ADC.



The voltage across the thermistor is then :-

V = V_ref . R_th / (R + R_th)

Here is a graph of the the output voltage when Vref is 5V.



Note that the voltage decreases as the temperature rises. This could be inverted by swapping the resistor and thermistor but I prefer to keep one end of the thermistor at 0V so I can use single screened cable. It is also a good idea to put a capacitor across the ADC input to filter out any noise when using long leads like RepRap does. I used a 10uF tantalum bead.

Another consideration is how much power is dissipated in the thermistor as it will cause heating and alter the reading. The maximum dissipation will occur when its value equals the value of the resistor. At this point half the voltage is across the thermistor so the power dissipated in it is :-

P = (V_ref / 2)² / R

In the example above this works out at 13.3mW. The thermistor datasheet specifies a maximum of 18mW and a dissipation factor (in air) of 0.4 mW /K. I think this means that the temperature will rise by 33°C by self heating. The error would be less when not in air, but it is still perhaps a bit high. My system uses a V_ref of 1.5 volts which, because it is a square law, only dissipates 1.2mW giving a 3°C rise at the mid range temperature in air.

For a 5V system is is probably worth sacrificing some of the ADC resolution to reduce the self heating error. This can be done by using two resistors :-



The full scale voltage is now :-

V_fsd = V_ref * R1 / (R1 + R2)

We also want the source impedance of this voltage, which is R1 in parallel with R2, to be 470Ω.

1/R = 1/R1 + 1/R2

Solving these simultaneous equations gives :-

R1 = R / (1 - V_fsd / V_ref)

R2 = R . R1 / (R1 - R)

So for V_fsd = 1.5V, V_ref = 5V and R = 470:

R1 = 671Ω and R2 = 1569Ω, preferred values are 680 and 1K6.

And finally here is the Python code to work out the temperature :-

from math import *

class Thermistor:
   "Class to do the thermistor maths"
   def __init__(self, r0, t0, beta, r1, r2):
       self.r0 = r0                        # stated resistance, e.g. 10K
       self.t0 = t0 + 273.15               # temperature at stated resistance, e.g. 25C
       self.beta = beta                    # stated beta, e.g. 3500
       self.vadc = 5.0                     # ADC reference
       self.vcc = 5.0                      # supply voltage to potential divider
       self.vs = r1 * self.vcc / (r1 + r2) # effective bias voltage
       self.rs = r1 * r2 / (r1 + r2)       # effective bias impedance
       self.k = r0 * exp(-beta / self.t0)  # constant part of calculation

   def temp(self,adc):
       "Convert ADC reading into a temperature in Celcius"
       v = adc * self.vadc / 1024          # convert the 10 bit ADC value to a voltage
       r = self.rs * v / (self.vs - v)     # resistance of thermistor
       return (self.beta / log(r / self.k)) - 273.15        # temperature

   def setting(self, t):
       "Convert a temperature into a ADC value"
       r = self.r0 * exp(self.beta * (1 / (t + 273.15) - 1 / self.t0)) # resistance of the thermistor
       v = self.vs * r / (self.rs + r)     # the voltage at the potential divider
       return round(v / self.vadc * 1024)  # the ADC reading

Laying it on the line

I decided to investigate the conditions necessary for multiple layers of HDPE filament to stick together so I wrote a little Python test script to extrude 20mm squares stacked on top of each other. From my graphs in equations-of-extrusion I chose an output rate of 3mm/s which gives a filament diameter of about 1.2mm. That only requires about 60% PWM which I thought was not too stressful for a 5V motor running from 12V. I set the heater temperature to 200°C. Here is the first run :-



The first two layers look reasonable and then we are into basket work! The z-axis was raising 1.2mm between each layer but, although the nominal filament diameter should be about 1.2mm, the sides were not growing at the same rate. That meant the filament was dangling allowing it to wiggle around. Next I reduced the z-increment to 1.1mm :-



Better, the first four layers are OK this time, so obviously I tried z-increment 1.0mm next :-



Much better! What is happening is that the filament is no longer cylindrical. Each layer is about 1.0mm high and 1.4mm wide. It could be due to gravity but I think it is more to do with being bent through 90° as it comes out the end of the nozzle.

The fact that the filament weaved about when the nozzle was too high made me think that the feed rate might be too fast so I did a taller test with the XY travel 20% faster :-



Another basket case! What is happening here is that there is not enough material so the filament slumps down and holes start appearing.

I went back to the original feed rate and did a couple of 20mm high tests to check consistency :-



These are actually incredibly strong in the vertical direction. I can stand on one and it takes my full weight. Here is a video of the one on the right being made, the middle section is sped up 8 times :-



I also ran a test at 160°C to see if the filament would still weld to the layer below. It did but it did not stick to the foam board.

As you can see the main defect is that the bottom corners curl up. This was completely expected from the work Forrest published here: Ten-layers-with-no-curling, so next I will try his solution of laying down a raft first.

Another defect is that the filament width varies in waves. These seem to be related to the rotation of the extruder drive screw. You can hear the motor labouring more on part of the revolution. I think it is because something in the drive is a bit eccentric but more investigation is required.

Brush off

HydraRaptor was using a knife to remove excess filament from the extruder :-



It always cut the filament OK, but it was random whether the loose bit fell off or stuck to the far side of the nozzle. The soundtrack of a video I saw of a commercial FDM machine said that they use a brush. I thought I would need a wire brush for 200°C but then I reasoned that, if the nozzle passed through fast enough, the high specific heat capacity of plastic might mean that it would not have time to melt. I decide to give it a try with an old electric toothbrush head :-



It does seem to work quite well. Here is a video of it in action :-



The scrap of filament sometimes stays stuck to the brush but subsequent passes eventually knock it off.

When I was using HydraRaptor for milling I had a tray around the table and a plastic skirt to protect the mechanism of the precious XY table from loose plastic chips. When I moved on to FDM I thought these would not be needed because it is a lot less messy. Actually I was wrong as HDPE chips are appearing, presumable from inside the extruder, and the filament offcuts sometimes ping off from the brush. I have therefore refitted the tray and skirt.

Taking up the slack

I had a problem with my HDPE filament getting unwound from its reel. Because my extruder is attached to the z-axis, the filament gets pulled off the reel as the z-axis descends, but when it rises back to the home position there was nothing to take up the slack. Also the springiness of the HDPE makes it want to unwind. It needs a constant back tension to take up the slack and keep the filament on the reel.

My first idea was to attach a small DC motor to the roller to provide a backwards pull. As the motor would be permanently stalled I would have had to limit the current to something reasonable. After some thought I came up with a much simpler solution. I wound some picture cord around the roller and hung a weight from it. As the filament unwinds it lifts the weight. The weight is also tethered to the top of the machine, so once it gets to the maximum height it stops. The reel is only a friction fit on the roller so it starts to slip at that point. When the axis ascends again the weight falls and winds the reel backwards, taking up the slack. There is enough travel on the weight to cover the full z-axis travel, even when the filament has been used down to the inner diameter of the reel.

Sticking point

Over the last few days I have been working on getting my machine to lay down straight lines of HDPE filament. It was a lot harder than I imagined. Initially I could not get it to stick to anything. I knew Forrest, who has been pioneering the use of HDPE with Tommelise, had successfully used foam board as a base to extrude onto, and the RepRap design uses a sheet of MDF for CAPA. I didn't have any foam board to hand so I tried MDF and several other things with no success at all. In desperation I then tried slowing down the extrusion to 0.75mm per second and that did the trick. I found I could then extrude onto lots of things so I tried as many as I could think of to see the pros and cons. Today I got my hands on a piece of 5mm foam board as well.

This was 3mm thick cardboard, it didn't stick very well at the ends.



Blotting paper sticks better but the heat makes it wrinkle and it leaves residue when peeled.



Funky foam, my wife's contribution, sticks too well, it gets welded in and can't be separated cleanly.



A thin sheet of HDPE cut from a milk bottle. As expected it welds and cannot be separated. It could be a useful technique though, you would have to cut round the extruded object but it would be left with a strong smooth base.



Felt adheres very well and can be peeled off again but you would end up with a slightly hairy object!



MDF adheres well and peels easily but it does leave some residue fibres on the filament.



Anti-static foam from semiconductor packaging. This insulated the filament so well that it stayed molten too long causing the ends to stretch away. It sticks well but leaves a residue and a rough surface.


Foam board works very well despite having a glossy finish. That allows the filament to be peeled off cleanly and gives it a nice smooth surface. With this quick test there was no sign of damage to the board either but Forrest has reported the foam inside can melt.



This seemed to work so well I tried upping the speed to 4mm / second and that worked fine as well.



So I should have taken Forrest's word for it and saved myself some time, but it got me thinking why does it work so well? For the filament to stick, it must remain molten long enough to bind with the surface. That means something with low specific heat capacity and low thermal conductivity should work better. Paper has a specific heat capacity that is about the same as HDPE but that is only 0.2mm thick and then you have foam which is a good insulator. I had been trying things with some surface texture for the HDPE to bind to so I was surprised when something glossy worked. I don't know what makes the foam board surface glossy, maybe it is a thin layer of of plastic that binds with the HDPE by melting itself. Or maybe there is some molecular bonding going on, out of my depth here!

The next thing to do is to tidy up the line endings by adding a delay at the start and reduce the dwell at the end. Then I should be able to draw accurate outlines and fill them in.

I have started to think ahead to the next layer and what the requirements are to make it stick to the layer below. My mental model, which may be wrong, of how the heat flow works is to translate temperature into voltage, heat flow into current, specific heat capacity as distributed capacitance and thermal conduction as electrical conductivity. The extruded filament is then an infinite number of small capacitors, charged to 200V, linked by resistors. That will meet a bigger infinity of capacitors linked by resistors charged to 20V (room temperature). When the filament meets the already extruded layer the two surfaces behave like two capacitors charged to different voltages being connected in parallel. What happens in electronics is that the total charge is preserved so V(C1+C2) = C1V1 + C2V2, i.e. V = (C1V1 + C2V2) / (C1+C2) . If the capacitors are equal then V = (V1 + V2) / 2.

That means, if my analogy holds, that when two surfaces meet the temperature at the infinitely thin junction instantaneously becomes the average temperature, weighted by their specific heat capacities. In our case these are equal because it is HDPE at 200°C meeting HDPE at 20°C. It is my belief the junction will be at 110°C to start with. Heat will flow to it from the neighboring material on the hot side and away from it on the cold side. Since its temperature is half way between the two then these flows will be equal. The junction will stay at 110°C and this band of 110°C will start to spread to the neighboring material on each side. However, to form a weld the junction must reach the melting point of HDPE which is 135°C. The only way for this to happen is for the nozzle to stay around long enough to continue to supply heat. That puts a limit on how fast filament can be laid down and still bond.

To be free of this limitation the average of the temperature of the filament and the temperature of the workpiece must be higher than the melting point. If that is the case then it will weld instantly and there is no limit on extrusion speed. For HDPE and room temperature that would mean extruding at 250°C. Anything below that requires additional heat to flow from the nozzle to form the weld and hence sets a limit on how fast it can move away.

Die swell revisited

My machine is back up and running again after replacing the thermistor and MSP430 micro. I added some high temperature insulation to keep the thermistor wires away from the heater wires in future! I salvaged it from the 10A shunt of an old multimeter that I scrapped.



I should really recalibrate the temperature measurement but after finding temperature is not too critical I can't be bothered at the moment. I might wait until I after I have blown it up again!

In my previous article Equations of Extrusion I put forward a theory for the significance of the Y axis crossing point on this graph, i.e. the minimum filament diameter at zero flow rate, was that it was the size of the hole in the nozzle.

My explanation was that perhaps I had inadvertently opened out the hole in the extruder nozzle by drilling too far from the back. While my extruder was off the machine for its new thermistor I had the opportunity to inspect the end of the nozzle.



As you can see the hole is still the correct size, 0.5mm, so my theory was wrong. My revised explanation for the minimum filament size is that HDPE is so viscous that there is a minimum pressure to make it flow through a small hole, below which it does not flow at all. The minimum diameter is then the hole size plus the die swell at that minimum pressure.

I used a fine stiff wire as a probe to try to get an idea of the depth of the hole. I think it is no more than 1mm, so I am at a loss to explain why I get variable die swell and other people do not. Perhaps my HDPE is different, I know mine is translucent whereas Forrest Higgs' is opaque white.

Dribble and smoke

Not a very good day today. I started by trying to lay down a 50mm straight line of HDPE. I completely failed and ended up smoking my machine!

The first problem I decided to tackle was extruding just the right amount of filament. This should be easy because I can instruct my extruder controller to turn the pump an exact amount. Using the equations I described last time, I know what feed rate is required to give a particular diameter filament and what its exit speed will be. The problem is that when the extruder stops, the filament continues to extrude slowly for a while afterwards. This is because the molten plastic, being non Newtonian, is compressible.

To start with I was getting about 12mm of overrun. I have noticed that the flexible drive made from steel wire gets wound up and stores some energy. With no power applied to the motor it actually unwinds a bit driving the motor backwards. By default my software was preventing that because it monitors the shaft position and applies increasing power as the shaft moves backwards until equilibrium is reached.

The host can instruct the controller to turn off the motor completely and let the wire unwind. That reduces the overrun to about 4mm. The shaft encoder sees the motor go backwards so, when it's told to move again, it regains all the backlash as fast as it can before settling down to the desired speed. Therefore, there is no loss cumulative loss of accuracy in letting the wire unwind and wind up again.

I expect the amount of filament overrun could be reduced further, or even eliminated completely by running the pump backwards a bit at the end. Unfortunately I can't do that because this is what happens to the steel wire when it is turned the wrong way:-



Because of this I designed my electronics to only be able to go forwards. Apparently this effect is not observed on the RepRap at Bath university. They are using 3mm wire, whereas mine is only 2.5mm, so that might account for it. I may see if I can get better wire that won't unwind. If so I will have to upgrade my drive to an H-bridge to allow the motor to be reversed. There isn't any spare room on my Vero board so I will either have to make a new one or make some sort of 3D creation.

In the meantime I decided to bodge round the problem. As well as the 4mm overrun when the motor stops, it also extrudes about 15mm when the heater is allowed to cool down and is then warmed up again. This is usually accompanied by a sharp cracking sound which sounds like trapped air bursting through the HDPE. I am not sure of the exact mechanism, but air must get in when the plastic is cold and contracted and then get trapped while it is heating up again, forcing some molten plastic out. Perhaps I have discovered a new type of pump with no moving parts!

So, before I can start extruding I need to remove the excess filament hanging from the nozzle. I did this by attaching a scalpel blade to one corner of my XY-table and having the machine visit it to wipe its nose just before starting to extrude. It is just a lash up at the moment, it would be better if it was 20mm above the table and a razor blade might be better, but it seems to work OK.



Of course, once the overrun has occurred and been removed, there is a net deficit of material which manifests itself as a delay before extrusion starts when the motor is switched on again. That has to be made up by starting the extruder in advance of moving the table for the first line segment.

So the next step was to lay down the filament on the table in a straight line. The first problem was that I discovered a bug in my software that meant the table only moved at half the specified rate. So any previous references to milling feed rates in this blog need to be halved!

The bug was easily fixed of course but I could not get the filament to stick to my table. When it hits the table it curls upwards into a loop and sticks to the side of the hot nozzle. The table surface I used for milling is made of upside down laminate flooring. It is covered with a textured layer of what I assume is probably some sort of vinyl. No great surprise it didn't stick, the next thing I tried was paper, a post-it note to be precise. That did not work either so the next thing to try was MDF. I taped an 18mm block to the the table for a quick test and raised the z position by 18mm, but I forgot to program it to raise up to clear it after visiting the knife. The result was the nozzle collided with the block and that pushed the thermistor wires so they touched the heater wires.

The result was quite spectacular, the thermistor wires, being quite thin, lit up like a light bulb before burning out. The thermistor is toast and so is the micro. Three volt micros don't like 12V up 'em!

I should have insulated the wires but I didn't have any insulation handy that would stand the temperature. Also three 3A diodes in series across the thermistor would have saved the day but it's a bit late now.

Fortunately I have a couple more micros and a spare thermistor but the machine will be out of action for 24 hours while the JB-Weld cures.

It is very easy to get a tool crash with a 3D machine and it usually causes a lot of damage. When I was using it as a milling machine I got into the habit of getting it to mime what it was going to do by running the program with a Z offset higher than the workpiece. I should have done the same thing this time.

Equations of Extrusion

When I first tested my extruder I found that the filament diameter varied with the flow rate and temperature. This was contrary to what others have experienced so I decided to investigate further. It turns out that this is known as die swell and is caused by non Newtonian fluids expanding after they have been squeezed through a hole. Apparently it is a very complicated subject.

To get an idea of what was going on I designed my extruder controller to be able to make measurements. Rather than drive the motor with open loop PWM I used a shaft encoder with proportional feedback. Instead of specifying what PWM setting to use, the host specifies how many shaft encoder steps to move and at what rate. The extruder controller then adjusts the PWM to maintain the correct shaft position at any given instant. Assuming the filament does not slip against the drive screw, that means I can extrude a known volume of plastic in a known time to the tolerance of the the original feed material. The host can then ask the controller what the total on time and off times have been so that it can calculate the average power that has been used.

My temperature control works in a similar way. The host calculates the resistance the thermistor should have at the desired temperature, and from that, what voltage reading the ADC should produce. It sends that setting to the controller which turns the heater on and off. Again it keeps track of the total on and off times so that the host can calculate the average power.

My heater has a resistance of 8.5Ω and has 11.8V across it after the drop in the MOSFET switch and the wiring. That gives a power of 16.4W. This is a graph of the temperature reading from the thermistor plotted against the heater duty cycle :-

As you can see it is not quite a straight line. This is because the resistance of the nichrome heating element increases slightly as it gets hotter, so power does not quite rise in line with the duty cycle. I measured the resistance at 200°C to be 9.7Ω. Using the formula:

R = R₀[1 + α(T − T₀)]

that gives a temperature coefficient α of 7.8 × 10^-4 which is about twice the figure I found on the web for nichrome. I expect that it varies widely according to the exact alloy being used.

Here is a graph of temperature against power, calculated using the above formula for resistance :-

It is a lot closer to the straight line I was expecting.

I decided to investigate how much extra power is needed to heat the incoming plastic when extruding. I found that while feeding the filament in at 1mm/s, which is about the maximum my motor can do, the PWM to maintain 200°C increased from 44.6% to 61.2%. An increase of 16.6% corresponding to an extra 2.4W. Feeding a 3mm filament at 1mm/s gives a flow rate of 7.1 × 10^-3 cc/s. HDPE has a density of around 1 so that is 7 × 10^-3 g/s. The specific heat capacity is 2.2 J/g-°C which gives 2.8W to heat 7 mg from 20°C to 200°C per second. I think that is reasonably close to the value I measured, given that HDPE has quite a wide range of densities.

Next I decided to look at the effect of temperature on the motor power required to extrude at a given rate :-

I concluded that temperature has little effect on the motor power required, except when it gets close to the melting point, where it rises rapidly as expected. That was how I broke my extruder!

Next I looked at filament diameter against temperature :-

No real correlation, so it seems temperature is not very important as long as it is above the melting point. This was a surprise to me as I imagined molten plastic would get less viscose as temperature increased. It may become more critical when I start laying down filament as it will effect how it fuses together and shrinks. I did all the subsequent measurements at 200°C.

Feed rate (in mm/s) against PWM was another surprise. I expected power to rise rapidly with feed rate but, in fact, it is quite proportional :-

Presumable 30% is the power required to overcome static friction in the system.

Here you can see the output rate versus the feed rate :-

It does not increase in proportion, so if conservation of matter is true then it must be getting bigger in diameter. Indeed it does, here is output diameter against output rate :-


Either it is a very complex relationship with multiple inflexions or it is just linear with lots of measurement error. I made three measurements per test with digital calipers and took the average but the deviation between samples was quite high.

I prefer to think it is a simple linear relationship which means I can make a simple mathematical model of my extruder. As you can see it will hit the Y axis at about 0.93 mm. I think that must be the size of the hole in my nozzle. I drilled it 0.5mm but perhaps I drilled the hole from the back too far and opened it out a bit. It seems to have got bigger with use because I could get 0.8mm filament when I first tested it but I don't seem to be able to now, even at very low extrusion rates.

So if the filament diameter equals hole size plus a constant times extrusion rate then from conservation of volume I can relate the output rate to the feed rate.

d_o = d_h + kv_o

v_od_o² = v_id_i²

So: v_o(d_h + kv_o)² = v_id_i² a cubic equation!

Where d_o is the output filament diameter, d_i is the input filament diameter, d_h is the nozzle hole diameter and v_o is the output filament speed, v_i is the input filament speed.

With these equations I can calculate the output rate to get a particular filament diameter. That also tells me how fast to move the head. From the output rate I can also calculate the feed rate required.

Conclusion? Well I definitely have die swell which increases with extrusion rate but other people have reported constant die swell. The only explanation I can think of is that I drilled my nozzle too deep from the back so the aperture has almost zero thickness instead of the 0.5 to 1mm expected.

I have a simple mathematical model which allows me to exploit the variable filament width if I need to. This may all become irrelevant when I start laying down filament to build things because the filament can be stretched or compressed if the head movement does not match the output rate.

Tomorrow I will try laying down the filament.

Self destruction

Not managed any self replication yet but my machine has done a bit of self destruction!

While doing some experiments running my extruder at different speeds and temperatures, I managed to run it at too low a temperature such that it forced the PTFE barrel out of its clamp. That broke off one of the heater wires under the JB Weld. Fortunately I was able to dig out the end of the nichrome and reconnect it. I soldered the joint but that is not the best idea as solder melts at 183°C and I am running my barrel at about 200°C. The heater gets a bit hotter than that. Presumably molten solder is still a good conductor. The ideal way to make the connection would be with a miniature barrel crimp but I don't know if they exist. Here it is repaired :-



Clamping a very slippery plastic rod with a clamp made out of a slightly less slippery plastic is probably not the best design.

I seem to spend as much time stripping down and rebuilding my extruder as I do running it. Looking on the bright side at least the thermistor didn't fall off again despite some rough treatment. Here it is all back together again and working :-

Temperature drop

My extruder controller is working much better after I cured the motor noise problem. The 10 bit SAR ADC also seems to work better than the 16 bit sigma-delta version did. With the 16 bit one there was a lot of noise on the readings, even when the motor wasn't running. I had to average over many samples to get a consistent reading which delayed the response. With the 10 bit ADC I just read it and compare it with the temperature set point value to decide if the heater should be on or off. That gives a temperature swing of about ± 3°C with the heater going on and off every four or five seconds.

The temperature is calculated from the ADC reading and vice versa by the PC with the following Python class :-

from math import *

class Thermistor:
 "Class to do the thermistor maths"
 def __init__(self, r0, t0, beta, r1, r2):
     self.r0 = r0                        # stated resistance
     self.t0 = t0 + 273.15               # temperature at stated resistance, e.g. 25C
     self.beta = beta                    # stated beta
     self.vref = 1.5 * 1.357 / 1.345     # ADC reference, corrected
     self.vcc = 3.3                      # supply voltage to potential divider
     self.vs = r1 * self.vcc / (r1 + r2) # effective bias voltage
     self.rs = r1 * r2 / (r1 + r2)       # effective bias impedance
     self.k = r0 * exp(-beta / self.t0)  # constant part of calculation

 def temp(self,adc):
     "Convert ADC reading into a temperature in Celsius"
     v = adc * self.vref / 1024          # convert the ADC value to a voltage
     r = self.rs * v / (self.vs - v)     # resistance of thermistor
     return (self.beta / log(r / self.k)) - 273.15        # temperature

 def setting(self, t):
     "Convert a temperature into a ADC value"
     r = self.r0 * exp(self.beta * (1 / (t + 273.15) - 1 / self.t0)) # resistance of the thermistor
     v = self.vs * r / (self.rs + r)       # the voltage at the potential divider
     return round(v / self.vref * 1024)    # the ADC reading

It is instantiated as follows :-

thermistor = Thermistor(10380, 21, 3450, 1790, 2187)

10380 is the resistance of the thermistor measured by my multimeter at a room temperature of 21°C. 3450 is the beta of the thermistor taken from the data sheet. The last two values are the two resistors forming a potential divider with the thermistor wired across the second one, again the values are measured with a multimeter. The fudge factor of 1.357 / 1.345 corrects the MSP430 internal reference voltage so that it agrees with the multimeter.

The result seems to track the temperature measured by a thermocouple to within about 5°C, good enough for me. Just as I had finished checking it, I knocked the thermistor leads with my thermocouple and it fell off. It was stuck to the brass nozzle with JB Weld but I forgot to roughen the surface first. I am now waiting 16 hours for it to set again.

The extruder controller firmware is only about 400 lines of C. As well as temperature control it also controls the DC motor precisely using the shaft encoder and handles the I²C protocol.

I have now completed all the mechanical parts, the electronics and the firmware. I just need to get the RepRap host code to talk to my non standard hardware to complete the machine.

DC to daylight

Well my machine is not going to pass any EMC regulations, my wife is complaining it is interfering with the digital TV downstairs! The amount of noise coming from the little GM3 gear motor is astonishing. This is the motor switching waveform on the top trace and the other lead of the motor which is at 12V on the bottom trace. The vertical scale is 20V and the timebase 0.4mS.



In this instance the motor is being powered for about 300 uS every 1.3 mS when its negative lead is driven to ground. When the motor is switched off the voltage shoots up above 12V due to the back emf. It gets capped at 48V by the over voltage protection of the BTS134 low side switch that I am using to drive it. It then has a damped oscillation at about 6KHz before settling down to 12V for the remainder of the off period. This will be due to the inductance of the motor windings resonating with the 100nF capacitor I put across the motor terminals. Although it looks violent it is actually the smaller burst of noise on the right which is causing all the problems.

Here is a close up of a similar burst of noise with a timebase of 10uS.



This is around 20MHz and you can see it gets onto the 12V rail. It is caused by the sparks at the motor brushes. Sparks emit RF energy from DC to daylight as I was once told by an EMC expert. My guess is that 20MHz is the resonant frequency of the motor windings with their own stray capacitance when they are momentarily disconnected from my suppression capacitor by the commutator.

One nasty aspect of this sort of noise is that it tends to get less as the motor brushes wear in and then get worse again as they start to wear out. I remember a project where a small motor was mounted close to a PIC. The PIC would frequently crash when the device was first run, but it would soon become impossible to recreate the problem until a new motor was fitted. I read that it is a good idea to "break in" DC motors by running them without any load at a low voltage for a few hours to allow the brushes to become a good fit to the commutator. Too late for mine though!

This is what the noise that gets onto the I²C lines looks like :-



A tough challenge then to make I²C reliable in this environment!

I began by stopping the comms from locking up so that I could add a retry scheme. To do that I had to put timeouts in all the points where I was waiting for the master controller to do something. When it times out I have to reset the controller and do one manual clock pulse to free up the slave before delaying 100uS and then re-enabling the controller. That stopped the comms locking up but did nothing to preserve data integrity. E.g., while I was sending motor commands and reading the temperature the heater came on of its own accord, not good!

The next thing I did was add an 8 bit CRC checksum to the end of each message so that I can detect when a message has been corrupted. 8 bits should be sufficient because the messages are only a few bytes long, i.e. less than 2⁸ bits, and the bursts of noise are only a few bits long, i.e. less than 8. I used a table driven method so the software overhead is just a 256 byte table, one XOR and a table lookup.

I also added a sequence flag to the top bit of the command byte. This alternates when a new command is sent but does not on a retry. This enables the slave to ignore retried commands resent by the master because the previous reply from the slave has been corrupted.

The result seems to be robust even with the massive amount of noise present but I don't like to paper over hardware problems with software. To make systems like this completely reliable I aim to get no retries in normal operation and only rely on the protocol to handle exceptional events. The root cause is the noise from the motor so I decided to have a go at tackling that.

I took a closer look at the noise on the motor leads without any suppression :-



It looks pretty random and different on each wire which is to be expected because the two brushes spark independently. Here is a spectrum analysis :-



It peaks at 23 MHz but must in fact go all the way up to over 600 MHz to affect the television. There is also a lot of noise on the can. My first attempts to suppress it were to put a 100nF disc ceramic across the terminals and earth the can. That did not work well at all. I found that a more modern 1nF capacitor across the terminals worked better and leaving the can floating was better than grounding it because that just put noise on the ground rail. The old and new capacitors are shown below :-



It is no surprise the me that the smaller one works better at higher frequencies because it is so much physically smaller its inductance will be less. It is also much kinder to the MOSFET driving it!

Doing a bit of research I found that it is common practice to connect a capacitor from each terminal to the can, so I added two more 1nF caps forming a triangle. That worked well as it got the retries on the I2C bus down to zero, and also stopped the TV interference. I could have stopped there but there was still plenty of noise visible on the scope. I added two small ferrite bead inductors that I salvaged from a very old disc drive, one in series with each lead, and put a small 10nF ceramic across the cable. That made a fantastic filter leaving no noise visible on the scope.




I also decided to add a back emf clamping diode rather than rely on the over voltage protection of the MOSFET. 48V across a 5V motor is a bit much after all and is high enough to give an electric shock.

Here is the resulting filter mounted on Vero board and fitted to the motor :-



The 1nF cap across the motor is hidden by it and the other two are underneath :-



And here is the new switching waveform with pretty much all overshoot, ringing and noise eliminated :-



If only all EMC problems were that easy!

Bus stops

The I²C bus not working was more of a problem. I had some issues when I just had the spindle controller connected, see bodge-it-and-move-on, but at that time I did not have a storage scope so I could not get to the bottom of it. In the meantime I bought a cheap 100 MHz 2 channel USB scope so I was able to find out what was going wrong.



As I have indicated above, the clock line has two glitches where it should have a proper clock pulse. The master generates the clock but the slave is allowed to stretch it by extending the low portion. Normally it is hard to tell which device is driving the bus but in this case it is obvious because I got the pull up resistors too small for the MSP430. I forgot that the MSP430 is aimed at low power applications so has an unusually low drive capability.

I still wasn't sure which end was the problem so I coded the host end in software so I could see exactly what the slave was doing. It is relatively easy to do an I²C master in software because it does not have any strict timing deadlines. The slave does, so it is more difficult to implement purely in software.

It turns out the problem lies with the mask revision of the MSP430F2013s that I am using. Revision B has several I²C bugs such as pulling the clock low when it shouldn't and no workarounds. I have had my chips for some time, long before I started this project. Two are actually labeled with a mask revision of X which is undocumented. It seems to have at least all the bugs in mask B. The other is labeled as mask B, so none are of any use for I²C!

Very disappointing that these days a device has to have three or four mask revisions just to get something as simple as an I²C module working. This seems to be the way things are going: hardware is becoming just as buggy as software. I wasted some time at work recently discovering that the UART in a PIC18F65J10 occasionally inserts zero bytes in the middle of your packet. These things were lab exercises when I was an undergraduate, now big companies can't get them right.

Fortunately, I had some MSP430F2012s that were mask revision B and the I²C bugs were fixed one revision earlier on that chip. They are slightly different in that they have a 10 bit SAR ADC instead of a 16 bit sigma-delta ADC. This is actually more appropriate for my application but it has a completely different software interface and voltage range.

Once I had swapped to the MSP430F2012 and modified the firmware for the new ADC, the I²C bus sprang into life. That was until I started to run the motor whereupon I got occasional bus lockups. This is due to the massive amount of noise coming from the brushes of the DC motor. I get about 2.5V of noise on the I²C lines

Using I²C without buffers for anything other than inter IC comms is a really bad design decision, I am not sure what came over me. I normally use RS485 differential comms when linking boards that drive motors or other high current loads and have never had a problem with noise. I even think I have publicly criticized the RepRap design for converting the RS232 to 5V signals before sending it around the ring of control boards. It was tempting to give I²C a try because I already had micros that support it, and didn't have UARTs, and my screened cable is only about a foot long. I²C is particularly susceptible to noise though because it is only actively driven low and because it is edge sensitive. Also the data rate I chose is five times faster than RepRap uses and I am using 3.3V logic rather than 5V. I²C also has the nasty feature that corruption can cause the bus to lock up which doesn't happen with asynchronous comms.

One thing I noticed was that earthing the can of the motor made things a lot worse by coupling the noise onto the ground rail. I established that the noise is conducted rather than radiated by running the motor from a separate bench PSU. I also managed to get it to run reliably by adding some 2200pF capacitors to the I²C lines, but that is a horrible bodge! Other things I will try :-

1. Change the pullup resistors from 1K to 2K2 so that the MSP430 can pull them fully low. That will increase the logic low noise immunity but make the logic high immunity worse.
2. See if I can program the master to clear the bus lockup.
3. Add a CRC and packet sequence flags so I can detect errors and do retries.
4. See if I can suppress the motor better.

If that doesn't fix it I may have to rethink the design. There are such things as high voltage I²C buffers but I expect they are SMT only. I could switch to differential comms or use a better DC motor, or replace it with a small stepper motor. That would also eliminate the need for a shaft encoder but I may struggle for torque.