Temporal Anomaly

Sumpod 3d Printer improvements

2012-05-20T12:56:19Z

My Sumpod 3d printer now has several upgrades. I've upgraded the software to Marlin (Thanks to Stohn and Erik for the firmware.) This gives noticeable improvements in print quality and allows the printer to be driven a bit quicker.

I've upgraded the hardware adding:

an SD card reader (for printing without a computer),
an rotary encoder (knob) to control the printer and navigate the SD card, and
a speaker for feedback from the rotary encoder. (I'm planning to add beeps for error events in the firmware so it is more obvious when something goes wrong or when the printer is preventing me doing something stupid - like extruding when it is too cold.)

This morning I printed these coins for my children:

They are very happy with them. I uploaded the designs to Thingiverse as thing 23369 and thing 23374 respectively.

Most of my other prints have been things for the printer itself, such as a small mount for the SD card reader and a spool holder.

Making more things on my Sumpod 3d Printer

2012-04-14T20:19:50Z

Now my Sumpod 3d printer is working, I've been taking requests for things to print. Tracy designed these with inkscape and I did the rest:

Caleb asked for a blue snake. I did my best to design one:

He loves it which is what matters but I think it needs more work - both the design and the printing. I did rather like watching it print especially the hex in-fill:

and it was good to see that the printer coped with the slight overhang created by building up and out on the lowest layers.

Bed levelling my Sumpod 3d Printer

2012-04-14T14:02:37Z

I initially used spheres of blutack to level the bed on my Sumpod 3d printer. This worked surprisingly well and was good enough to start testing but wasn't very robust.

For something more robust, I followed Stohn's method. The components I used were:

M5 Stainless Steel Countersunk Allen Screws from ebay,
M5 captive pronged tee nuts from ebay,
9.5x15.9mm springs from a set on Amazon, and
washers from a set on Amazon.

For each corner in turn, I used a screw with a large washer (to spread the force) through the platform without the bed in place to drive a captive pronged nuts into the platform and then removed the screw again.

I then put the springs and bed in place and put the screws back in (using smaller washers). I screwed it together leaving a bit of space to tighten it during levelling.

I don't know how others are doing the actually levelling, but I used replicatorg with X axis and Y axis homed then moved the Z axis until it was less than .5mm from the bed. I then attempted to slide a business card under the nozzle; and tightened the closest screw until the card wouldn't go under and then loosened it very slightly until the business card just went under. I then moved slowly towards another corner. Every 10mm (or sooner if it looked too close), I tried the business card and, if necessary, adjusted the screw (of the corner I was heading towards).

I'd welcome comments about better processes for bed levelling.

Success with Sumpod 3d Printer

2012-04-12T22:23:04Z

I've never been so pleased to see a pink alligator!

Today I did exactly what I said I'd do in the previous blog post. First, I took apart the hot end of my Sumpod 3d printer to clean it. I'm not sure if Tracy approved but found a Brulee torch (like this one) made a perfect tool for cleaning the nozzle. I used it to burn off all the PLA from an earlier leak. I kept at it until the smoke stopped. Although the smell wasn't as nice as burning sugar, then end result was almost as satisfying as a Creme Brulee. I definitely recommend this to others who've got a dirty nozzle.

Next, I put everything back together with a fresh piece of PTFE tube (from ebay). This presented a small problem as my hot end has a very slight misalignment between the PEEK/insulator and the nozzle. (This is probably why I initially failed to insert the PTFE fully and thus caused a leak.) I'd got around this last time I reassembled the hot end by shaving a very tiny amount of the tube with a pencil sharpener. This seemed to work but didn't lead to a successful print so I thought I'd try something else this time.

So, I threaded the push fitting, the MDF holder, and the PEEK onto the PTFE tube. Then I pushed the PTFE into the nozzle making sure it went in completely. I then screwed the nozzle and PEEK together - this way the PTFE is pushed in really tight. Finally (with some care to push the fitting down) I screwed the PEEK and push fitting together. This seemed to work better than any of my previous attempts where I screwed everything together first and pushed the tube in last. It seems a more reliable procedure to ensure success than the obvious/natural (?) way I'd been doing it before.

I said that I was planning to clean the filament as it entered the extruder. I did this but it was rather half-hearted effort and I don't think it made much difference.

I printed the same 20mm x 20mm x 3mm block with solid in-fill that I tried yesterday and it came out much better:

One corner is slightly less neat than the rest - the corner where the layers start:

This was quite a short print less than 30 minutes, but I was optimistic enough that I'd beaten the jamming problems that I called Richard Sum to thank him for this help and let him know I'd made good progress.

This evening I tried a more complicated (and more useful) print. This time I used the default skeinforge hexagonal in-fill and the print took a bit less than an hour. I watched very nervously as it took shape:

I was very relieved when it finished (especially as the pink filament was close to running out):

and I'm pleased with the result:

Now I have to actually think about what I'm going to use this printer for. I'm sure my lovely boys will have some ideas.

More troubleshooting of Sumpod 3d Printer

2012-04-11T22:15:09Z

Today, I spent a bit of time cleaning out the hot end of my Sumpod 3d printer. I put everything back together making sure I was really pushing home the PTFE tube. Unfortunately prints are still messed up by intermittent jamming.

I wondered if perhaps the jamming was corresponding to the natural temperature oscillations of the heating process. I did several prints at different temperatures (195'C, 200'C and 205'C) and videoed the process with the temperature reading visible on the LCD. The good news is that the best print occurred with the set point at 200'C which was the temperature I was using. The bad news is that the intermittent jamming occur-ed with all prints and the video showed that the jamming wasn't directly related to the temperature variations.

The 200'C print started very well:

but then on the third layer there is a trough where the filament jammed temporarily:

The intermittent jamming continued right up to the top layer but there were still periods of good extrusion:

While cleaning the hot end, I noticed that the Bowden tube was warped:

I need to think about what caused this.

My next steps are:

1) replacing the Bowden tube with a fresh piece,

2) cleaning the hot end again to make sure there is no old filament around the interface between the nozzle and PTFE tube, and

3) Add a bit of lint-free cloth before the extruder to clean the filament.

On a more positive note, I attempted something like Stohn's bed levelling mechanism which worked very well and was significantly easier to control than the squashed blutack I was previously using.

Initial prints on Sumpod 3d Printer

2012-03-31T08:07:00Z

My Sumpod 3d printer arrived a while ago but it has taken me this long to paint (sand, paint again, sand again, ...) the MDF. I finished most of the build last weekend. Since then, I've been attempting to calibrate it in any spare moment. After initial problems with the extruder and with the X axis belt being too loose, it does feel like I'm making progress. This print started quite well:

and the bottom layer looks pretty good:

but quality of the sides varies quite a bit:

and the top looks dreadful:

so there is definitely some calibration to do.

Making gift tags with a Silhouette Cameo cutter

2011-12-19T19:07:00Z

A month or so ago I bought Tracy a Silhouette Cameo cutter as an early Christmas present. Today she made some 'Dad' gift tags for my Christmas presents from my two lovely boys, so I thought I'd have a go at making some tags for her presents too. I think they came out quite well considering it was pretty much my first attempt at using inkscape and that we were using the robocut software rather than the official windows-only software.

While poking out snowmen eyes with a pointy stick, I remembered the excellent (but tedious to make by hand) paper graphs that Nick O'Leary wrote about a few times. The cutter would be great for making them.

The SVG files, snowmen.svg and baubles.svg, are licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

What can you tell about me just by looking at my keyboard?

2011-06-28T19:45:22Z

I recently read a blog post about people "figuring out iphone unlock codes just by looking at marks on the screen" and it made me wonder about my work laptop keyboard. It looks like this (click for high res version):

It was new when I got it but it is showing signs of age now. How old do you think it is? What can you tell about me just by looking at my keyboard? What operating system do I use on my work laptop? What IDE/editor? Anything else? Polite answers in the comments please.

Home Automation Setup: May 2011

2011-05-08T20:20:07Z

I was planning to answer a question in a comment on previous post and wanted to talk about the number of xPL clients that I have running. Rather than just quoting the number, I thought I'd make a post to put my response in context.

Most of my xPL components support the hbeat schema. So I can identify them by sending a hbeat.request message. My perl xpl-sender command can do this:

bash$ xpl-sender --schema hbeat.request --wait 10

By default, the sender just sends the specified message and exits. But, with the --wait parameter, it prepares to receive replies, sends the message and waits the specified number of seconds for any replies. The output from the above command is a summary of each received hbeat.app reply:

xpl-stat/hbeat.app: bnz-apcups.apc -> * 5/53556/192.168.32.1
xpl-stat/hbeat.app: bnz-blue.slave -> * 5/51540/192.168.32.1
xpl-stat/hbeat.app: bnz-ccost.slave -> * 5/58435/192.168.32.1
xpl-stat/hbeat.app: bnz-dmx.slave -> * 5/44072/192.168.32.1
xpl-stat/hbeat.app: bnz-gpower.slave -> * 5/59772/192.168.32.1
xpl-stat/hbeat.app: bnz-heyu.slave -> * 5/56009/192.168.32.1
xpl-stat/hbeat.app: bnz-lcdproc.slave -> * 5/41722/192.168.32.1
xpl-stat/hbeat.app: bnz-linux.slave -> * 5/46917/192.168.32.1
xpl-stat/hbeat.app: bnz-lirc.slave -> * 5/33992/192.168.32.1
xpl-stat/hbeat.app: bnz-mpd.slave -> * 5/32798/192.168.32.1
xpl-stat/hbeat.app: bnz-ownet.slave -> * 5/46631/192.168.32.1
xpl-stat/hbeat.app: bnz-rfxcomrx.slave -> * 5/40448/192.168.32.1
xpl-stat/hbeat.app: bnz-rfxcomtx.slave -> * 5/48635/192.168.32.1
xpl-stat/hbeat.app: bnz-sendsms.slave -> * 5/47592/192.168.32.1
xpl-stat/hbeat.app: bnz-smart.slave -> * 5/43472/192.168.32.1
xpl-stat/hbeat.app: bnz-udin.slave1 -> * 5/50553/192.168.32.1
xpl-stat/hbeat.app: bnz-udin.slave2 -> * 5/52187/192.168.32.1
xpl-stat/hbeat.app: bnz-wol.slave -> * 5/33981/192.168.32.1
xpl-stat/hbeat.app: bnz-zenah.slave -> * 5/39324/192.168.32.1
xpl-stat/hbeat.app: bnz-mythtv.vz -> * 5/34473/192.168.32.6
xpl-stat/hbeat.app: bnz-smart.vz -> * 5/34298/192.168.32.6
xpl-stat/hbeat.app: bnz-xosd.vz -> * 5/34487/192.168.32.6
xpl-stat/hbeat.app: bnz-xvkbd.vz -> * 5/49051/192.168.32.6

Each summary is of the form:

message_type/schema: source-identifier -> target interval/port/ip

and each source-identifier is of the form:

vendorid-deviceid.instanceid

My vendor id (developer id) is bnz, the device id is typically the type of the device being managed, and the instance id is typically the hostname of the machine running the client.

There are two machines in the list vz (which is my main mythtv box) and slave (which is the main home automation server). (The observant may notice that there is also apc but that is actually running on slave monitoring an APC UPS via USB but the instance id is changed as a convinience in order to distinguish between slave and the UPS as they both report power/battery information.) The clients on the mythtv box are:

xpl-mythtv which reports the percentage utilisation of the video inputs/tuners,
xpl-smart which reports disk temperatures so I can turn on fans to extract warm air from the server room,
xpl-xosd which responds to osd.basic schema messages showing on-screen display text using xosd, and
xpl-xvkbd which sends fake key presses to the active window (probably a security risk even though the keys always go to mythfrontend).

The clients on slave are:

xpl-apcups which reports status of my APC UPS and sends events if when the UPS switches between mains and battery and vice versa,
xpl-blue which monitors for the presence of various bluetooth devices so that my house "knows" when different people are home,
xpl-ccost which monitors my mains power usage (or at least it did until it got confusing when I started exporting power) and the solar power generated by the PV panels on my roof,
xpl-dmx which sends commands to a Milford Instruments DMX Transmitter to control a Pulsar ChromaZone 12 Controller which in turn drives a number of ChromaRange lamps,
xpl-gpower which reports my power usage information into the Google PowerMeter API,
xpl-heyu which uses the heyu X10 software control my mains appliances and lights,
xpl-jabber which enables interaction via XMPP instant messages (such as Google Talk),
xpl-lcdproc which responds to osd.basic schema messages showing text on a picoLCD-4x20-slideshow device using the [lcdproc][] protocol,
xpl-linux which reports Linux battery status and events, system temperature, etc.,
xpl-lirc which reports LIRC IR remote button presses (so that I can switch the kettle on or send wake-on-lan packets using a basic TV remote control),
xpl-mpd which controls a Music Player Daemon to play music in several zones around the house,
xpl-ownet which is an interface to an OWFS Daemon that reads from temperature/humidity sensors and writes to relay controllers on the one-wire network in my house,
xpl-rfxcomrx which is an interface to an RFXCOM RF Receiver that reports RF messages received from various sensors, switches, etc.,
xpl-rfxcomtx which sends RF messages via an RFXCOM RF Transmitter to control X10, HomeEasy, etc. devices,
xpl-sendsms which sends SMS messages via any service supported by the SMS::Send Perl API (I use the service from Connection Software),
xpl-smart which reports disk temperatures,
two instances of xpl-udin to control two UDIN USB Relay Controllers to momentarily pulse the open/close inputs of several blind and curtains,
xpl-wol which sends wake-on-lan packets (using the etherwake command) to wake up devices that are shutdown in order to save power (such as my mythtv box), and
zenah which is the brains of my house - triggering actions based on timers and incoming xPL messages.

I am also running several other clients that run in stealth mode - that is only sending messages and not listening for or responding to hbeat.request messages. These "inputs" include:

a web frontend,
an experimental daemon supporting the lightswitch API so that I can use existing Android (or iPhone) applications to control my house, and
some security-related inputs (that I wont be writing much about).

I'm currently trying to refactor the code to separate out the device-related code from the xPL code and to reduce the coupling between the web interface and the zenah "brains". This will probably involve a couple re-write of the zenah component and the web interface.

Home Automation Protocols: MQTT

2011-05-02T20:52:23Z

In my previous post, I mentioned some of the issues I was experiencing with my current choice of home automation protocol, xPL.

The primary issue was the need to perform filtering for every message on every client due to the use of broadcasts for messaging. One way to avoid this is to use a pub/sub messaging system instead. A number of people that I respect have been using the MQTT Protocol so I thought I'd take a better look at it.

I figured a good way to understand it would be to implement it. I've implemented several protocols from scratch without any documentation so implementing MQTT from a well-written specification was simple process. The basic implementation took less than a week and resulted in Net::MQTT and AnyEvent::MQTT on CPAN.

The protocol is lightweight and flexible. This is great. It works well in contexts where you are both publisher and subscriber because you can design the simplest, minimal messaging format between agents.

However, building communities that can write components that can interoperate will require some more structure. For example, using xPL, I have a client that monitors messages using the "sensor.basic" schema and creates/updates round robin database files for each sensor reading. This works for all xPL clients that support the "sensor.basic" schema regardless of developer/platform/etc. Another good example of this kind of protocol layering is XMPP and the XMPP Extension Protocols.

Essentially what is required to make this work is an ontology - a specification for topic usage and semantics. I have no idea how to produce such a suitable ontology but I plan to think about it some more. I'll probably draw ideas from various existing sources such as xPL Message Schema, xAP Message Schema, Pachube feed definitions, etc.

If anyone has any ideas (is it a good idea, how to proceed, etc?) then I'd love to hear about them.