Freesteel

To be fair, there was also a human interest angle in this “working life of a software engineer story” to make it media-noteworthy enough: the software engineer in question was deaf.

Now, there are many activities in the world which it is more challenging to do if you are deaf than if you are not, and programming computers is probably not one of them. Nor is playing badminton for that matter, even though there is a whole squad of competition players, vastly outnumbering the negligable membership of the deaf lug (linux user group) mailing list, for example.

What if it is the case that careers counselling, as it is experienced in our schools and universities, systematically steers students away from free open source software businesses, and into the traditional channel of vocational training, followed by proper old-fashioned employment in a real company that does things the capitalist way where they talk only about how much money they’re making from the start to the end of their annual report? The company directors not even slightly interested in anything else.

I’d be willing to posit that people with disabilities probably get more than their fair share of careers counselling, and this would result in an under-representation of perfectly agreeable deaf programmers in the open source sector, compared to their peer group who will have been allowed to muddle along a bit more at the start of their lives.

Generally career counsellors are going to want you to seek employment with respectable and astonishingly expensive education software suppliers with notoriously bad service, bogus security regimes, tightly closed software, and who combine this with the willingness to convert these major customer disadvantages into financial vitality that makes them qualified to apply through the government’s gratuitously complex procurement systems that at no time take any account of coding quality or long term vision (except the vision to make more money).

So it was that the Guardian’s photography correspondent, Leo Bendictus, interviewed Xander Hurley, who also features on the net as a Deaflymic Badminton champion. The article begins:

So … I pause, because this is a question I have dreaded asking. Erm … what does a software engineer actually do? Xander Hurley stares quizzically across the table. He is a long-limbed young man, with floppy blond hair and blue shirt. He has already explained how he meets clients, discusses with them what they need, and then goes out and makes it for them.

“Can I borrow your pad?” he asks. I slide it over, with a pen. “For example, if I was to create a calculator to add two numbers together.” He pauses, looking suddenly concerned. “I hope this doesn’t sound patronising?” Not at all, I assure him, and probably impossible. “OK. Bear in mind I’m using C#, which is a language, part of Microsoft .NET.” Consider it borne.

Hurley writes “value1 = 10″ on my pad, followed by “value2 = 20″. “This is pseudocode, by the way,” he explains, “not actual code.” I nod fraudulently. “Now I want the code to take these two numbers and add them together.” He writes “int result = value1 + value2″. “Now, ‘int’ stands for integer. It’s a whole number. And that,” he points to the word “result”, “is a placeholder, which is like a bracket for holding numbers. It’s just a name. It could be anything.” He crosses out “result” and replaces it with “Xander”.

“So you add value1 to value2, and that gets assigned into there.” My pen hops about the page in his large hand. “So ‘Xander’, after doing this, will contain 30.” He looks up like a maths teacher who has just made everything clear, and sees, as maths teachers must often do, an expression of poorly simulated comprehension looking back at him. What I am still struggling to decide is whether software engineering is in fact much simpler than I had hitherto imagined. Or far, far more complicated.

Certainly what Hurley does with C# most of the time would be beyond me. He is a member of the data exchange team at RM, a large education software company, in the dowdy bowels of whose Oxfordshire headquarters we are sitting now. Here Hurley spends most of his days building computer programs to help schools manage their information. At the moment he is working on a way of enabling pupils and parents to access their own data themselves.

The reporter went on to explain how Hurley took six years to get through his software engineering course at university because of the difficulty lip-reading the lecturers from 20 metres away, and how he pulled out of exams at the last minute twice to avoid getting a bad marks in his final degree.

Now, I know a lot of programmers, and this is not how any of us learned our trade. Exams in software engineering the butt of jokes. When I used to work for a company and we had to hire somebody, we’d give them a one page coding quiz and that pretty much sorted everything out. Oddly, this was not standard practice in other companies, as though their chosen criteria for the job of being a programmer did not include the ability to programme. I flunked every single job I’ve ever applied for, and one thing I can do well is programme.

Programmers generally teach one another one on one. We practice for hours, sometimes all night long. We debug other people’s code. We search for answers on usenet. And, at the last resort, we RTFM. All this social activity over the decades has given rise to the open source community from which the whole world has benefited.

The ironic thing is that Hurley is permitted to talk about actual in the boundary of a newspaper story, but he works for RM in Oxford, one of the notoriously evil PFI contractors which doesn’t care one jot about code. Check out their web-page and any news. It’s all about money money money money money.

For contrast, you could inspect the website for moodle which is the leading competitor of RM for software to run schools. One click and they’re talking about the code, the features, what they’re trying to do with it, and how you can learn about it and use it. It’s all about friendship, not business. In a business, they occasionally take a break from the money and talk about people. Watch this video where some lobotomized zombies unfortunate enough to have been TUPED across to RM’s PFI business explain how they’re having a wonderful time doing exactly the same job as before for exactly the same pay and conditions while only costing the taxpayers only four times as much for a lot of senseless paperwork and stagnant technology.

The PFI system bundles up the publicly utilized IT infrastructure into a system of bogus shell companies and tax-efficient asset vehicles, such as Local Education Partnerships (LEP), using the same crooked logic of obscuring things illustrated with the sub-prime loan banking crisis. While the job of installing an operating system or wiring a network router is something that fundamentally anyone can do and is only ever going to get easier as the hardware and (open source) software technology improves, the result of packaging this work within the exclusive remit of one particular trade employee of one particular company for the next thirty years is only going to make things cost much more than they should. That’s what big profits are all about — the ability to invoice for much more than something is worth. It used to be that we’d laugh about how many union workers it took to change a lightbulb, because the union was only ever interested in preserving jobs. Now the question is going to be: how much money is it going to cost to change a lightbulb? The act of changing the lightbulb is going to be done perfectly efficiently, but you will pay. That’s because it’ll be declared as an Emergency and this will cause the need for Unprogrammed Maintenance.

It’s all there in the ICT Services Contract for Partnership for Schools:

8.8.8 If, as a result of an Emergency, the need arises for Unprogrammed Maintenance, the LEP may carry out such Unprogrammed Maintenance provided that the LEP informs a member of the senior management of the School(s) affected by the Unprogrammed Maintenance as soon as possible and the LEP notifies the Authority’s Representative as soon as possible (and in any event within five (5) Business Days of the occurrence of the Emergency) of the extent of the necessary Unprogrammed Maintenance and the reasons for such Unprogrammed Maintenance. The LEP shall take all reasonable steps to minimise the duration of, and any interference caused by, such Unprogrammed Maintenance.

8.8.9 The carrying out of Unprogrammed Maintenance shall not be construed as relieving the LEP from providing the ICT Services or as entitling the LEP to any relief from Deductions.

8.8.10 Notwithstanding that there has been no objection to a schedule of Programmed Maintenance submitted in accordance with clause 8.8.3 (Maintenance of the ICT Assets), the Authority’s Representative may, at any time, require the LEP to accelerate or defer any Programmed Maintenance by giving written notice to the LEP, (unless otherwise agreed) not less than forty (40) Business Days prior to the scheduled date for carrying out such Programmed Maintenance (where applicable, as accelerated), which notice shall set out the time and/or periods at or during which the Authority requires the Programmed Maintenance to be performed. The LEP shall, within ten (10) Business Days, notify the Authority of the amount of any additional reasonable costs which it will incur as a direct consequence of such acceleration or deferment (the Estimated Increased Maintenance Costs). The Authority shall, within a further period of ten (10) Business Days following receipt by the Authority of notification of the amount of the Estimated Increased Maintenance Costs, at its option, either confirm or withdraw its request to accelerate or defer the Schedule of Programmed Maintenance. If the Authority does not respond within this ten (10) Business Day period, the request shall be deemed to have been confirmed. The Authority shall reimburse the LEP the direct and reasonable costs actually incurred by the LEP as a consequence of such acceleration or deferment up to, but not exceeding, the amount of the Estimated Increased Maintenance Costs.

The Guardian article ends with a story of how Hurley was once called home by his mother to fix her computer and how he travelled two and a half hours only to discover that all he needed to do was turn on the plug. We smile at this comical situation, because it has often happened to us. It’s a weakness when humans and computers come into contact. The problem of the plug being turned off is common even to a desk lamp, but because there were so many other things that could go wrong with the computer it is easy to over-look it.

As with any other human weakness in our interaction with the modern world, our economic system is designed to reward entrepreneurs who prey on and exploit it to the maximum extent the law allows. We have a bad intuition with probabilities: mega-casinos. Our appetite is satisfied by cheap processed food that will kill us: McDonalds. We get addicted to chemicals and ape what the stars do in the movies: Tobacco. We are greedy to make lots of money for nothing: Ponzi schemes. (There are regulations outlawing overt versions of the Ponzi scheme because it is so damaging to the economy, but they didn’t catch up in time to prevent the current financial crisis.)

These vast PFI service contracts now gobbling up the public sector IT are merely institutionalizing the lack of knowledge at the current state of technology, locking it down as effectively and systematically as Coca-cola targets children, getting them hooked on the brand and the sugar while they’re young and impressionable. The fundamental purpose is to disempower people.

Think about it: any employee unfortunate to work for one of these companies is basically forbidden from talking to anyone about the “company secrets”. What are these company secrets? Well, they’re often on the face of them secrets kept from the customer about how they could do things themselves. It is not in the company’s commercial interest for these secrets to get out, or it will no longer be able to charge people for doing things for them.

This is fundamentally the opposite attitude to open source programming which is why it is doomed in the long run.

It would help, however, if newspaper reporters were able to stoop to the level of talking about what programming is all about with open source people for a change. But they won’t because it’s deemed too boring and geeky.

Unless it is framed in terms of making money.

Or it intersects with something worthy, like deaf culture. Hacker culture just doesn’t deserve respect.

It’s taken nearly a week and 400 lines of C++ code to complete the algorithm shown in the above picture, where a series of trapeziums, representing the conical sections of a tool holder, are merged into one continuous monotonic (in radius distance from the axis) piecewise linear curve.

We get these kinds of non-joined up segments when thickness is applied to the toolholder shape and all the previously consistent sections start to overlap in various ways depending on how much material you’re adding. It’s important to have a consistent contour to work with because you can code things much faster than checking the collisions of all the independent segments individually. For example, when you lower the cutter down in Z onto a point, the distance between the point and the axis tells you the unique conical segment that it will collide with. No need to check any others.

You notice in the drawing the big triangle contributes three individual segments to the final red line. This aligned envelope finding algorithm — pain though it is — is about a 100 times easier than the polygon intersecting algorithm which you have to implement if you want to find the offset contour from an arbitrarily shaped pocket slice. That’s an algorithm many CAD programmers have foolishly tackled, not having the wit to recognize the extreme difficulty of it. In fact, if I was giving CAD developers interviews for my job I’d ask them to tell about how they would approach the problem of finding the offset of a polygon, and if they showed any confidence of being able to do it, they’d fail the shortlist. Only by suspecting that you’ll have a hard time doing it by brute force (which results in a debugging project for the next 20 years) are you likely to hunt for and find out about the real solution, which involves Voronoi diagrams of lines (not the simpler one of just points).

For some reason I’ve stupidly implemented it in C++ rather than Python, probably because I needed to use my Along(lam, a, b) function and other little quirks in my small functions library. This means that we need to provide accessor functions to get the results back out of the C++ objects and into the Python, which is the interface to the graphical visualization tools. Maybe when I’m feeling I’ve got the time I’ll convert it from one language to the other (or someone else can volunteer if they want to — I’ll give you the code). Like I said, I made the wrong choice. I’ve been having a heavy cold all week, which may have clouded my judgment.

It’s not working out as I had hoped.

The grand plan was to run the Windows-only software HSMWorks and the C++ development compiler from Linux through a VirtualBox session that hosted a copy of Windows. That would mean that while the whole of the “we need high performance and to play games” CADCAM world chose Windows, I wouldn’t be stuck with it in order to develop the software.

Now Windows, and especially the new Vista, acts like it is the one true operating system in the world. When you install it on your machine, it takes ownership and blocks access to all other operating systems that might be there. The software is a lazy, arrogant bully, and most people give in to bullies if they want an easy life. Therefore bullies predominate. Even when ugly.

I should have known that my grand scheme couldn’t possibly work. I would have had more success if I bought a 100% Windows machine and ran Linux in a virtual box session within Windows, because things can get along that way. Linux is an effete wimp that does its best to get along in a world with a bully. But since now only 30Gig of disk is in the Windows partition, there isn’t enough space for that.

Here’s my log of the day.

9:47 Insert HSMWorks disc
10:00 Installed.
10:06 Run HSMWorks
10:08 Download Firefox
10:09 Install Firefox
10:10 “Detected change in activated licensing components. You need to run HSMWorks as an administrator”
10:11 Firefox complete.
10:12 Control panel suggests the vista Julian account is an administrator.
10:13 Skype to Copenhagen - bug in old version. “update from web”
10:20 Download the experimental version from hsmworks.com
10:23 Copy out license codenumber into form
10:24 “Failed to update machine configuration. Please make sure that you have administrative privileges”
10:28 Although when you list the user accounts it says Julian (Administrator), the “Make changes” page has the radio button for “Standard user” set to On and “Administrator” set to Off; when you click on this the “Change Account Type” goes grey.
10:31 Becka, who has the password in her office, is not there.
10:32 Install the Chinese Government IM service
10:33 Try to download putty and save in System32 directory. It won’t let me.
10:35 Read the net for a while.
10:41 Copenhagen gets back with the idea of running a remote Netviewer session. Software was installed with HSMWorks
10:42 All sessions in use now. come back later.
10:50 I misinterpreted the administrator privileges dialog on Vista.
10:56 Run Skype and take a .reg file from Copenhagen
10:59 HSMWorks still doesn’t work (administrator error)
11:00 Get another .reg file from Copenhagen
11:01 Failed again. “Make sure you have administrator privileges”
11:13 My old computer, which I’m taking these notes, rebooted for an operating system update whether I like it or not. I’m getting screwed over by Windows in stereo. Martin tells me to stop swearing.
11:15 Still waiting for remote viewer key thing so Copenhagen can work out why my UAC (User Access Control) is blocking HSMWorks security key installation. I couldn’t save putty.exe directly to system32 directory; I had to copy it in and go through dialog boxes.
11:17 Windows comes with java installed.
11:20 Try to install python. Fail due to lack of administrator privileges. Conclude there is some irritating dialog box obstructing administrators from doing administratory things.
11:31 Check through the internet and discover the Run as… technique
11:34 Download the JDK 1.6
11:35 Download TortoiseCVS and TortoiseSVN
11:42 Voluntarily register with Sun for the JDK
11:43 Run netviewer and hand control of the computer to Copenhagen
11:46 My computer is now possessed.
11:49 Watch him do the Run as… hack
11:50 Debugging appears to be happening
11:57 Install TortoiseCVS at my own risk
12:00 Install Audacity to see if there’s a mic. Is none.
12:05 Install Open Office
12:10 Install HSMWorks 2008
12:14 Decide to install C++ while they look into it.
12:30 Run As… hack on HSMWorks works.
12:37 Now downloading 0.5Gig service packs for the C++ compiler
12:48 Go to lunch
14:00 Back from lunch. Finish installing C++ Studio updates
14:20 Down to 3Gig disk space out of a total of 30Gig in the Windows partition
14:29 Begin SVN checkout of HSMWorks codebase
14:36 Back to 4.7Gig free. Uninstall Open Office
15:10 Get the C++ environment working
15:13 Install Swig. SVN checkout HSMWorks thirdparty code
15:37 Uninstall JDK and extra Java versions
16:00 SVN checkout the vroni code
16:05 Do more recompiling because I selected the wrong solution (so many old ones floating around not cleaned out)
16:08 Struggling over getting the python24 that we use in HSMWorks compiled. Ask Copenhagen for help.
16:10 Getting itchy to log in to Ubuntu, but then I won’t get any workwork done. The point here is to build the development environment the Danes use in Solidworks, which I have got by without until now.
16:43 still struggling with getting the python in HSMWorks to function.
17:00 Shutdown, reboot to Ubuntu. Find that all the software I’d installed before sending it back to the Emporium is still there
19:06 Still fighting over getting one of virtualbox or vmware to work
19:49 Have discovered I should be loading virtualbox2.0 not virtualbox-ose. Then chown-ing all the /dev/sda disks
19:57 The virtualbox works, Ubuntu boots in it, but Vista is sick when it does so.
20:20 Serious error with apt. Try rebooting
20:23 fsck error. go into root and let it try to fix everything

Fed up, I went home without my computer.

Using a dual boot, my working habits are going to be different. I am either going to do some actual machining work in Windows and not have any room to do anything else, or reboot into Linux and do all the fun stuff with undemocracy, publicwhip, tunnelx, and other projects. I won’t be able to change jobs so easily in the middle of the day, so I will be forced to remain focused on finding the intersection between a line and a torus if that’s what I have to do. I’ll try it. Maybe it’s all for the best.

You don’t begin a project that will take the rest of the year and more without evading it as long as you can. Finally I’ve begun to break ground on this.

Background: Almost all industrial algorithms for generating toolpaths for 3-axis machining are based on the Drop Cutter function, where the tool is lowered along its axis towards a triangulated surface until it makes contact. I have discussed this here, where I also add my usual complaint about how almost all of published academic literature on 3-axis machining is based on the contact point offset from a point in a parametric surface, and so is of no use. The problems raised by that approach are insurmountable, and you don’t need to solve them because there is a better way.

For most CAM systems, if you speed up the Drop Cutter function (which for toroidal cutters often depends on solving the quartic equation), then everything runs faster. The other determination of performance is if the implementation of the machining strategy calls this Drop Cutter function too frequently. That’s how fundamental the function is.

The only 3-axis machining algorithm that does not depend on the Drop Cutter function is the Horizontal Projection function used in the calculation of constant Z (waterline) contours. (A visualization of a bug in it is shown here.) This Horizontal Projection function finds the points of intersection when the cutter moves in the plane perpendicular to its axis. In Machining Strategist/Depocam I never solved it for the toroidal case (because I didn’t know the answer to an order six polynomial which you get instead of the quartic), and used a neat little fudge where I could get to the same answer by measuring the contours for a ball-nosed cutter and then offsetting the contour in its plane by the radius of the circular axis of the torus. In HSM Works/Adaptive Clearing I finally worked out how to do it, which is fortunate because I’m going to need it here, and there’s no way round it.

The obvious fundamental 5-axis cutter location function is shown in the diagram above. The cutter is in an arbitrary orientation (the red dotted line is its axis) and is dropped in an arbitrary direction (the thick green vector) to find the point of contact with the triangulated surface (outlined in blue).

We can transform everything into a better position and make the green vector the vertical Z-axis. Then, if the dotted red line (axis) is in line with this green vector, we’re back to the 3-axis condition. If the dotted red line is horizontal (perpendicular to the green vector), then that’s Horizontal Projection function. Otherwise we can rotate the assembly so that the dotted red line is in the X-Z plane to observe that the only new parameter we need to include is the angle between the axis of the cutter and the direction of projection. (If the red axis line is below the horizontal I’m going to reflect about the horizontal X-Y plane.)

Makes it seem simple. The interface into the big calculation engine that solves the Horizontal Projection function merely needs to take a unit 2D vector in the X-Z plane representing the tilt from the red vector to the green vector. A value of (1,0) is the Horizontal Projection, and (0,1) is the Drop Cutter function.

At least that gives it a home and a tiny tweak to the interface for the other developers to access. But there’s going to be thousands of lines of hard code coming up real soon over the next few months.

BTW this doesn’t unify the Horizontal Projection and Drop Cutter functions, because the Drop Cutter, being as fundamental as it is, is unbelievably optimized. In its case there is a rotational symmetry about the Z-axis that can be heavily exploited. Once there is a tilt from this axis, the symmetry is broken.

And so to work.

Here’s a computational geometric problem I found in the course of work with no obvious good algorithm to solve it.

Take this picture below. The dotted line provides orientation and shows you where the endpoints are. We’ve got red dots and blue dots, and we start with a green piece of string threaded above the red dots and below the blue dots. (We can assume it’s in order along the orientation of the dotted line.)

Now pull the green string tight through those endpoints to get a nice zig-zaggy result like so:

I need a clean algorithm that will get to this answer. For the moment I am confounded.

The actual problem relates to smoothing a 5-axis milling machine toolpath with respect to one of its rotational axes while avoiding collisions. For this, the situation is a little more complex (I don’t want to calculate the positions of the blue and red points unless I absolutely have to), but an answer to the simplified version could lead the way.

Meanwhile, out in the real computational geometry world where there are professors, you’ll discover endless amounts of study of a similar, but somewhat less interesting problem of finding the convex hull of a set of points.

To get to this uninteresting problem, simply throw away all the red points and put the starting line all on one side.

The algorithm for pulling the red dotted line tight to get to the green line over all the points is easy to see: Consider each sequence of three points in order; if the middle point is below the line joining the other two points, then delete it.

If you run this trivial algorithm twice, once for above and once for below, and you started by finding the extreme left and right end points, you get Andrew’s Monotone Chain Algorithm for the convex hull of a set of points, published in 1979.

Finding the convex hull of a set of points has occupied quite a bit of attention over the years. We start with the Graham scan of 1972, the Jarvis march gift wrapping algorithm of 1973, the Alk-Toussaint heuristics of 1978, the Kirpatrick-Seidel algorithm of 1986, and Chan’s algorithm of 1996.

Never has so much mathematical honour been accorded for so little over so many years as has been the case for the computation of convex hulls. New students come to this field and wonder what the hell the whole fuss is about, because it looks just obvious. It is obvious. All the algorithms are pretty much O(nlogn) because they apply a sort function at some point and, in my opinion, are absolutely equivalent. The later advances merely involved partitioning the points into smaller sets, finding the convex hull for each set individually, and merging the result.

As these students grow older and eventually become professors, they realize what the game is, which is to have an easy life in a comfy job doing stuff that isn’t very hard, but just looks like it is because it has lots of equations so no one is going to say it’s silly. At least not anywhere that matters. (Blogs don’t count.)

The last thing you want is for anyone to find an application in your area. You don’t want some random machine tool programmer coming along and saying: “Oh, you look like the sort of person who ought to be able to solve this computational geometric problem I have here,” because they might find you out.

I can rephrase the problem in terms of the fruitful convex hull situation:

I want to see a slick algorithm to go from this:

to this:

where the string is pulled tight, with the blue birch trees on the inside and the red maple trees on the outside of the perimeter.

Then you can get one of your colleagues to name it after you (if your name sounds cool enough), and then later, after they’ve done something with one of the numerous variations of the problem (eg higher dimensions — the string passes through a set of polygons in space — or made-up geometries), you can return the favour by naming their invention after them.

But be warned. The older professors are going to say, “No no no no no. You don’t understand. Convex hull algorithms are the foundation stone of all computational geometry for the last thirty years.” Let’s not be too hasty and get beyond into stuff involving tori, and triangulations, and hundreds of other things it would be useful for someone to look at. You wouldn’t want the subject to become too difficult and sophisticated by the time you grow up. Next you’ll be telling me I should be releasing my code under some new-fangled public license so other people can make advances on it, and that I shouldn’t be using FORTRAN, which is a perfectly good language, I’ll tell you, because it makes moderately straightforward things into a terribly complex scramble without any effort. I am not going to put up with you telling me that your sloppy Python language is so much better and that I should learn something new. You young people always think you know everything.

The point of a university academic is to produce papers. You’re not supposed to get involved with any curious applications that are someone else’s problem. Unless they pay you. And you certainly don’t want to be maintaining libraries of free software functions in use out there in the wider world, like it is some kind of public service.

* Have I mentioned how many implementations of the quartic equation I believe are out there in the industry? I keep wanting someone in a university to maintain a really good one, and part-exchange it for the copies of this routine implemented in all the different CADCAM systems in the world, and do a sort of interesting archaeological code-study on them.

The researcher wouldn’t actually need to write their own. They’d only have to pick the one which is the best. The game is that all the CADCAM companies have a version of this and many other fundamental algorithms, and nobody knows who has the best. But if ten companies all got together and put their implementations into a pot and chose the best, each one would have a 90% chance of improvement in efficiency for free in each case.

Usually, the companies who are most unwilling to consider this game — even as a thought experiment — are the ones with the worst quality software. It’s the lack of curiosity that’s the give-away. They guard their source code jealously, because “someone might learn a secret from it and gain a competitive advantage”, yet they are the last ones who would ever comb through someone else’s code if they got access to it.

As with a lot of concealed secrets in business, the real revelation is that there’s nothing there. It’s just a game of Poker. Fun, but a waste of time, ultimately. It would be nice if someone clever went round the table telling everyone what to play so we could all win big against the House. It’d be more fun for those who want to move things forwards, rather than just maximizing the money. Eh?

“This is the boss’s son; he’ll be working his way up from the bottom over the next two weeks.”

I’ve always wanted to use that sentence. Fortunately, neither my employment with NC Graphics, nor NC Graphics itself lasted long enough for this morale-obliterating situation to come to pass.

However, announced at Surfware on 1 July 2008:

Stephen A. Diehl has been named President and CEO of Surfware, Inc., developer of SURFCAM® CAD/CAM systems.

“I am proud and happy to announce that my eldest son Stephen will take over as Surfware President and CEO of Surfware, “says Alan Diehl, founder and former CEO of Surfware, Inc. “Stephen has been working with me behind the scenes for several years and more recently, full time at Surfware.”

But I’m not here to pick on the elements of shouldn’t-be-admired experience gained working in the vast global swindle and misallocation of capital of which the real-time trading of stocks, bonds and swaps for Fortune 500 companies is but part.

My attention was actually grabbed by a 19th of August announcement of a Notice of Allowance signifying that their patent application has been examined and is allowed for issuance as a [software] patent.

I blogged about this back in November 2005. The links to the patent pending pages on the US Patent Office webpage seem to pull out random patents now (for a Jet nozzle mixer and a Classification-expanded indexing and retrieval of classified documents thingie) because the Office’s website is absolutely shite and inexplicably avoids the use of the handy centuries-old unique-id system provided for these documents by the patent number. On the other hand, my European Patent Office link from three years ago does still work, because it does.

You can read the entire 38 pages of gory details on-line there. The provisional applications were filed in April 2004. Think: if all the work and expense that went into writing this patent and applying for it had instead been applied to working on the code itself, maybe they wouldn’t have had to spend the last four years “taking it to new levels of excellence”.

The announcement explains:

The origin of the patent application goes back to early 2002 — Surfware’s R&D Department. Robert (Pat) Patterson came up with the core idea for engagement milling, and he and Surfware co-founder Alan Diehl, set out to develop it into a workable product. Within one year they had developed two different versions of TrueMill, both covered in patent applications.

Over the next several years, the pair went on to supervise the project based on their core ideas, with some assistance from the SURFCAM product manager. In 2005, the initial patent application for engagement milling was filed with the co-inventors listed in alphabetical order, without regard to their actual contribution.

So that’s why when you search for “surfware” on the USPTO website (I’m not wasting time with their deeplinks) you get:

• Application: 20050246052, Filed March 2, 2005: Coleman, Glenn; (Cave Creek, AZ) ; Diehl, Alan; (Westlake Village, CA) ; Patterson, Robert B.; (Bellevue, WA)
• Application: 20050256604, Filed April 22, 2005: Diehi, Alan; (Westlake Village, CA) ; Patterson, Robert B.; (Bellevue, WA)

Back in 2005, Glenn Coleman was touting the benefits of Truemill in his capacity as Surfware’s Vice President of Product Design.

Also around at the time doing the same thing in his capacity as Vice President of Worldwide Sales, was Domenic Lanzillotta.

And then there was Dr Evan Sherbrooke who was Systems Architect. And there was Terry J. Sorensen who joined in May 2006 and became CEO of Surfware in December 2006, even though he was not Alan Diehl’s son.

Meanwhile, in Scottsdale (Phoenix) Arizona, in October 2006 Mike Coleman (probably no relation) announced the appointment of Domenic Lanzillotta as Vice President of Worldwide sales, and Greg Dare as Director of Marketing at TekSoft. Lanzillotta was formerly Vice President of Worldwide Sales for Surfware, and Dare was formerly Director of Marketing for Surfware.

In September 2007 TekSoft announced a new toolpath strategy, called the Adaptive roughing strategy providing the ability to cut using the full depth of the tool and safely running machines at optimum speed to reduce machining time up to 40% over conventional roughing with less wear.

A friend who went to the EMO 2007 trade show at the time saw it in action. In an interview in the same month, Mike Coleman said:

“Rather than pretending that a couple of guys in the back room can come up with everything that we need, we buy our HSM algorithms from a third party that devotes 10–15 programmers to developing just the HSM modules,” he says. This third party can afford to invest more in the module than most other developers because selling it to companies allows it to amortize the cost over a larger user base.

The two of them, Dare and Lanzillotta seemed happily installed at the TekSoft trade show booths in February 2007 at SolidWorks World (in same room as HSMWorks) and March 2007 at Westec.

In early 2008 Lanzillotta moves to Planit to sell Edgecam software from Thousand Oaks California.

At some point around then, Sorensen introduced his new marketing department with Steve Crane as the Director of Marketing [I have his business card - he told me I was crazy], Steve Myers, Sales Engineer, and Bryan Sullivan, Media Relations Manager.

Then in April 2007, Sorenson, Sherbrooke and Glenn Coleman show up with their new business model attempting to market a new algorithm called VoluMill, which goes on-line in October 2007 from Cave Creek (Phoenix) Arizona.

That gives them about 6 months to write their new algorithm and release it. I observed it in December 2007 while at the Euromold trade show. It uses the neat but flawed idea of hosting the algorithm on their servers and arranging for your CAM system to transfer the model to them, generate the toolpaths, and transfer the results back. It’s a nice idea. The payment is by a monthly service plan rather than, say, per metre of toolpath calculated. We’ve made a much more sophisticated implementation of this, and could have given them the code if they’d asked. It seems that users are not quite as excited by it all as we are, so the innovators all need to work together to create the interest.

Not that any of this happens, mind you. Now I’d thought that VoluMill had basically died as so many on-line things do, but there’s a non-spam message from June 2008 on the forum:

Question: I am a hobbyist user. and although the up-front cost is zero, have you considered a plan which limits the number of tool-paths that can be generated in a month, or maybe a per usage charge?

As a hobbyist I am not so much interested in the aspects of saving time as I am in a good quality tool path. It appears that your paths work well on machines that can not accelerate quickly since they try to maintain a constant velocity.

Answer: At this time we have not received a level of interest that would make it a high priority. However, if the level of interest in such an option increases we will address it accordingly.

That answer is from Joe McChesney, Product Manager. It’s a closed user forum, so I can’t post a message telling the questioner that we’d happily give him a free copy of the Adaptive Clearing algorithm in return for some user feedback and movies.

Given what they achieved in terms of development in their first six months, what have they been doing over the past year? Also, I’ll eat my hat if they have any customers using their service at all. You can see the client source code activity here.

Back to the evil software patents — the filing of which is as much of a waste of programmer time as technical blogging like this — I asked someone about it at Euromold 2005 and took action. I received effective confirmation about it from their General Counsel of Surfware Inc in February 2006. According to the Patent Office rules:

Each individual associated with the patent owner in a reexamination proceeding has a duty of candor and good faith in dealing with the Office, which includes a duty to disclose to the Office all information known to that individual to be material to patentability in a reexamination proceeding.

So that’s all right then.

Not that the Adaptive Clearing algorithm has anything but superficial similarity in intent with TrueMill or VoluMill. But when has that ever been an excuse to avoid grief? The real defence is that the world at large hasn’t found it particularly interesting, so there’s no money worth arguing about.

The fact is, we should all be talking and working together on this. The market does not seem to have taken to new technologies, such as constant engagement milling, as it ought to have been. There are significant savings to be made in production machining by applying something like this, even if it was a very temperamental and unstable release. However, I don’t see evidence at the trade shows of it ever being used by the machine tool vendors, say. The only place it gets exhibited is on the stands of the CAM companies that sell these algorithms, and nowhere else. This is an issue.

With a market that is as conservative as it is, it makes it very difficult to get anywhere, because the dominant CAM companies can keep flogging their ten year old systems at the same high prices, invest nothing into development, and pocketing all the profits for as long as it takes users never to notice.

Ultimately the problem is with the users and their level of interest. They’ve got lots of better things they need to do than care about the software, and none of them seem to show any curiosity whatsoever as to what goes into it. The vendors spin this line about how there’s all these programmers at work in a back room you can’t talk to, and the company has all its secret special valuable algorithms that are extra good works of genius better than the science behind General Relativity, and I don’t think they actually need to bother with these fairy-tales. So few people question it. All the company needs to say is:

“Yes, we sacked all the programmers last year, and we’re down to our last guy who knows how to compile the system for new versions of the operating system. We pay him well to stay. No you won’t get your bugs fixed, because at this stage of development everyone seems able to work around the issues that remain without too much hassle. We’re certain that no one is going to come along with anything new and better because they won’t be able to afford the years of development that it took to get ours up to this stage. Back when our product was being developed in the 1990s it was possible to make money with fewer features and with something that ran slower on the machine, and at that time we were still re-investing the money and keeping lots of well-motivated programmers working on it to get it ahead. Now we don’t need to do this, because we believe that the development gap is too wide for any new start-ups to be able to bridge it with us competing against them while they are still in their early days. We know you, the customer, will not give them a second thought until they have everything we do and twice as good, and they’ll always go out of business before that happens. Today and tomorrow, we own this software. It is indeed stagnant. And if you want it, you can take it at the price we like, and I’ll be able to afford a nice car and continue filling it with gas to drive back and forth across Arizona until this economy goes completely into the ground because we’re not able to tell the difference between producing stuff and making money. Thank you very much.”

Like I said, it would be nice to come clean in the CAM software industry as to which system uses what kernel and whose algorithm. I don’t think the users actually give a toss enough to make a difference to sales. Some transparency would be really helpful for people like me to find out who in the world is actually still programming these specialized algorithms in order to share tips and find out where the jobs are.

In the absence of this, all I’ve got is this blog-ranting about manager-level machinations within the industry that have nothing to do with actually getting any programming work done. Even communication that’s one-way can be useful.

For reasons known to myself, I have decided that it would be convenient to be able to get a quick result for the distance of closest approach from a given point to a model…

I was going to outline how I have begun work on a giant 3D array of cells which each know the minimum answer for all the points in the cube, but have just thought of something better in the process of writing after I spent the last two days on the project.

I was going to cache all the results in an array: vector< vector< vector< double > > > subdividing the region in space and compute the closest difference between cubes and triangles, and began writing the code. Here’s the annoying code for doing it to a point:


void BoxClosest::MergeClosPoint(const P3& p)
{
double pdsq = Square(xrg.Distance(p.x));
if (pdsq > clossq) return;
pdsq += Square(yrg.Distance(p.y));
if (pdsq > clossq) return;
pdsq += Square(zrg.Distance(p.z));
if (pdsq > clossq) return;
clossq = pdsq;
}


where

struct P3 { double x, y, z }
struct I1 { double lo, hi }
struct BoxClosest { I1 xrg, yrg, zrg; double clossq }


The code for edges and triangles is very horrible. There should be some fancy algorithm to fill it in across the entire space, but I don’t know if it one exists. It’s an interesting puzzle.

Anyways, I’m hoping I can throw all that code out shortly if I proceed with something a bit more interesting that is able to cache the results and do it by points instead of cubes.

Ultimately I want a function that gives me the following:


bool IsDistanceGreater(const P3& p, double r, triangulated_model)
{
if (distance(p, triangulated_model) > r) return true;
// false negatives are acceptable as long as it's fast
return false;
}


Now, if we know (have earlier calculated) that s = distance(q, triangulated_model), and it happens to be that s - distance(p, q) > r then we can get the answer quickly, using power of metric spaces.

We have ultimate case of lazy calculations here. The function remains valid for the same set of triangles, so it can be shared among several algorithms and they will constantly get faster as the computer runs on them for longer. It could be a strange situation. The first 5-axis pass will be slow. The second will be faster, as long as it doesn’t go too far away from the first. How this optimizes for multi-core coding is another problem.

Here’s a bit of easy C++ code using a template class with a template member function that compiles and executes with no problems on MS VC8:

But try this on a linux machine with gcc (I used “gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)”) and you will get into compilation trouble:

So, what’s wrong?
If there’s only one candidate, why does the compiler not instatiate that one? Why is there a matching problem, and why does VC8 not spot this?

I could wait until tomorrow with telling you the solution, but I won’t let you racking your brains…

here it is:

replace the declaration of the template member in template struct A with this:

and you get a result. But why is that? You tell me!
And what do you do if you want to code a member that needs pointers, not constant references? Somebody out there who knows the answer?

While we’re waiting for someone to ask the Question from Hell, Becka has appeared in today’s New York Times.

Evidently this is related to the conference in Hamburg she’s just been to. I can’t give you a link because conference alerts takes things down too quickly, and I can’t even check it up yet on archive.org. I’ll be able to find out maybe in 5 months time what it was without asking. This is an information black-hole.

A tip for any of you reporters who don’t see your job as sitting back and waiting for the PR industry to spoon-feed you with well-crafted press-releases, she’ll be at the ECVP 2008 in Utrecht showing off her haptic experiments.

Update: Stumbled upon this crude visualization of point-cloud data used to make a music video. For decades CADCAM engineers have been trying to convert this sort of data into usable surface models (eg at the meshing round table). This is one of those insoluble problems, because only when you make a concerted effort to solve it do you realize that what seems to be enough data is in fact insufficient, and everyone who hasn’t gone through that process just thinks it’s because you’re not smart enough.

Anyway, what’s makes this effort cool is they’ve released the point cloud data in downloadable format so people can play with it. Some results, using standard applications, are here. Maybe someone in the wider audience will prove smart enough, having been exposed to some real messy data. Working from clean data at the start seems always to spoil the intuitive understanding of the problem. That’s why I am thankful that my initial CADCAM experience was with the output of NCG Toolmaker, where everything was broken and none of the surfaces connected up, as you get from proper solid modellers these days.

This is the result of a rapid “old feature” -> “idea” -> “new idea” -> “experiment” cycle of about a week. The Danes said they needed the feature to measure how long the toolshaft should be for a given toolholder and surface model.

In Machining Strategist/Depocam, this feature is implemented by analysing all the positions of a theoretical tool holder at every point of a given toolpath and comparing its interference with all the triangles in the model in a potentially n³ algorithm. This produces a monotonic graph of height above tooltip against maximum diameter the toolholder could be at that level and not collide with the part. You can use this to instantly predict the length the tool shaft needs to be (the stem between the cutting tip part of the tool and the chuck) given different shapes for the holder or chuck.

This is nice in theory, but in practice chuck shapes don’t change, so you might as well start with a single holder or chuck shape and calculate how high it has to be from the tool tip along every part of a given toolpath. The calculation gets faster and faster as you sample along the path, because you need the global maximum value, and with every increment of the running maximum there are fewer triangles to test the toolholder against. Add to this the fact that the operation is trivially parallelizable, and that my 3-axis holder location function is surprisingly fast (designed without compromising on memory), and the result is responsive without this intermediate data.

However, the Danes want something even more user-friendly. They wanted the tool holder length for the job without giving it a toolpath to begin with.

I couldn’t see the point in this, because the only way to implement it would be to produce a dense toolpath across the part, call the previous function, and then discard this useless toolpath. Now you’ve got a single number for the length of tool shaft, and you calculate the toolpath you wanted to anyway. Then you’d have to verify the shaft length against it just to be sure. And really you should just have the patience to wait to get this number at the right time in the course of the calculations, so you don’t waste duplication of so much cutter locationing on the surface. Unlike the tool shaft height algorithm, it doesn’t get faster the more you sample. You’ve got to scan everywhere densely because there might be just one deep narrow slot into which the tool falls, necessitating a very long tool shaft.

(Thinking about it now — and perhaps the Danes knew this and forgot to tell me during the ensuing argument over the pointlessness of this feature request — this feature does have an application for 3+2 machining when you want to to access the model from different directions in order to get away with a shorter tool.)

So, anyway, leaving it for a couple of days, coming back to it, and thinking some more, I realized the bit I didn’t like was the huge calculation resulting in one lone floating point number. What if I produced a height field where at each XY point on the drive plane it gave you the minimum length of the tool shaft? You could colour shade the surface instead of producing a height map if you had to. But still you need the numbers. I realized I could build it into my under-used stock model algorithm (it’s used to produce the fillet surfaces, but it doesn’t do animations, so no one wants it when they can bring in MachineWorks, which already works for everything, like 5-axis, which this one doesn’t). The other advantage of the stock model algorithm is it’s the same one that runs all the other algorithms (scallop, zslice, pencil, area detect) and so is already parallelized. So there.

Probably going to run out of memory, but who knows. It makes the right picture. As you can see, the high points correspond close to the steep walls. And if it was ridiculously fast, (which is isn’t going to be) you could use the mouse to vary the tool-axis in real time and see the heights changing as you maneuvered towards a more optimum position.

We’ll shelve it for another couple of weeks and come back to it. I’m minded of the fact that users normally have to type in their “desired” 3+2 style tool axis in a dialog box, usually by guesswork or using their favourite default number (eg 45degrees from vertical). It is possible that this will work will move towards the computer discovering the optimal tooling angle on its own. Or at least shifting it slightly to a better position (such as 39degrees from vertical) in a way that suddenly allows you to use a shorter tool from your stock list. The truth is, in any user interface dialog box which allows the user to set it to “any number they like” (as if this is an advantage), the option should be to type in: “The best one”.

Meanwhile, we’ll just check out check out a number of very uninspiring websites, declare it forevermore now unpatentable, and move on.

CADCAM employees, respecting the irrational demands of their companies, are normally astoundingly reticent about any kinds of innovations and ideas that might be going on. The official reason for this habit is that the atmosphere in their office is so bubbling with heaps of potently good CADCAM innovations that if one such idea leaked out, someone who heard it would be able to apply it, win the entire market share, and put them out of business. Another explanation, probably closer to the mark, is it’s like the secret conclusive evidence for weapons of mass destruction. The secret was there wasn’t any. The commercially confidential information is that all the programmers in the office are bored out of their tiny minds, don’t want to have any ideas that just cause more work and absolutely advantage or glory coming back to them owing to the anonymized force of the corporation, and can’t even be bothered to surf around the internet for places where some sort of half-formed ideas might be disclosed by some nitwit who’s out of control of his employer and doesn’t understand the protocol of silence and the jealous protection of technological stagnation that allows clanky old ancient first-draft CADCAM kernels to continue to compete in the market like they were fresh out of Stanford, and be bothered to leave an anonymous comment at the bottom of their blog to encourage them to continue this nutty practice of giving away important secrets that harm his own business and helps everyone else’s to get better. It’s not like ideas only develop without sharing and testing and discussions and different implementations to get towards something that might eventually be half good, like the sales-theory that it will all come out straight and perfectly formed in the next release and take the market by storm. People are not that excited by things any more. And those developers who do still have some life left in them to offer need to understand this so they can move their work forwards and faster and eventually leave this tranche of ossified kernels behind, because at the moment it takes more than a decade for the market to notice that the programmers have, like Elvis, left the building and that ten years of uninvested consumer profits have been frittered away like a sour bet on the stock market and a yard deep stack of pointless legal paperwork. It’s amazing any progress gets made in spite of this sickening business cultural attitude. And that’s exactly how long your shaft needs to be.