If you’re a knitting addict, like Elisabeth, then you might find yourself having to deal with yarn in big bundles called hanks. You might come across hanks if you’re making your own yarn, and some yarn vendors only sell it in this form. The hank isn’t a particularly good format for knitting from, as the wool will tangle quite quickly. You want your yarn to be in a ball.
You can wind yarn balls by hand, but you’ll quickly get very bored of this. So, you’ll want a ball-winder. You can buy these, but you can of course make your own (you can even 3D print one). Elisabeth had one she’d made that could be driven by a belt connected to a spinning wheel. Unfortunately, it was a bit rickety, which I believe meant that it could only actually be rotated by hand else the belt would fall of. I harvested the bearing from an IKEA lazy susan and reduced the ricketyness of the ball winder such that it was more suited to higher speed operation. We also motorised it. As luck would have it, I’d already got a motor with a pulley and compatible belt from my recent temperature-controlled oven project.
Now that we’d got a high-speed ball-winder, some new issues appeared. It now took three people to perform a ball-winding operation. One person would hold and untangle the hank, one would manage the tension and position of the yarn as it entered the winder, and the other would observe the other two and manage the speed of the winder appropriately. The solution to this problem in knitting-land is to use a structure called a swift. A swift holds a hank of yarn such that it can be easily unwound. It’s essentially a variable-diameter wheel around which the hank is wrapped. When its loaded with a hank, one just needs to pull the end of the yarn, and the swift will rotate allowing the yarn to be unwound. This avoids all the tangling of attempting to do it by hand because the hank maintains its shape until it is completely unwound.
So, we decided to build a swift. More specifically, we decided to laser-cut a swift. Johannes and I came up with a conceptual design for the swift relatively quickly. Johannes did the CAD (he seems to enjoy the QCAD interface more than I do). We’ve uploaded the design for our swift to thingiverse so others may make it should they wish.
Here’re the swift and baller in operation:
My friend Elisabeth was recently responsible for baking a layer of a wedding cake. Wedding cakes are not like normal cakes. They tend to be quite large and regarded as quite important. So Elisabeth did a couple of practice runs of baking this cake, which was good for the occupants of this house as there was much yummy cake to go round. During these practice sessions it became apparent that the temperature control of our kitchen’s cheap gas oven was not suited to mission-critical situations. Using hot water causes our on-demand boiler to come on, which lowers the gas pressure reaching the oven, resulting in it cooling down. I had a shower during the second attempt, which resulted in the pressure going so low that the oven turned itself completely off. It turns out that, like electronic components, cakes also have temperature profiles that should be stuck to when processing them!
Ideally the oven would control the amount of gas being burnt based on the difference between the temperature within the oven and the desired temperature. However, cheap ovens are cheap. They work on the assumption that the gas supply has a constant pressure, and the room temperature is constant over all time. Furthermore, again because they’re cheap, these ovens do nothing in response to differing thermal masses. It seems that our cheap oven’s “temperature” knob just adjusts the target pressure of a gas pressure regulator. The relationship between the position of the temperature knob and the gas pressure is extremely non-linear, and bears much resemblance to its close relative, the all-too-familiar and highly-sensitive shower temperature control.
I decided that was was needed was a better temperature controller for the oven. This was quite clearly a situation demanding the fusion of some amusing mechanical hacking and electronics. Pulling the knob off the oven revealed a brass rod with two flats on its sides. I decided that the easiest way for me to motorise this was to mount a pulley on it. With Jeff having recently moved to London, I’d been left particularly latheless and so scoured the internets for suitable pulleys. The online shopping experience for mechanical parts isn’t anything like the world of online shopping for electronic parts. It is a world pretty much completely devoid of parametric search, and is full of websites that feel like they’re still being served from the same BBC Micro they were designed on… (That’s not to say that online electronic component shopping is a gold standard however — it’s got an awful long way to go, and unfortunately competition is not fierce within it.) Also, one gets the disconcerting sense that there are still a lot of fax machines involved in the mechanical parts world. After pushing myself through the HPC Gears website, which is still very much adheres to ye olde “the paper catalogue is the one true way” line of thinking (sigh), I found the pulley I was looking for. I was pleasantly surprised to find that I could order a single pulley, rather than 9000.
So, it was Sunday evening. The cake needed to be baked on Wednesday. Everything I ordered at this point would arrive on Tuesday (because ubiquitous 24/7 UAV-based shipping networks still belong to the future…). So I spent a couple of hours making sure I’d either got or ordered all the bits I needed. This is the final list of things that I ended up using:
- Pololu Simple Motor Controller 18v7 — A USB-controlled motor controller.
- A 12-24V MFA/Como Drills 918D series motor with what I believe to be a 60:1 gearbox (I have quite a few of this range of motors hanging around — they’re quite a popular choice for Student Robotics activities — so establishing exactly which gearbox the one I used isn’t straightforward…)
- A pulley for the motor’s shaft from Technobots.
- A K-type thermocouple from Farnell
- A MAX6675 (from Farnell): A chip that bakes all the interface and calibration circuitry one could want for interacting with a K-type thermocouple into a single 8-pin SOIC chip. It’s pretty awesome: thermocouple in, SPI out.
- A FT232RL FTDI adapter to interact with the MAX6675.
Luckily, the postal service functioned well, and everything did indeed arrive by Tuesday. So on Tuesday evening, Johannes and I hacked the mechanical situation together:
Next came the electronic and software side of things. This was reasonably straightforward. The MAX6675 has a simple SPI interface, which we talked to using the FTDI adapter. Hacking this together at high-speed, I decided to just use the bit-bang mode of the adapter. This is the most conceptually simple mode, as one just sets, clears, and reads pins on the adapter. I could have got the FTDI module to perform all the clocking of the MAX6675 itself, but this additional complexity really wasn’t worth it for an unneeded efficiency/speed improvement.
Interfacing with the motor controller didn’t take too long. The documentation about the Pololu motor controller seems unnecessarily convoluted to me. All I wanted was a table of the different commands that I could send to it over its USB connection. Pololu give a long manual for the board, in which the different commands are spread out, and interlaced with screenshots of various graphical programs that I had no interest in using.
Initially, I had plans to add a AS5030 magnetic rotary to provide feedback on the position of the temperature knob. It turned out the end-stops of the oven’s knob were sufficient for us to drive into them a bit. So we could easily get to “min” and “max” without feedback. It was about three in the morning by the time we’d got the mechanical, motor control, and thermocouple situation configured. Pressure to ship combined with sleepy haze lead to us abandoning the AS5030 plan, which was OK because we could just oscillate between min and max to control the temperature. This is known as bang-bang control. Our testing convinced us that we could get the oven to stay within something like ±5°C, which was definitely accurate enough for what we wanted.
Whilst Elisabeth was busy mixing the cake, the control loop was set to heat the oven to 160°C and keep it there. The mixture was put in the oven, and the system was left to run for two and half hours. By “left” I mean that Johannes had a constant eye on it throughout the baking procedure — this was an important cake! All was well, and the cake baked successfully:
Bring On The Graphs!
Of course, whilst the cake was baking, we logged all the available data to disk (you can download it too… for some reason… find it at the bottom of this post). Below is a plot of the temperature of the oven read through the thermocouple throughout the whole process. The black line is the temperature, and the red shaded areas show where the knob was set to “max”. The knob was set to “min” in the white areas.
So you should be able to see from the above graph that the cake stayed around the temperature it should have throughout the whole process. There are a couple of more interesting events in there. If we zoom into the left-hand end of that graph (at the beginning of the baking experience), we can see what happened when the oven door was opened to put the cake in. Here you can see how quickly an oven will cool down when it is opened.
The other interesting bit is when the cake was removed from the oven. The control and logging stuff was turned off for a short period after the removal, so there’s a bit of a gap in the data as well:
So, now for some analysis of the above data. Here’s a histogram of the temperatures sampled during the periods of time when the oven door wasn’t open and the cake was installed:
Some stats from that:
- Minimum: 156.75°C
- Maximum: 168.25°C
- Mean: 160.54°C
- Standard deviation: 2.09°C
So, a range of 11.5°C. Not bad for a night’s hacking. Elisabeth decorated the layer of cake, and transported it to the wedding, where it was combined with two other layers of cake baked by different people. News on the grapevine is that Elisabeth will be posting some photos on her blog any day now ;-)
There are two repositories of source related to this project:
- therm.git: C utility for interacting with the MAX6675 through an FT232RL.
- control.git: Python script to perform the bang-bang control, by interacting with both the above therm utility and the Pololu motor controller.
And the data is available in this CSV file. The columns are as follows: time (seconds), temperature (°C), and whether the knob was on max or not. Enjoy.
Site by Rob Gilton. © 2008 - 2019