Saturday, February 4th, 2012 at 4:56 am - Whipping
In about 2 seconds — zip! — a 3 day long train ticket from New York to Los Angeles was purchased for $208. I went with Aidan to a noisy sports bar in Penn Station where his brother was having a beer with a golfing buddy. “Wot de fok’s wrong wid’ you?” he said.
On this train I am going to get some work done. I hope it doesn’t have WiFi.
![]() |
![]() |
Meanwhile, back at the hackathon, I spent the day doing PDF parsing. I got lucky. There were 120 documents all identically formatted with lots of numbers in them.
There’s another day of this tomorrow, so off to bed.
Wednesday, February 1st, 2012 at 6:18 pm - Machining, Weekends
I got out on Saturday before my nasty travel-induced cold really took hold and laid me low. I was not surprised to find that most of the Underwater Rugby players round here are Columbian. One of them gave me a lift up to East Haven, Connecticut, which was a 3 hour drive north and then east. In spite of the huge population and development around New York, there are very few pools that they can play the game in. This pool was on a back street behind a school. It was a turn-out-the-lights-when-you-leave affair. The team coach was funny. Before the game he was like “It doesn’t matter how many points the other side scores, as long as you’re learning to play.” After the other team began to score, then the real strong critical coaching began. If it’s just you up against the goalee there is no excuse not to score. There’s a technique to levering them off the basket which inevitably caused me to bang my head against the pool wall. Quality entertainment. More like this please.
|
|
Have been working night and day (when not trying to rest) finishing off various webscraping duties. Must get moving on. A three day transcontinental train ride beckons. I have it in my tiny mind to move on to SolidWorksWorld. Why, I don’t know. Plans can always change.
Thursday, January 26th, 2012 at 3:03 pm - Machining, Whipping
It appears that I am in New Jersey for the purpose of assisting somewhat with USA based scraperwiki business.

As I limit my air travel to the bare minimum (for reasons that would be obvious if we were a species that took any notice of threats to its survival), I am staying here for 3 months (till 24 April) using only surface means of transport.
I’d like to meet anyone on my travels in relation to scraping business.
But, more interestingly, I’d also like to meet anyone in relation to CADCAM machine tool work. A lot more of that happens here than at home, I understand. Please get in touch.
Travel plans are NY till 6 Feb. Then I must be in St Louis Missouri on 24 February. No plans have been made to fill the time in between or what exactly happens afterwards.
Tuesday, January 17th, 2012 at 4:04 pm - Cave
After a very wet New Year at Bull Pot Farm, there was a few days down in London at the EPS finding various things to do. In between I did a lot of coding on Scraperwiki’s dataproxy, converting it to twister.
This weekend was a final trip to Leck Fell doing the usual stuff before I get trucked off for three months to the US of A.
Saturday was a trip down Death’s Head Hole, which had recently been connected into the lower part of Lost John’s Cave main drain below the lake ducks. Surveying.

One slight error was I had packed one of Becka’s wellies instead of my own, so I had a bit of trouble fitting my right foot into it.
Friday, December 30th, 2011 at 2:34 pm - Cave
Over three day-long digging sessions in Ogof Dydd Byraf in November and December 2011 I failed to film anyone filling the rubble sacks with sand.
I did make tea and sandwiches (when they weren’t ruined by James spilling them all over the mud).
Friday, December 30th, 2011 at 2:27 pm - Machining 2 Comments »
The big idea is to use this 3D printer makerbot as a 2D plotter (by the application of a rubber band and a felt tip pen) to draw a representation of someone’s face on a post-it note.
We have the printer driver technology, we have a camera. All that is in between is software. So it should be easy, right?

Computer vision is a field that has been worked over for decades. Unfortunately it hasn’t resulted in a straightforward bitmap to vector drawing function I can call from Python. What I do have, however, are a lot of specialized CAM algorithms that I can apply to the problem. Specifically, the Pencil Milling algorithm. (That’s the one where you run a blunt object along all the surface to surface corners as if in the gutter of a kerb.)
First off, we use the FIND_EDGES filter which converts a bitmap into another bitmap with the sudden changes in brightness highlighted.
(The code which follows is as much for my reference — once I forget exactly how I did this — as much as it could be for anyone else’s benefit.)
Tuesday, December 20th, 2011 at 12:31 pm - Machining 3 Comments »
Over in DOeS Liverpool, where I have been banished, there is this cobbled together Makerbot Industries Cupcake CNC.
The only software that runs it is ReplicatorG, a big Java GUI system behemoth (rather like Tunnel), which is great if all you want to do is go from STL files to 3D volume-filled plastic builds.
If you want to do something interesting, like make shapes without the use of a crappy STL file or adjust the geometry in response to build feedback mechanisms (the way CADCAM has got to go, but can’t so long as machine tools continue to operate as non-interactive batch processors), then you need to get behind this prescriptive interface.
This we have done, after an enormous amount of dead time. The secret was getting the baud-rate right. (There is this USB to serial port wire too.)
The code in ReplicatorG is very difficult to scavenge, containing as it does 3 copies of Skeinforge, like so much junk DNA. It’s made to work, not for repurposing.
The way through was the document of the protocol here and the source code for the firmware here.
I finally was able to write a program to operate the way I want — without a batch process. [the single file code for everything below is here]:
def gospiral():
go(0, 0, 0)
for th in range(0, 500, 2):
rth = math.radians(th*1.8)
c, s = math.cos(rth), math.sin(rth)
res = go(th*c, th*s, 0)
go(0, 0, 0)
The go() function transmits the position vector to the machine and pauses if the buffer is getting full. (Buffer is 512 on this device.) It took ages for us to identify the code using the ReplicatorG debug mode and the documents — as though it wasn’t the most important function in the whole darn set-up.
def go(x, y, z, cycletime=5000):
while getbuffsize() < 300:
time.sleep(0.5)
return runcommand("\x81"+struct.pack("<iiii", x, y, z, cycletime))
To communicate with the device you need to install pyserial, which gets everything done.
We connect to it as easily as this:
import serial ser = serial.Serial(11, 38400, timeout=1)
The command form is byte “\xd5″ followed by the number of bytes in the payload of the command, then the payload bytes themselves, and finally the cyclic redundancy check byte calculation.
def runcommand(payload):
ser.write("\xd5"+chr(len(payload))+payload+crc(payload))
first = ser.read()
if first == '':
raise Exception("No response")
if first != '\xd5':
raise Exception("Bad leading byte")
length = ord(ser.read())
rec = "".join(ser.read() for i in range(length))
rcrc = ser.read()
if rcrc != crc(rec):
raise Exception("Return crc mismatch")
return rec
Don’t forget that cyclic redundancy check byte:
def crc(payload):
b = 0
for c in payload:
b = (b ^ ord(c)) & 0xff
for i in range(8):
if b & 0x01:
b = ((b >> 1) ^ 0x8c)
else:
b = b >> 1
return chr(b)
And finally here are some random other functions to help work it out:
# prints 'Cupcake'
def getversion():
return runcommand("\x14\x1c\x00")
def getpos():
res = runcommand("\x04")
return struct.unpack("<iiis", res[1:])
# setpos(0,0,0) would set current point to home
def setpos(x, y, z):
return runcommand("\x82"+struct.pack("<iii", x, y, z))
def abort():
return runcommand("\x07")
def getbuffsize():
res = runcommand("\x02")
return struct.unpack("<i", res[1:])[0]
What to do now?
Well, printing plastic is quite complicated and I know I’d run out of enthusiasm short of what can be done using ReplicatorG. So I thought about drawing something.
If we can replace the plastic extruder with a felt tip pen, and the build platform with a post-it note, then all I need is for a way to convert a photo into a sequence of lines which can be drawn.
The Python Image Library has an edge detection algorithm:
import PIL.ImageFilter
import PIL.ImageOps
i = Image.open("PB250118.JPG")
j = i.filter(PIL.ImageFilter.FIND_EDGES)
j = PIL.ImageOps.invert(j)
j = PIL.ImageOps.grayscale(j)
#j.save("test0.bmp");
j.show()
How do I convert this into a sequence of paths? I was wondering about turning the above into a simple 3D triangulated relief surface and running the pencil milling algorithm against it.
If the pencil milling algorithm can be called from Python (or is implemented in Python), then we can have a full end-to-end process from photograph to drawing the picture in a single readable file, which means the process is hackable and can be experimentally adapted to other purposes, such as etching, artistically plotting with different colours, or cutting chocolate.
Personalize your mobile phone by scratching your picture on it. First it needs to touch-probe the shape of the surface, and then wrap the image onto it in 3D.
Tuesday, November 29th, 2011 at 1:17 pm - Whipping
Because the political process in the UK is funded by donations, people must learn to donate money to political campaigns the believe in, or they get what’s coming — a political process entirely owned by moneyed interests who find they can buy it out for chump change.
So I donated £50 to the Yes to AV referendum campaign at the beginning of the year (largely selected and funded by the Joseph Roundtree Foundation), only to find that they were the most useless bunch of wankers one could ever be stuck with. It was so bad it seriously looked like sabotage. Meanwhile, the No Campaign could pump out more and more lies to its heart’s content, knowing there was no opposition.
Trying to get any idea what the Yes “Campaign” was on about was like talking to a brick wall. There were rumours of their awesome decisions, like not taking any advantage of the free leaflet mailshot and blowing their whole roll on a telephone cold calling system, but today, with the financial disclosures, we have the first peak into what went on.
Friday, November 18th, 2011 at 6:12 pm - Machining 2 Comments »
While trying to kick-start my engagement with some CAM algorithms I am supposed to be doing stuff about, I decided to try some of these new-fangled unit test concepts people have been going on about.
(Normally I object to unit test people quite a lot because they come with the attitude that if the code is not completely pre-infested with unit tests from start to finish throughout the development process, then it cannot possibly be any good, and by implication the programmers who wrote it are stupid, ignorant and ugly. Nevertheless we can salvage something from the ideas, if we can be bothered.)
Much of my CAM algorithms are self-tested with the use of assertions, rather than unit tested. Partly because it’s easier, and partly because the example failure cases are so big it’s never the cases which you think about that are the problems. Usually I have a slow, simple algorithm running against a fast highly optimized algorithm and I make sure (in debug mode) that the two answers are the same.
Generally, running big CAM algorithms in an isolated test harness is tedious and tricky, so you normally compile it into the final product and test it there. However, lately I’ve decided that maybe I ought to be trying a bit harder to take it out of that environment. Especially as we do have our C++ algorithms driven through SWIG into Python, so there is no excuse whatsoever for not trying it out.
Almost none of it is documented properly. So here is an idea of the code needed to plot a series of slices of a torus against a line.
First build the “surface” object, add one line into it (in the form of a triangle with two points the same), and “close” the object with the Build function (I’ll explain this some other day).
import hsmkernel as kernel fssurf = kernel.FsSurf.New() fssurf.PushTriangle(0,0,0, 0,0,0, 0.4,0.1,1) fssurf.Build(1.0)
Now make a horizontal tool surface, which is an object that defines a tool shape in a particular Z-plane and references a surface
fshoriztoolsurf = kernel.FsHorizontalToolSurface.New() fshoriztoolsurf.AddSurf(fssurf) fshoriztoolsurf.AddTipShape(0.4, 0.3, 0.5) # (corner_radius, flat_radius, z)
Now make an implicit area, which is an object that defines a subset of the 2D plane and a set of tolerances to which the boundary contour of that subset will be computed. Such an object can reference more than one horizontal tool surface, making it possible to handle compound tools, such as you get when you have a protection surfaces or large tool holders that should limit the 2D area.
fsimplicitarea = kernel.FsImplicitArea.New(0)
fsimplicitarea.AddHorizToolSurf(fshoriztoolsurf)
fsimplicitarea.SetContourConditions(0.99, -1.0, 0.002, 2, -1.0, 0.9)
# (minCNdotContour, maxZdiffContour, deltaHdiffContour, maxHdiffContour, maxCPcuspContour, minBNdotContour)
Those contour conditions (boundary tolerance values) don’t really belong here, but they have to get into the algorithm somewhere, and it doesn’t matter where. (At least that’s what I tell myself to overcome the sense that I have made a design mistake here.) These values are things like maximum segment length (maxHdiffContour), minimum segment length (deltaHdiffContour), maximum change in angle between two segments (cosine of value is minCNdotContour), and so on.
Now we build the structure which will model the subset of the 2D plane:
fsweave = kernel.FsWeave.New() fsweave.SetShape(-5, 5, -5, 5, 0.17) # (xlo, xhi, ylo, yhi, approx_resolution)
Now, the contour created by the interference set of a near vertical line and a small torus (total diameter 1.4) moving in a horizontal plane is going to be something approximating a circle.

The numbers add up, because you can see it’s approximately 8.5 major cells across (about 0.17mm wide each) and it fits with the total diameter of the torus.
You can also see some subdividing of the contour to maintain an angle change between subsequent segments of less than acos(0.99), or approximately 8 degrees.
If I was a bit more rigourous with my inputs, I could be comparing this contour with the near ellipse shape I would expect the answer to be in order to unit test my torus-line slicing algorithm.
In the image below I have created 50 slices at various z-heights and plotted the normals in green so you can see the blob shape defining a sort of 3D volume made from all the slices together.

I’m wondering whether the DLL and python bindings which allow the above algorithms to be scripted would be a more worthwhile thing for people to use than our slice.exe application. This would require people to know Python, though. Unfortunately, most Python programmers are doing web things and not doing CADCAM.
Monday, November 14th, 2011 at 11:49 am - Whipping
My attention has been drawn to a 22 March 2010 Parliamentary publication, London Regional Committee – London’s population and the 2011 Census
From Chapter 3, Preparations for the 2011 Census in London:
The National Address Register
87. We are encouraged by the development of a national address register for the 2011 Census. Such a register is vital for a successful Census in London.
91. We understand that the address register will not be maintained in its present form after 2011, despite the substantial time and effort which has gone into establishing and updating it. Shaun Flanagan of the Cabinet Office told us that when ONS negotiated the contract with the Royal Mail, Ordnance Survey and the Local Government Information House to provide data for the register, a condition of the agreement was that the register would not be re-used, but that any improvements to the data would be fed back to the three providers.
92. The Chair of the UK Statistics Authority has already written to Ministers to make the case for the national register to be maintained beyond 2011. The Minister for London told us that negotiations on the future use of the register were ongoing: “there is no dispute about the importance and benefits of resolving this.” That view was echoed by Keith Dugmore of the Demographics User Group, who described it as a “golden opportunity to produce a definitive national address register and to keep it going”. We were nevertheless disheartened to receive no clear answer from the Government on the issue of lead responsibility for negotiating an agreement.
93. An accurate and well-maintained national address register is an invaluable tool for the 2011 Census, and will be vital for any future exercises to quantify London’s population. We find it barely credible that the address register developed for the 2011 Census at substantial effort and expense is to be abandoned following the Census for reasons connected to the ownership of the intellectual property.
94. We concur with the UK Statistics Authority in recommending that the address register prepared for the 2011 Census be maintained as a public resource. We recommend that the Government urgently seek to resolve any outstanding issues with the maintenance of the register after April 2011, and to provide sufficient resources for its continued maintenance and development.

