Freesteel

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.

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.

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.)

(more…)

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.

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.

In January 2006 the ownership of Edgecam and its 3-axis kernel passed to Planit with its acquisition of Pathtrace Limited (02485210). (Pathtrace is now a “dormant company”, according to its listings at Companies House [the accounts]).

Here is its extraordinary chain of ownership, worthy of Enron or Tony Blair, pieced together from around 20 documents purchased from Companies House.

Planit Software Limited (02093062)

Directors: Bryan Pryce and Jonathan Lee, Employees: 130

Planit Holdings Limited (01731539)

Directors: Jonathan Lee and Bryan Pryce, Employees: 30

Velocity Acquisitions Limited (05943914)

Directors: Ian Grant, Richard Green, Richard Moon, Jonathan Lee and Bryan Pryce

Velocity Investco Limited (05943898)

Directors: Ian Grant, Richard Green, Richard Moon, Jonathan Lee and Bryan Pryce

Velocity Holdings Limited (05943865)

Directors: Ian Grant, Richard Green, Richard Moon, Jonathan Lee and Bryan Pryce

It also says that August Equity Partners 1 GP Limited holds 1,825,000 ‘A’ Ordinary shares which leaves 400,000 shares unaccounted for after subtracting the 250,000 directly held by 3 of the directors — until correct this by doing the calculations in the Annual Return

August Equity Partners 1 GP Limited (04141155)

Directors: T J Clarke and R J Green

But there’s more:

That is to say this company is simultaneously a member of the following two partnerships:

August Equity Partners 1 (LP007896)

Type: Limited Partnership, Previous name: August Equity Partners IV
No other membership information disclosed

August Equity Co-Investment Fund 1 (LP012301)

Type: Limited Partnership, Registered: July 2007
No other membership information disclosed

August Equity LLP (OC313101)

Members: R J Green, T J Clarke, I D Grant, P M Rattle, A Hassan, August Equity Management Limited

One of those partners isn’t a human being…

Directors: T J Clarke and August Equity LLP

So, August Equity Management Limited is owned by, is directed by and is a partner in August Equity LLP.

Is this normal?

No wonder these financial management types don’t have any time to get to know anything about the stuff which they actually own!

As it says:

Vero Software and Planit Holdings Merge, form Third-Largest CADCAM Vendor

The Planit Group offers its software products globally under the Edgecam, Alphacam, Cabinet Vision, CabnetWare, Javelin and Radan brands.

Vero focuses on plastic injection moulds, sheet metal stamping dies, multi-axis milling, laser cutting and wire EDM, offering its software products globally under the VISI, PEPS, Machining Strategist and SMIRT brands.

The combination of Vero and Planit creates the third largest CADCAM vendor — only behind Dassault Systèmes and Siemens PLM, according to the companies. The merger of the two organisations will provide the platform to build stronger products through significantly enhanced development capabilities and further extend a growing influence on the global market, according to the company.

The merger has been funded by Battery Ventures (Boston, USA) who have been investing for more than 25 years in technology-driven companies and work hard with management to build their presence into global market leaders.

Never mind the branding, what will become of the software? I believe that Edgecam still has its own home-grown 3-axis kernal, as does Vero (from the NCGraphics Machining Strategist kernel).

Will one of them be discontinued and replaced by the other, or will there be an effort to merge the code (impossible) or at least salvage something by linking one on to the other as a library?

Like everyone else, Edgecam buys its 5-axis kernel from moduleworks, so no change there.

All that’s left is the user interface and other gubbins (eg post-processors). Very difficult to discontinue them and force users onto the other one.

It’s expensive and pointless (except in the very long term) to merge software products that have never been together. The expense was lost in duplicating the effort in the first place.

So, although what you can do with the software is all that should matter, this is going to be ruled by the finance guys, who work to a completely different model where one programmer is interchangeable with another.

Hopefully lots of financial statements will be disclosed in the process which may illustrate the curious extent of disconnect between the software development and the management that is usually present in these sort of businesses.

Planit Holdings Company No. 01731539
Previous Names:
Date of change Previous Name
01/12/2006 PLANIT HOLDINGS PLC
08/03/1989 MEMCOM INTERNATIONAL HOLDINGS PLC
04/03/1991 TELFORD GROUP PLC
30/10/1998 BRITISH THORNTON HOLDINGS PLC

I appeared to have made a fundamental error in mistaking a document published in March 2009 by Capital for Enterprise Limited entitled “guidance for Enterprise Capital Funds” as having anything to do with the Capital for Enterprise Fund (which bailed out Vero Software in December 2009).

Oh well.

Nevertheless, following my FOI request about the information they received, they supplied me with what appears to be a close approximation of an Investee Summary Sheet for that particular transaction, and disclosed that there were 38 of them in total.

These funds tend to keep their operations as secret as possible, and provided the following explanation for this confidentiality in my last Decision Notice

33. BIS has also provided the Commissioner with evidence of similar prejudice occurring in a comparable situation. BIS explained that a named Capital for Enterprise Fund portfolio company, suffered adverse publicity as a result of voluntary disclosure of information that related to the company by a Fund Manager. This is another fund similar to the ECF programme which receives some investment from the government. It explained that the disclosure resulted in damage to the fund and the investee company. In the aftermath of the press coverage, it stated that there was significant disruption to the business and diversion of management resources to reassure customers and other stakeholders as to the businesses viability. In addition following press scrutiny surrounding this investment there was a noticeable aversion by investee companies for it to be a matter of public record that they had received funding from the Capital for Enterprise Fund as they wanted to avoid similar scrutiny of their business and because there was clear reputational risk of undergoing such scrutiny. The Commissioner considers that whilst this relates to a different funding programme and different information was disclosed, this example provides some evidence as to the nature of the prejudice claimed occuring in this case. This is because the SMEs which apply for ECF investment are private companies which may not wish to come under public scrutiny and therefore may be detracted from applying for such funding programmes.

And what was the “named Capital for Enterprise Fund portfolio company” I had to ask? It was KeTech.

Creditors to Mandelson-backed KeTech face losses
A private company that received £2.75m from a Government-funded scheme set up by Lord Mandelson less than a year ago is to file for protection from its creditors.

Mandelson faces embarrassment over KeTech’s pension black hole
The Government’s investment arm has begun investigating how a taxpayer-funded scheme rescued a company without noticing that one of its subsidiaries had failed to pass on thousands of pounds of its employees’ pension contributions.

Oh, so the Capital for Enterprise Fund managers or related government operatives apparently failed in their diligence, which was only found out when the company entered into a sort of bankruptcy process in which creditors lost money.

…And that is your cited example to justify zero disclosure about these venture capital funds?

Come on.

I mean, the press scrutiny was primarily about the shortcomings in the official scrutiny by the financial professionals hired to oversee this case.

And that press scrutiny is then described to the Information Commissioner as a case of unwelcome outside disruption and reputational risk — which he accepted as reasonable!

Only in the financial sector can an administrative failure get converted into an intangible asset with such ease.

Why do these cock-ups keep morphing into successful conspiracies?

Trying to do some machining work here. I’ve got the task of making the 5-axis holder collision check work a bit faster. But first check the review of the 3-axis holder case.

Consider the following diagram. The background yellowish volume is the model, the blue is the toolholder that can collide with the model when it is lowered along its z axis, and the barchart thing represents the box-set containing the model.

The box-set is the structure that puts all the triangles, points and edges of the model into rectangular boxes so as to reduce the number of elements that need to be scanned.

For example, if the model contains a million triangles spread across a metre squared, then it’s going to take a long time to scan all of them for each tool holder location to test for collisions. However, if the triangles are listed in boxes, then (according to this diagram) we need only to scan the triangles that appear in the 12 boxes between A and B, which is a fraction of the total.

Also, each box has the triangles listed in order of max z (within the box). Since we know the minimum z of the toolholder where it overhangs each box, we need only scan down the triangles in each box until we reach the first triangle whose maximum z is below this minimum.

Even so, with a big toolholder shape covering a broad area, there can be numerous boxes to scan, many of whose top triangle is well below the min z of the holder over that box.

So there is scope for optimization.

For any toolholder xy axis position, there is a height difference between the maximum z of the triangles in each box, and the minimum z of the tool holder over that box.

We can sort references to these boxes by this order.

In this example (if the tool holder were a fraction lower), we can see it would look at the top few triangles in box 1, then maybe a lesser few in box 2, and finally since box 3 and all subsequent boxes are lower than their corresponding holder min z, we can stop there, having scanned 2 boxes instead of 12, and quite possibly discovering a collision (if there is one) on the first box.

Obviously, producing this list of priorities for each box takes a bit of time as well as memory. As with any precalculation, care has to be taken that you are actually reducing the end-to-end calculation load.

The size of the boxes in which these lists are made can be much bigger than the boxes containing the triangles of the model.

At the extreme case, you can use a single holder box, and just list the triangle boxes in order of max-z. Then the algorithm simplifies to merely going through them in order until the box that is below the lowest point of the toolholder is encountered.

I took the plunge and made the online slicing application live today. Read about it on the Free Stuff page.