Monday, 24 September 2007

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 :-

Saturday, 22 September 2007

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.

Tuesday, 18 September 2007

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 28 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!