After a period of relevant dormancy, Squirty has had a lot of work done recently. I have replaced most of the original plastic parts, which were starting to crack, and put in new bearings. I also designed a new x-carriage ducted fan adaptor that put better air flow on the printed part and put in aluminium pulleys to replace the badly worn plastic ones. I’d even made some progress rebuilding the case after its destruction in 2014. Little did I know the printing gods had a plan ready to knock poor Squirty back and severely terrify me into the bargain.

As part of the case rebuild I left a part printing overnight. In theory you are never supposed to leave a printer unattended, for reasons that will become obvious, but I do this fairly regularly because most things I print take at least 4hrs to do. It’s much more convenient (and semi-magical) to set something printing at night and pick it out of the printer fully-formed in the morning.

This time when I woke up I saw that the part had failed a few layers in. The printer nozzle was motionless over the semi-formed part, which is unusual as most of the time it will not know anything has gone wrong and will keep going, merrily spewing plastic all over the place, until it has come to what it thinks is the end of the print. There was also a strange whining coming from the power supply, and I noticed that the heated bed light was still on. This was bit of an oh-shit moment. The heated bed should not be on continuously, but should cycle on and off to keep the bed at the desired temperature. I felt bit of a chill and thanked my lucky stars that something similar had not happened to the printer hotend, which has a much more powerful and concentrated heating element. Then I looked at the printer hotend and saw this.

Oh shit
Oh shit

The aluminium block that holds the heater cartridge had got so hot that it had deformed. Under the nozzle, it had charred the plastic of the part it was printing.

Charring of the part where it was in contact with the nozzle. There is a melted portion to the right hand side of the photo. I think this is because the ducted fan was blowing in that direction.
Charring of the part where it was in contact with the nozzle. There is a melted portion to the right hand side of the photo. I think this is because the ducted fan was blowing in that direction.

By the time I found it the printer nozzle was cool, I think because the heater cartridge itself had burned out. Needless to say I feel very fortunate that this was the worst that had happened. If any of the flammable PLA parts had caught fire then it would only have been my smoke detector and fire extinguisher standing between me and a firey death.

There are some protections against this kind of thing happening built into the Marlin firmware that is running on my Melzi control board. The firmware monitors the thermistors and if they behave in an unexpected way, such as going open circuit or not showing any temperature rise despite the heater being on, then it will stop everything. This was a big improvement over the early days where if the thermistor became disconnected, or fell out of the hot end, the firmware would assume that the hot end was too cold and keep pumping in more heat.

In my case this thermal runaway protection didn’t help me because the whole board had become unresponsive. Any protection measure that’s based on firmware will not help if your control board crashes.

I have had situations where the control board became unresponsive before. In those situations I have started up the printer but not been able to connect to the Melzi board that controls it. I can’t remember exactly what I did to fix it in those situations, but I think I took out and reconnected all the wires plugged into the Melzi. My current theory on what happened is that while the whole thing was moving around one of the connectors going in to the Melzi became briefly disconnected, and that caused the firmware to crash at a moment when both the heated bed and the nozzle were on.

The heated bed itself seems undamaged. I think this is because of its large surface area – the maximum temperature it can reach is limited as at higher temperatures the heat loss from the surface matches the maximum power of the heater.

All other parts outside the hotend were also undamaged, other than the ducted fan nozzle which had some melting where it had been very close to the nozzle. I am hoping this is because of conduction from the hotend rather than from any flames coming from the part below. I take this to mean that the heat break from the hotend to the rest of the printer did a good job. The Melzi started working again once a new thermistor was attached to it, but I don’t know if this is because the thermistor caused the problem or because the thermal runaway protection was preventing it from starting while the thermistor was destroyed. The power supply also stopped making strange noises after being left unplugged for a few minutes, so I suspect it was somewhat overheated from driving the heated bed continuously. I will have to keep a careful eye on them to make sure there is no hidden damage.

I’ve got new parts to replace the hotend from, but I’ll need to make some modifications to make them fit my ancient version of the Huxley. Once it is repaired I will be running wholly supervised until I can be sure I have safeguards that will prevent something like this happening again. So far my ideas are:

  1. Build an analogue circuit attached to a second thermistor in the hotend that will cut power (via a relay) if the hotend goes above a certain temperature
  2. Put a thermal fuse in series with the hot end heater cartridge attached to the hotend
  3. Write a program that will work with the ocotopi controller to cut the power relay if it can no longer communicate with the Melzi board
  4. Put a fire suppression system like this over the printer

New York Timelapse

I’m much better at acquiring kit for projects than I am at building them, so I tend to have a lot of Raspberry Pis lying around. I’m very lucky to have access to a beautiful view of the New York skyline at the moment, so I thought one good use (partially inspired by the House of Cards opening sequence) would be to do a timelapse of the cityscape.

To do this I used the Raspberry Pi camera module. I printed this case for the camera and this one for the Pi itself. I needed the camera case to shield the lens from any light from inside the building. Once the camera was mounted in the case I stuck it to the window with some tape. I used a Raspberry Pi B+, so I didn’t need a powered USB hub to attach a wifi dongle and 4 GB memory stick.

Pi and camera module looking out of window
Pi and camera module looking out of window

For setting up the software I followed the instructions in this post from H4hacks. He explains how to set up a thumb drive to save the pictures and provided a modified version of a python program developed by Craig Thomas. The program is needed to adjust the exposure settings of the camera so that it can capture shots at night as well as during the day. One extra thing I had to do was to tell the Raspberry Pi to turn the camera module LED off, as otherwise it would spoil the night shots with a red reflection. There are instructions on disabling the LED here. I tried to make it so that I could read the memory stick on a mac as well as on the Pi, but after a while admitted defeat and formatted it as a linux file format.

Taking one picture every minute, the Pi filled up the memory stick in about a week. The video below shows the result, sped up 6000 times (I used 100 fps when doing the video encoding) and with dramatic music.

On the day I started taking the snapshots there was a big fire at a church a few blocks south (no-one hurt, fortunately). You can see the fire around 00:10.

This is what a four alarm fire looks like
This is what a four alarm fire looks like

To make the video I downloaded the stills to a mac using filezilla. They were saved in a YYYY-MM-DD-hhmmss format. I converted the filenames into a sequence of zero-padded 5 digit numbers using this command…

find . -name '*.jpg' | sort -n | awk 'BEGIN{ a=0 }{ printf "mv \"%s\" %05d.jpg\n", $0,a++}' | bash

…and then encoded them with ffmpeg like this…

ffmpeg -framerate 100 -i %05d.jpg -c:v libx264 week.mp4

One problem I had was that two of the daylight periods were entirely made up of green images like the one below, I deleted these from the sequence used to make the video.

It's just green
It’s just green

I’m not sure what happened here. At first I thought it might be that the connection to the camera had come loose, but it seemed to transition to the series of green images at sunrise and then go back to normal images at sunset. My current theory is that the exposure settings were too high for two particularly bright days, although I don’t see why that would have created a green image.

I’d quite like to do this over a year to see if I can get some of the seasonal changes, but it might be too static to be interesting. It would also be nice to do another timelapse at night on a clearer night and see if I can get some star movement.

Screen Shot 2016-02-28 at 10.07.26 PM

Measuring a 3D Printer Bed’s Flatness

Once I got my printer’s z-probe and autoleveling set up I was struck with a sudden paranoia that my printer bed was saddled. The standard autoleveling in Marlin can deal with a printer bed that is not level, but it cannot fully correct for a bed that is not entirely planar*, e.g. one that is bowed or saddled. To try and set my paranoia to rest I decided to test whether my bed was truly flat.
Continue reading

Alternating stripes of tape - one "sticky side up" piece of tape is held by two adjacent "sticky side down" pieces

Stripey kapton tape for glass beds

Some time ago I put a borosilicate glass bed on Squirty. I really like it because PLA will stick firmly to it when it is hot, but will pop off easily once it cools down. It is also really easy to clean. The only issue I had was how to attach it to the aluminium print bed surface. I know a lot of people use binder clips, but they have the disadvantage of slightly reducing the print area and also jut out above the print surface, risking collisions with the nozzle. Up until now my approach was to use kapton tape along the sides of the bed. It wasn’t a great solution because the glass still could slide back and forth slightly relative to the aluminium bed and it also tended to peel off over time. Today it occured to me that what I needed was double sided kapton tape. Such a thing does exist, but rather than ordering it I decided to cheat by alternating stripes of kapton tape with one “sticky side up” piece of tape stuck down by two “sticky side down” pieces. This arrangement holds the glass in place really firmly and yet I think I could still remove the bed without causing any damage.

This is a really simple idea that probably should have occurred to me years ago, but I am unreasonably pleased with it!

The bad old days. Tape around the side of the bed ineffectively holding the glass in place
The bad old days. Tape around the side of the bed ineffectively holding the glass in place

Alternating stripes of tape - one "sticky side up" piece of tape is held by two adjacent "sticky side down" pieces
Alternating stripes of tape – one “sticky side up” piece of tape is held by two adjacent “sticky side down” pieces

The solution to the collision problem - spacers that hold the Melzi board further away from the frame

Melzi holder and new wiring

In the last couple of posts I described how I put a z-probe onto Squirty the RepRap. Adding the z-probe meant new wires. These wires ended up jumbled all over the place and occasionally got caught on the z-axis threaded rods, causing all manner of chaos to break out. The z-probe also requires a lot of clearance, which means that the printer carriage spends more time up at the top of the build area than it used to. Once up there, it has a nasty habit of bumping into the Melzi control board. To try and tidy things up, I collected all the wiring for the z-probe and ducted fan components together and designed a new set of Melzi holding clips.

Continue reading

Wiring for the servo and microswitch

Z-probe V2: Autoleveling

Following on from the previous post I redesigned the z-probe holder to position the microswitch closer to the nozzle. I also forked the latest version of the Marlin firmware to correct some problems I was having with the leveling behaviour. The video below shows that the autoleveling seems to be working, but I need to do some checks to understand how successfully it is correcting for any tilt in the bed. I also need to make further design changes to the z-probe itself. This post includes more details on how I designed and set up V2.

Continue reading

V1 Z-Probe: the probe is far away from the nozzle

Z-probe V1: The Gom Jabbar

By far the most frustrating part of 3D printing with Squirty the RepRap has always been the strange dance you have to do to get the Z distance correct. I use a strip of paper and carefully pull it back and forth underneath the nozzle while trying to bring it close enough to the bed so that the paper just starts to rub against the nozzle. At that point you can use a command to tell the printer what the offset between the Z endstop and the bed is. It is a massive pain, and this assumes that the bed is level, which it rarely is. To level the bed you need to repeat something like this at multiple points while making fiddly adjustments to the three supporting bolts.
Continue reading

Shell of a star shaped prism

Creating Shells with OpenSCAD

Antony Monjauze had a question about whether OpenSCAD could be used to create a shell from an imported stl. At first I thought this wouldn’t be possible. It seems like to create a shell you would need to know something about the geometry of the stl you were importing, and OpenSCAD can’t tell you anything about what the dimensions of an imported stl are. However Henning Meyer’s comment on this thread explains how it can be done.
Continue reading