## Tuesday, 29 December 2009

### Cooking with HydraRaptor

I needed to assemble some PCBs recently, so I set about making a temperature controller for my SMT oven.

First I had to replace the solid state relay on HydraRaptor.

Solid state relays are triacs with an optically coupled input, zero crossing switching and built in snubbers. I used it for controlling a vacuum cleaner when milling. It was massively overrated but for some reason it failed some time ago. I replaced it with a cheaper one and added a varistor across the mains input to kill any transients, as that is the only explanation I can think of for the old one's demise.

The next task was to write a simple graphing program in Python. I tested it by plotting the response of my extruder heater.

With bang-bang control it swings +/- 2°C with a cycle time of about ten seconds.

Here is the code for the graph: -
from Tkinter import *class Axis:  def __init__(self, min, max, minor, major, scale):      self.scale = scale      self.min = min      self.max = max      self.minor = minor      self.major = majorclass Graph:  def __init__(self, xAxis, yAxis):      self.xAxis = xAxis      self.yAxis = yAxis      self.root = Tk()      self.root.title("HydraRaptor")      self.last_x = None      frame = Frame(self.root)      frame.pack()      xmin = xAxis.min * xAxis.scale      xmax = xAxis.max * xAxis.scale      ymin = yAxis.min * yAxis.scale      ymax = yAxis.max * yAxis.scale      width  = (xmax - xmin) + 30      height = (ymax - ymin) + 20      #      # X axis      #      self.canvas = Canvas(frame, width = width, height = height, background = "white")      for x in range(xmin, xmax + 1, xAxis.minor * xAxis.scale):          self.canvas.create_line(x, ymin, x, ymax, fill = "grey")      for x in range(xmin, xmax + 1, xAxis.major * xAxis.scale):          self.canvas.create_line(x, ymin, x, ymax, fill = "black")          if x == xmin:              anchor = "nw"          else:              anchor = "n"          self.canvas.create_text((x, ymax), text = x / xAxis.scale, anchor = anchor)      #      # Y axis      #      for y in range(ymin, ymax + 1, yAxis.minor * yAxis.scale):          self.canvas.create_line(xmin, y, xmax, y, fill = "grey")      for y in range(ymin, ymax + 1, yAxis.major * yAxis.scale):          self.canvas.create_line(xmin, y, xmax, y, fill = "black")          if y == ymin:              anchor = "se"          else:              anchor = "e"          self.canvas.create_text((xmin, ymax + ymin - y), text = y / yAxis.scale, anchor = anchor)      self.canvas.pack()      self.canvas.config(scrollregion=self.canvas.bbox(ALL))      self.root.update()  def scaleX(self,x):      return x * self.xAxis.scale  def scaleY(self,y):      axis = self.yAxis;      return (axis.max + axis.min - y) * axis.scale  def plot(self, line, colour = "blue"):      for i in range(len(line) - 1):          self.canvas.create_line(self.scaleX(line[i][0]),                                  self.scaleY(line[i][1]),                                  self.scaleX(line[i+1][0]),                                  self.scaleY(line[i+1][1]), fill = colour)      self.root.update()  def addPoint(self,p, colour="red"):      x = self.scaleX(p[0])      y = self.scaleY(p[1])      if self.last_x != None:          self.canvas.create_line(self.last_x, self.last_y, x, y, fill = colour)      self.last_x = x      self.last_y = y      self.root.update()  def __del__(self):      self.root.mainloop()
The third task was to interface a thermocouple to HydraRaptor. I had a spare analogue input, so I attached one of Zach's thermocouple sensor boards to it. I tested it by attaching the thermocouple to a light bulb with Kapton tape. I then ran a program that turned the bulb on and then off and graphed the temperature response.

As you can see there is a ridiculous amount of noise on the readings. I tracked this down to switching noise on HydraRaptor's 5V rail, which is generated by a simple buck converter from a 24V rail. The AD595 datasheet claims that it has a power supply sensitivity of only 10mV/V so the error should have been a small fraction of a °C. All I can assume is that its rejection of high frequency noise is far less than its DC supply rejection. In fact, pretty much all the supply noise appears on the output.

I fixed it by filtering the supply with a simple RC filter consisting of a 1K series resistor and a 22uF capacitor. I fitted these to the thermocouple board in the unused holes intended for an alarm LED and its series resistor. The power is fed in via the anode connection for the LED. It feeds to the supply rail via the 1K fitted in the R1 position. The positive lead of the capacitor goes into the original +5v connection to the board. The negative lead goes to the GND connection together with the ground lead. This mod will be required whenever the 5V rail comes from a switch mode supply rather than a linear regulator.

Here is the much improved graph with the filter fitted: -

The next thing I tried was bang-bang control of the oven to a fixed temperature with the thermocouple attached to a scrap PCB. No great surprise that there is massive overshoot due to the thermal lag caused by the loose coupling of the PCB to the heating elements via air.

It is obvious some form of proportional control is required, so I implemented PWM control of the mains supply to the oven. As triacs don't turn off until the end of the mains cycle there is no point in varying the pulse width in less than 10ms increments (in the UK). So I implemented a simple firmware scheme where I can specify how many 10ms units to be on for out of a total period, also specified in 10ms units. Setting the period to 1 second allows the heating power to be expressed in 1% units.

My original plan was to implement a PID controller, but after examining the required soldering profile I decided a much simpler scheme would probably perform better.

The is a profile for tin-lead solder that I got from an Altera application note. I mainly use leaded solder at home because the lower melt point gives a much bigger margin for error, it wets and flows a lot better, the fumes are less toxic and it doesn't grow tin whiskers.

Looking at the profile you can see the times are not too critical, but the temperatures are. I reasoned I could simply apply fixed powers to get the right temperature gradient until each target temperature was reached. To get round the overshoot problem I simply measured the overshoot and subtracted it from the target temps.

After a little experimenting I got this profile, which looks pretty good to me: -

The blue line is the target profile, red is actual and the green lines show the time at which each target was reached.

The preheat slope and re-flow slope are simply full power until the temperature is equal to the target minus the overshoot. During the first half of the soak period I had to ramp the power from 0 to 50% to get it to turn the first corner without overshoot. When the reflow peak minus the overshoot is reached I simply turn the oven off. When it gets to the cool section I open the oven door.

Here is the code: -
from Hydra import *from Graph import *profile = [(10,20), (120,150), (210,180), (250,210), (330, 180), (420, 20)]slope = 140.0 / 100overshoot = 15.0pre_overshoot = 25preheat_temp = 150.0soak_temp    = 180.0soak_time    = 90.0reflow_temp  = 210.0melt_temp    = 183.0preheat_slope = (soak_temp - preheat_temp) / soak_times_preheat = 1s_soak = 2s_reflow = 3s_cool = 4def interp(profile, x):  i = 0  while i < len(profile) - 1 and profile[i + 1][0] < x:      i += 1  if i == len(profile) - 1:      return 0  p0 = profile[i]  p1 = profile[i+1]  return p0[1] + (p1[1]-p0[1]) * (x - p0[0]) / (p1[0] - p0[0])def oven_cook(profile):  hydra = Hydra(True)  try:      xAxis = Axis(min = 0,  max = 500, minor = 5,  major = 25, scale = 2)      yAxis = Axis(min = 10, max = 250, minor = 5,  major = 20, scale = 2)      graph = Graph(xAxis, yAxis)      graph.plot(profile)      t = 0      state = s_preheat      m_state = s_preheat      hydra.set_mains(100,100)      while t < xAxis.max:          sleep(1)          temp = hydra.get_temperature()          print temp          graph.addPoint((t, temp))          #          # Control the power          #          if state == s_preheat:              if temp >= preheat_temp - pre_overshoot:                  hydra.set_mains( 0, 100)                  t_soak = t                  state = s_soak          elif state == s_soak:              power = (t - t_soak) * 100.0 / soak_time              if power > 50:                  power = 50              hydra.set_mains(int(power), 100)              if temp >= soak_temp - overshoot * preheat_slope / slope:                  hydra.set_mains(100,100)                  state = s_reflow          elif state == s_reflow:              if temp >= reflow_temp - overshoot:                  hydra.set_mains(0,100)                  state = s_cool          #          # Draw the time lines          #          if m_state == s_preheat:              if temp >= preheat_temp:                  graph.plot([(t,10), (t,temp)], "green")                  m_state = s_soak          elif m_state == s_soak:              if temp >= melt_temp:                  graph.plot([(t,10), (t,temp)], "green")                  m_state = s_reflow          elif m_state == s_reflow:              if temp < melt_temp:                  graph.plot([(t,10), (t,temp)], "green")                  m_state = s_cool          t += 1      hydra.init()  except:      hydra.init()      raiseoven_cook(profile)
This is the first board I soldered with it: -

All the joints were good. I had a few solder balls and some bridging but that was due to not getting the right amount of paste on each pad. I will be working on a solder paste dispenser soon!

I need to do some more testing to see if the arbitrary algorithm will work with large and small boards and with inner planes, etc. It relies on the overshoot being fairly constant, although with leaded solder you have some leeway.

I also want to play with PID to see if I can get a more general solution. The problem I see is that PID does not look into the future, so will always overshoot somewhat, which is exactly what you don't want. I think rather than using the angular profile, that is impossible for the oven to follow, I would have to put in a rounded curve, such as the one the oven actually follows now, as the control input.

## Monday, 21 December 2009

### Reliable extruder at last?

... well only time will tell but I have now fixed all the teething problems on my "no compromise" extruder.

The first problem was it was leaking plastic. I simply tightened the thread about another quarter turn while hot. The problem started when I had to dismantle it to replace the first resistor that I damaged. When I put it back together I didn't get it tight enough as it is difficult to judge when full of plastic and hot. The seal relies on the fact that the relatively sharp edge of the stainless steel tube can bite into the softer aluminium. It seems to work when tightened enough.

The other problem was that the motor would skip steps in the middle of a build for no apparent reason. It seems the amount of force required to extrude varies wildly for which I have no explanation, but I did find some mechanical issues that were reducing the torque available.

I noticed the gear would always be in the same position when the motor skipped. I found that the grub screw was catching on the bearing housing. You would expect it just to grind the PLA away, but PLA is very hard, so it would take a very long time to do so. I increased the clearance around the wheel hub and also around the moving part of the ball bearings.

Another issue was that both the worm and the gear were slightly off centre on their shafts, so when the two high points coincided they would bind. The hole in the Meccano gear is slightly bigger than the 4mm shaft it is on, not sure why. The hole I drilled in the worm is 5mm but the MakerBot motors have imperial shafts about 4.75mm, so that was even more eccentric. Added to that was the fact that the motor bracket has a slight warp to it angling the shaft down a little. All these things conspired to make it stiff to turn once per revolution. I fixed it by tightening the bottom motor screw tight and slackening the top two a little. That was enough to reliably extrude PLA. Making the motor holes into slots would make things less critical.

Although the extruder was working reliably for PLA I wanted more torque in reserve, so I switched to a higher torque motor more suited to my driver chip. The Lin motor I was using was rated at 0.3Nm holding torque for 2.5A, but my controller can only manage about 1.5A without some better heatsinking. I switched to the Motion Control FL42STH47-1684A-01 which gives 0.43Nm at 1.7A. So at 1.5A I have gone from 0.18Nm to 0.4Nm, i.e. doubled the torque and also got the right shaft diameter to fit the hole I drilled in the worm.

The only downside is that it is bigger and heavier, not really an issue on HydraRaptor.

To give it a thorough test I printed off a couple of Mendel frame vertices.

These take about 2 hours each with 0.4mm filament, 25% fill, double outline at 16mm/s, infill at 32mm/s. Six are needed in total.

I still have to test it with HDPE and PCL., I know it works with ABS.

## Sunday, 13 December 2009

### Motoring on with the A3977

Previously I have blogged about how to set up the Allegro A3977 driver chip to suit a particular motor: -

hydraraptor.blogspot.com/2009/07/lessons-from-a3977
hydraraptor.blogspot.com/2009/08/motor-math
hydraraptor.blogspot.com/2009/08/mixed-decay-mixed-blessing

Most boards I have seen using the A3977 and similar chips just have a current adjustment, with all the other values fixed. Unless you strike lucky this is not going to allow accurate microstepping because the off time and PFD need to be adjusted to suit the motor and supply voltage.

A while ago Zach sent me samples of the prototype V3 stepper controller kits and the NEMA17 motors used on the MakerBot. I made up the board using my SMT oven (pizza oven controlled by HydraRaptor, more on that later).

It works well, but the initial component values are not optimum for the motor, so I decided to make a test bench from the older prototype board that I have been experimenting with. I RepRapped a chassis for it with a panel to mount some switches to vary the timing components.

The chassis is one of the biggest parts I have made, not in volume, but in overall expanse. It warped a little, despite being PLA, heated bed coming soon!

The switch on the left must be at least 20 years old and the one on the right more than 40 but they both still work fine. I save all this junk and eventually it comes in handy.

I also have potentiometers on V
ref and PFD, so together with a bench PSU and a signal generator I can vary every parameter.

I knocked up a label on a 2D printer, it's so much easier to make this sort of thing than it was when the switches were born!

Zach has updated the board to have four preset potentiometers to make it fully adjustable. There are test points to allow the pots to be set to prescribed values with a multi-meter.

Vref and PFD can be measured as a voltage, but the two RT values have to be set by measuring resistance with the power off. My multimeter seems to give accurate readings of these despite them being in circuit. A good tip is to measure the resistance with both polarities and if it reads the same either way round then it is most likely the chip is not affecting the reading.

So here is a list of motors and optimised settings: -

## MakerBot Kysan SKU1123029 NEMA17

This is the motor that MakerBot use for the axis drive on the Cupcake, details here. It is actually a 14V motor, so is not ideally suited to being driven from a 12V chopper drive. You normally want the motor voltage to be substantially lower than the supply.

You can't run it at its full current because the duty cycle would tend to 100%. With a fixed off-time, the on-time tends towards infinity and the frequency drops into the audio range.
In practice I found the maximum current at 12V was 0.3A, any higher and the microstepping waveform was distorted on the leading edge due to the current not being able to rise fast enough.

To maintain the sinusoidal waveform at faster step rates requires the current to be lowered further, 0.25A gives a good compromise. It is not a bad idea to under run steppers anyway, otherwise they can get too hot for contact with plastic.

I used the minimum values for CT and RT, i.e. 470pF and 12K to keep the chopping frequency as high as possible, so that it is outside of the audio range. Not only is this a good idea to keep it quiet when idling, but also you want it much higher than your stepping frequency, otherwise they beat with each other.

The values give a minimum frequency of ~17kHz @ 0.3A and a maximum of ~150kHz on the lowest microstep value.
17kHz is not audible to me, but younger people might be able to hear it. There is still some audible noise at the point in the cycle when both coils have similar currents and so similar high frequencies. The beat frequency, which is the difference of the two, is then in the audio range. It isn't anywhere near as loud as when the chopping is in the audio range though.

I can't see any spec for the maximum switching frequency although a couple of parameters are given at less than 50kHz. I suspect 150kHz is a bit on the high side, which would increase switching losses, but with such a low current compared to the rating of the chip I don't think it is a problem.

One problem I had initially was that the switching waveform was unstable. It had cycles with a shorter on-time than required, which let the current fall until it then did a long cycle to catch up. The long cycle gave a low frequency that was back in the audio range.

I think it was a consequence of the motor needing a very short off-time in order to be able to have the duty cycle nearly 100%. The current hardly falls during the off period, so a little noise due to ringing can trigger it to turn off too early. It is not helped by using the minimum blank time. I fixed it by putting 1uF capacitors across the sense resistors.

The PFD value is best set to 100% fast decay with this motor.

It works better with a 24V supply. The full 0.4A current can be achieved (but it gets much hotter of course) and it maintains microstepping accuracy at higher step rates than it does on 12V.

## MakerBot Lin SKU4118S-62-07 NEMA17

This is the NEMA17 that MakerBot used to supply. It is at the opposite extreme compared to the one above, i.e. it is a very low voltage motor, only 2V @ 2.5A. As mentioned before, this causes a couple of issues: -
1. The inductance is so low that the ripple current is significant compared to the lowest current microstep, causing positional errors. OK at 2A, but gets worse with lower currents.
2. It is difficult to get 2.5A from the A3977 without it overheating. The PCB layout has to be very good. The datasheet recommends 2oz copper and four layers. 2A is no problem and that is the maximum with the 0.25Ω sense resistors fitted to the board.
At 2A the motor runs at about 40°C, so just about OK for use with PLA. The chip gets a lot hotter, about 77°C measured on the ground pins.

I used a value of 56K for RT and 2.1V on PFD. To some extent the optimum PFD value depends on how fast you want it to go.

## Motion Control FL42STH47-1684A-01 NEMA17

This is the recommended motor for the Mendel extruder, details here. After buying a couple of these a friend pointed out that Zapp Automation do the same motor with dual shafts for about half the price!

This is a high torque motor so it is longer and heavier than the previous two NEMA17s. Electrically it is in the sweet spot for the A3977 with a 12V supply. The A3977 can easily provide the full current and the switching frequency doesn't have wild fluctuations or drop into the audio range.

When microstepped at 1.7A it gets to about 43°C but the chip only gets to 56°C.

I used 39K for RT and 0V on PFD, i.e. 100% fast decay.

I have high hopes for this motor as a replacement for the one above that is in my extruder currently. It should give me almost twice the torque and has the correct sized shaft, i.e. 5mm. The Lin and Kysan motors both have imperial shaft sizes which caught me out as I drilled the worm gear for 5mm thinking NEMA17 specified that, but it must just be the frame dimensions.

## MakerBot Keling KL23H251-24-8B NEMA23

This is the motor I used on my Darwin. It has 8 wires so it can be connected in bipolar serial or parallel. Series has the advantage that the full torque can be achieved with 1.7A which is easily within the range of the A3977. Parallel has one quarter of the inductance so torque will fall off with speed four times slower. To get full torque 3.4A is needed but I found 1A was enough for the X and Y axes. I think Z needs more torque but my z-axis uses different motors so I don't know how much.

An RT value of 56K is fine for currents in the range 1-2A. PFD is best at 0v, i.e. 100% fast decay.

## Summary

Here is a summary of the motor specifications :-

 Motor Resistance Max Current Voltage Max Power Holding Torque Inductance LIN 4118S-62-07 0.8 Ohm 2.5 A 2.0 V 10.0 W 0.30 Nm Kysan SKU 1123029 35.0 Ohm 0.4 A 14.0 V 11.2 W 0.26 Nm 44.0 mH Motion Control FL42STH47-1684A-01 1.7 Ohm 1.7 A 2.8 V 9.5 W 0.43 Nm 2.8 mH Keling KL23H251-24-8B Series 3.6 Ohm 1.7 A 6.1 V 20.8 W 1.10 Nm 13.2 mH MakerBot Keling KL23H251-24-8B Parallel 0.9 Ohm 3.4 A 3.1 V 20.8 W 1.10 Nm 3.3 mH

Here are my suggested settings :-

 Motor Current Vref CT RT PFD Kysan SKU 1123029 0.25 – 0.3A 0.5 – 0.6V 470pF 12K 0 LIN 4118S-62-07 1 – 2A 2 – 4V 470pF 56K 2.1V Motion Control FL42STH47-1684A-01 1 – 1.7A 2 – 3.4V 470pF 39K 0 Keling KL23H251-24-8B Parallel 1 – 2A 2 – 4V 470pF 56K 0

## Friday, 4 December 2009

### Quality control

I RepRapped a doorstop for our new bathroom shower: -

It has a 10mm hole most of the way down and a countersink to take a ~5mm wood screw.

A 2mm self adhesive felt pad covers the screw hole and acts as a shock absorber.

It has a rim around the bottom to prevent it rocking if the base warps or the wall is not flat. To support the bottom of the hole there is a one layer membrane: -

I removed it with a 5mm drill: -

I was quite proud of it but my wife had something more like this in mind: -

I can't print chrome yet, so I will have to go out and buy one, and it has three screws which have to be drilled through the tiles into the wall.

The files are on Thingiverse if you prefer function over form.