Freesteel

This is a follow-on from the Diamond Angle article about useful encoding of plane angles without trigonometry.

The same trick can be applied to 3D vectors using a regular octahedron instead of a diamond.

The corners of the regular octahedron are:

  { (1, 0, 0), (-1, 0, 0), (0, 1, 0), (0, -1, 0), (0, 0, 1), (0, 0, -1) }

Another way of writing it that shows off how rubbish mathematical notation can be sometimes is:

  { (x, y, z) | x, y, z in {-1, 0, 1} where 2 of the values are 0 }

The corners of the cube, on the other hand, can be expressed as:

  { (x, y, z) | x, y, z in {-1, 1} }

Let’s start with the conventional angular encoding of a vector into latitude and longitude:

def RadianPolarAngle(x, y, z)
    r = sqrt(x*x + y*y)
    return (atan2(x, y), atan2(r, z))

This is obviously decoded by:

    (x, y, z) = (sin(a)*sin(b), cos(a)*sin(b), cos(b))

The ranges for the two encoding angles are 0 < a < 360 and 0 < b < 180, but the disadvantages include the use of slow trigonometry, and the existence of two poles where the encoding density is high.

An uneven density means an unnecessary loss of precision:

Suppose I encode this pair of values into two bytes (16 bits) by rescaling them like so:

   int(a/360*256) * 256 + int(b/180) *256

Then the directions near b=0 and b=180 will be preserved far more accurately than the directions near b=90. This represents an inefficient waste of my small and finite number of encoding values.

Here is a picture of the point distribution stepping every 5 degrees:

The three blue lines are the x, y, and z (pointing up) axes.

The slow trig functions problem can easily be solved by substituting DiamondAngle in place of atan2 so that 0 < a < 4 and 0 < b < 2. This gives a picture like so:

The right hand picture plots the vectors without normalization so you can see how they lie on the surface of an octahedron. But looking at the left hand picture, you can see a very slight higher density in line with the x and y axes (due to the DiamongArg encoding), as well as the very high density near the points (0,0,1) and (0,0,-1) axis.

A better solution is to extend the concept of the DiamondAngle to the OctahedronAngle by breaking the 3D direction into octants (rather than quadrants) and encoding the intersection with the triangle spanning the relevant octant.

We can number the octants between 0 and 7 like so:

    octantnumber(x, y, z) = (x > 0 ? 0 : 1) + (y > 0 ? 0 : 2) + (z < 0 ? 0 : 4)

and then, given x, y, z > 0, we can encode the vector’s intersection with the triangle spanning the octant:

    triangle[ (1,0,0), (0,1,0), (0, 0, 1) ]

like so:

    (a, b) = ( x/(x+y+z), y(x+y+z) )

where a, b, > 0 and a + b < 1

The inverse function (subject to normalization) is:

   (x, y, z) = (a, b, 1 - a - b)

So, the first version of our encoding is obvious: We can encode the number of the octant in 3 bits, and the direction within the chosen octant with two positive values whose sum is less than 1.

But we can make this more compact.

There are 8 such right-angled triangles in the square defined by -1 < a, b < 1, so we could use the number of the triangle to number the octant:

    trianglenumber(a, b) = (x > 0 ? 0 : 1) + (y > 0 ? 2 : -2) + (abs(a) + abs(b) < 1 ? 0 : 4)

and substituting a valid range for a and b like so:

    (a, b) = (abs(a) + abs(b) < 1 ? (abs(a), abs(b)) : (1 – abs(a), 1 – abs(b)) )

What we are working towards here is a wrapping of the 2×2 square onto the octahedron, and trying to have the same effect we wrapped the line segment [0, 4] around the diamond.

But can we make it continuous?

We can get continuity on the top pyramid of four triangles easily. For z > 0

   OctahedronArg(x, y, z) = (x / (abs(x) + abs(y) + z), y / (abs(x) + abs(y) + z))

And the inverse (subject to normalization) is:

   (x, y, z) = (a, b, 1 – abs(a) – abs(b))

Here is the picture of it.

You can see the DiamondArg style slight elevation in density in the planes of the x, y, z axes, but it is nothing like the huge density near the point (0,0,1) axis when we do it the traditional way.

Maybe a slightly better visualization involves imposing a checkerboard pattern by discarding the points where:

   int((a + 2) * 10 + 0.4) + int((b + 2) * 10 + 0.3) mod 2 == 1

to make it out of phase with the axes and plot how it crosses them

Extending this down to the lower pyramid is less straight forward. The outer triangles of the quadrants (where abs(a) + abs(b) > 1) have to equate their open edges, preferably without discontinuities.

The x, y > 0 double-octant spans the upper and lower pyramids like so (see middle diagram above):

   (x, y, z) =  (x + y < 1 ? (a / (x + y + z), b / (x + y + z)) : ((1 – y) / (x + y – z), ((1 – x) / (x + y – z)))

The x and y coordinates seem to reverse, because at the x + y = 1 line (x, y) = (1 – y, 1 – x).

The inverse function, for a, b > 0 is:

   (x, y, z) = (a + b < 1 ? (a, b, 1 – a – b) : (1 – b, 1 – a, 1 – a – b) )

It’s possible to continue for the final 3 octants and and have something that is as good as it’s going to get:

def InverseOctahedronAngle(a, b)
    h = abs(a) + abs(b)
    if h < 1
        return (a, b, 1 – h)

    if a > 0 and b > 0
        (x, y) = (1 – b, 1 – a)
    if a > 0 and b < 0
        (x, y) = (1 + b, -1 + a)
    if a < 0 and b > 0
        (x, y) = (-1 + b, 1 + a)
    if a < 0 and b < 0
        (x, y) = (-1 – b, -1 – a)

    return (x, y, 1 – h)

For the sake of completion, the encoding function is:

def OctahedronAngle(x, y, z)
    s = abs(x) + abs(y) + abs(z)
    if z > 0
        return (x / s, y / s)

    if x > 0 and y > 0
        return (1 – y / s, 1 – x / s)
    if x > 0 and y < 0
        return (1 + y / s, -1 + x / s)
    if x < 0 and y > 0
        return (-1 + y / s, 1 + x / s)
    if x < 0 and y < 0
        return (-1 - y / s, -1 - x / s)

I’ve been using greater than signs (>) rather than greater than or equal signs, because I don’t know the code for them, and because these are the boundaries where it gets interesting.

Let’s see how everything stacks up with regards to continuity across the z = 0, abs(a) + abs(b) = 1 boundary in the InverseOctahedronAngle(a, b) function.

  a > 0, b > 0  ==> a + b = 1 ==>   (1 – b, 1 – a) = (a, b)
  a > 0, b < 0  ==> a - b = 1 ==>   (1 + b, -1 + a) = (a, b)
  a < 0, b > 0  ==> -a + b = 1 ==>   (-1 + b, 1 + a) = (a, b)
  a < 0, b < 0  ==> -a - b = 1 ==>   (-1 - b, -1 - a) = (a, b)

That accounts for all the internal boundaries of the -1 < a, b < 1 square. But the 8 half edges of the square equate to the 4 lower edges of the octahedron, and the four corner points equate to the bottom vertex of the octahedron at (0, 0, -1).

Let’s start with those corners where a, b in { -1, 1 }

  a > 0, b > 0  ==> (a, b) = (1, 1) ==>   (1 – b, 1 – a) = (0, 0)
  a > 0, b < 0  ==> (a, b) = (1, -1) ==>   (1 + b, -1 + a) = (0, 0)
  a < 0, b > 0  ==> (a, b) = (-1, 1) ==>   (-1 + b, 1 + a) = (0, 0)
  a < 0, b < 0  ==> (a, b) = (-1, -1) ==>   (-1 - b, -1 - a) = (0, 0)

Now consider b = 1. For t > 0, I would hope for (t, 1) to equate to (-t, 1):

  a > 0, b > 0  ==> (a, b) = (t, 1) ==>   (1 – b, 1 – a) = (0, 1 - t)
  a < 0, b > 0  ==> (a, b) = (-t, 1) ==>   (-1 + b, 1 + a) = (0, 1 - t)

So it works!

The same applies to the halves of the other three sides of the square, proving that we have a good mapping and are not going to have to worry too much about precisely knowing which octant a point is within (as implied by all those missing greater-than-or-equal to signs in the above snippets).

It also suggests we could do a pretty good distance function in this space that would satisfy the metric space rule, though this would need to be checked out.

This function was developed for the scallop bisector algorithm in order to pack the directions into one 32 bit word.

A long time ago, when I was working for NC Graphics, I solved the same problem when designing a depth buffer structure by encoding (x, y, z) into three bytes by mapping each -1 < x < +1 into an integer less than 256. The fourth byte was was the colour.

The following year OpenGL became available and we started writing Machining Strategist.

Please post any errors in the comments below.

Martin and I had an inner cabin without a window on deck 9 of the Dana Sirena on the journey back from Denmark. We passed the time eating and drinking beer in the cabin and coding.

In the morning Sky News were running this story:

A ship sent to Brazil from Britain allegedly full of nappies, condoms and other toxic waste has arrived home [to Felixstowe] after being sent back in disgust.

When the MSC Serena docked in the port of Santos, near Sao Paolo, authorites opened up a container and, instead of the clean recyclable plastic expected, they found a stinking mess of rubbish.

Cool, I thought. I’m getting a little sick of plying the waters between Harwich and Esbjerg up to two times per year on this ship where the meals are over-priced and going downhill, so it was interesting to hear it shared a name with a toxic waste ship in the same harbour at the same time. (BBC news story.)

Anyway, here’s my photo.

It’s probably only a few containers of many that contain the crap. Pretty minor issue. If you have some ships that are complete rusting hulks full of asbestos and other toxins that you haven’t been bothered to clean up for the last 40 years, they are welcome at a place further up the coast.

While at sea, the Danish captain came on the intercom and told everyone to go out on deck to see the fleet of 25 “tank ships” parked off the coast of Great Yarmouth waiting for the recession to be over so they could get a better price for their oil. He said it represented one month’s supply of oil for the whole of Europe. I think he was glad he wasn’t having to drive through the area at night. They were all higgledy piggledy.

Since this fleet hasn’t been involved in an instantaneous newsworthy event of any kind, there isn’t a story about it in the regular papers. However, I’ve found the following July 2009 letter in the Southwold Organ:

I read, with more than a little interest, the letter from the District Emergency Officer in response to local concern over the recent increase in the presence of oil tankers offshore. I first found out about the licensed ship-to-ship oil transfers about 18 months ago. This is a very serious issue, with potentially catastrophic implications for local tourism and the environment. I’ll come back to this later, but, first, I’d like to fill in some of the background and thereby take issue with some of Mike Topliss’ contentions.

Southwold is the only place in England where this activity occurs. The only other places in the UK are three Scottish locations associated with the oil industry. Oil-transportation companies tried to obtain licenses for three other locations: the Firth of Forth, Falmouth Bay and Lyme Bay. These applications encountered very strong local opposition and, in the case of the latter, it seems that STS activity has been suspended.

The reason for the oil transfers is that large tankers cannot get through to Russian oil terminals in the Baltic, so relatively small tankers (eg 60,000 tonnes) travel through into the North Sea and disgorge into supertankers, which then travel to the Far East. The type of oil is Russian Export Blend Crude, a Grade 4 very heavy and persistent product. Clearly, if ship-to-ship oil transfer was carried out in a much safer harbour/jetty situation, then the oil transporters would be liable for dues, which would impinge upon the £120-million revenue generated per trip (2005 prices). (See www.graypen.com for Southwold STS operators.)

Although Mr Topliss mentions ‘several ships’, I’m afraid that the reality is very different. It may look like a mere handful of vessels off Southwold beach, but, if you use binoculars, then the scene changes. The farther out you look, the bigger the supertankers are. On 5th May this year, I counted 18 tankers off Covehithe cliffs; today, 16th June, there were 17 visible from outside the Sailors’ Reading Room.

Then in August the same correspondent writes:

On 23rd June, there was a sharp reminder of the goings on just off shore from Southwold. Many people in the town were assailed by a sudden strong smell of gas and even in Reydon, almost three-quarters of a mile from the sea, a short-lived, but powerful odour swept through some parts of the village.

Left with a definite ‘scorched’ feeling on the back of the throat, we wondered if someone had dropped their bottle of the new Beckham fragrance, but a call to the Marine and Coastguard Agency at Yarmouth quickly confirmed the true nature of the waft. We were victims of methyl mercaptan, a chemical used to give the ‘gassy smell’ to natural gas, and where had it come from? Yes, you’ve guessed, the floating chemical complex sitting just off shore. It seems that a rise in temperature meant that the liquified natural gas (LNG) bulk carriers had to vent their tanks for safety reasons.

Lowestoft had suffered the day before, with hundreds of calls about gas leaks and the evacuation of some schools and offices. The chemical itself is reputedly safe, but the disruption to coastal life and the masking of genuine gas leaks is simply not acceptable.

So, it seems that Southwold is now a concentration zone for a floating toxic timebomb. Not only do we have the potentially catastrophic ship-to-ship transfer of oil occurring at unprecedented levels, but added to the cocktail are LNG carriers and, according to the Wall Street Journal, amongst other sources, very large crude carriers (300,000 tonnes plus) acting as floating storage tanks for up to eight months or more.

On 13th July, there was a new and different addition to the fleet of 25 or so tankers visible from Benacre Cliffs. Quite close to the shore sat a small tug. This suggests that there is now an awareness that severe weather, coupled with a loss of power, could lead to the beaching of any one or more of these tankers. Exactly how effective this ‘protection’ might be, or who is paying for it, remains a mystery.

There is clearly an unprecedented rise in very hazardous activity just off our coast, clearly within so-called ‘territorial waters’. The Marine and Coastguard Agency seems hamstrung by the lack of effective legislation to deal with this issue in anything other than reactive fashion; in other words, after a spillage has occurred.

Maybe I’m wrong about the newspaper thing. But I can’t log on to the Wall Street Journal and look up this story. But I wonder if these license applications to do dangerous shipping maneuvers are on-line anywhere and available for webscraping. Just another thing to look into.

And so, we got off, had a coffee, and caught the next train out of town. At least they weren’t on strike like they were on the way out when I had to get my sister to drive us from Cambridge to Harwich.

Another week, another long day in the office in Copenhagen being frog-marched through scallop bugs that I have quietly been ignoring over the past year. Who knows which ones are the most important. No time for blogging or anything like that. I’ll push back any plans for the scallop bisectors, which would be another feature that will merely bring in a whole lot of new bugs once people started using and depending on it. Maybe it’ll have to wait until another CAM system does it, and then there’s a reason to have it.

It’s a bit like the developments in the Adaptive Clearing, now being driven by what others are doing. I had a too-brief look at the Mastercam Dynamic Milling and got pointed out a couple of features that are liked in it which we don’t have. In particular, having different shapes for ramping down into a level, instead of always doing a helix. I think I can frig some algorithm to find an approximate bisector of a pocket for the purpose of zig-zag ramping. Here the average cut depth is half the step-down, but there is a spike in the load at the tool approaches the end of each the zig-zag swipe when the cutter is doing a full width full step-down cut — followed by no load as it goes back in the opposite direction. Maybe the dynamics of this are fine in practice because it has time to cool off. But that would suggest that there is an optimum length for the zig-zag, because if it’s too long then we would have a proportionately long period at the max load. Not that I know anything about real world machining. I’m just guessing.

Tomorrow we catch the ferry back from Esbjerg to Harwich, and then onwards. Hopefully the trains won’t be on strike this time.

Yesterday I was called upon to write a response to Celeritive Technologies’ new document circulating among potential customers, entitled “Volumill vs Adaptive Clearing”. This caused me to do a quick browse among the webpages, and I was pleased to see that the plaintiffs in the case Surfware, Inc. v. Celeritive Technologies, Inc. et al have been experimenting with video promotion of their technologies.

This is a good idea, because machining is a fundamentally time-motion affair, and motion pictures are a far better form for showing it off than crappy low-res bits of fuzz like you get on Delcam’s website.

But while video is the answer for conveying the superior programmed motions of a your toolpath algorithms on a machine, it’s not easy to get it right. It’s not like porn, where basically any old footage of the act in motion will be all right. Watching machine tools in action is unbearable after the first 30 seconds. Especially when you have to hear the noise as well.

Surfcam have uploaded some of their experiments onto youtube.

Here’s an example from last month of some perfectly nice music ruined by a continual grinding sawing sound.

This is a long one of theirs uploaded two months ago that ends with a lot of milky fluid being stirred around in a metal pocket underneath a veritable pillow of swarf.

This video, also from two months ago, has a narrator. This is a good idea because talking is an effective way of conveying information and causing the viewer to watch the whole film without dragging the slider and forwarding through it to the end just to check if something interesting actually happens. Unfortunately, the movie ends with a milky swarf explosion and a totally filthy pile of ground up metal. Not beautiful.

But this is most stylish one of them all, uploaded only 4 weeks ago. It’s just 10 seconds long, but that’s not what makes it great. It’s a clean slow motion capture with perfect lighting and no milkshake flying around. Beautiful. More like this please.

Eventually, there will come a day when some proper advertising talent gets involved and proper infomercials are produced, with a storylines, plots, characters and dialog…

The DynAptive TrueVoluCutMill Challenge

The scene opens with two guys, father and son, in their family toolshop.

The father has just got back from a training course on using DynAptive VoluTrueCutMill Technology. They get a job to cut out two bamiweenie bearing cases, one left and one right, for the spronk car that will be used in the new Bruce Lee movie.

Let’s have a race.

Zoom out to see famous TV sports commentator, with headphones a mic, in the foreground.

And they’re off.

“Remember, Mr Smith has only learnt to use this technology yesterday, so he’s a little slow on the uptake. Young Master Smith finishes his NC programming first, because he has been using his old-fashioned CAM system for years and knows how to cut corners. He is onto his machine early. He gets a good head start. Will this be enough to see off the more powerful DynaMill AptiveCutTrueVolu Technology?”

Grunge. Grind. Greech. Ping! goes the machine.

“Oh no, his tool has snapped! He’ll have to get another one for $30 dollars. This race is only about time, but if we counted cost it would make it more complicated. It’s every man for himself.

“Meanwhile, Mr Smith has finally started cutting his part after having to double-check the instructions. Wow! Look at that smooth side-milling motion, cutting the full depth of the cutter on the side.”

“Yes that’s right, the material removal rate is far greater than if it used the tip alone as he would with conventional non-TraAdaptive MillCutVoluDyna toolpaths. Look at that smooth sweep and transition! Can we have a slow-motion replay? Yes we can!

Bish bash, and we’re done.

Dad wins the prize. VolAptive MillTrueDynaCut Technology wins the day. Father and son share a well-earned refreshing banana milkshake.

MillAptive VoluCutDynaTrue Technology will pay back its worth in 6 weeks of daily orders. Buy yours today.

Remember terms and conditions apply. Always RTFM and verify the toolpath. Celery-Potato Systems is not responsible for any crashes, fatalities or gouges encountered in the use of this product.

To prove I can still do work, here’s for the machining category.

There are times when you need to encode the direction of a 2D vector. For example, the sequence of arc segments on the bottom rim of the cutter that are in material for the purposes of running the Adaptive Clearing algorithm.

These vector directions from the centre point to different points on the cutter need to be in angular order and analysed in relation to a reference direction.

Often when programmers see a problem to do with angles they use school mathematics and apply trigonometry and convert the direction into its representation in radians whose values they can then compare:

double RadianAngle(x, y)
{
    if (y > 0)
        return atan(x / y) + 1.5707963267948966;
    else if (y < 0)
        return atan(x / y) + 4.7123889803846897;
    else if (x > 0)
        return 0.0;
    else
        return 3.1415926535897931;
}

I really hate using radians. How can anyone justify a numbering system that cannot unambiguously represent the important perfect 90 degree right angle in floating point notation without needing to compare to pi/2 to epsilon accuracy all the time? But that’s another story.

The above function, which has the simple inverse (cos(a), sin(a)), has a lot of instability problems for small values of y that can be avoided by introducing more cases:

   if ((y > 0) && (y < x))
      return atan(y / x);
   else if ((y < 0) && (-y < x))
      return atan(y / x) + 6.2831853071795862;
   else if ((x < 0) && (x < fabs(y))
      return atan(y / x) + 3.1415926535897931

There is a standard C library function that encapsulates all of this mess into the single function atan2(x, y), which programmers may be happy to use because it hides all this complicated and slow calculation.

But I'm not happy with it because I don't like trigonometry and I need the speed. So I use the following function (subject to the special cases):

double DiamondAngle(x, y)
{
    if (y >= 0)
        return (x >= 0 ? y/(x+y) : 1-x/(-x+y));
    else
        return (x < 0 ? 2-y/(-x-y) : 3+x/(x-y));
}

The result ranges from 0 to 4 with right angles being integers. Note how the calculation requires a single division and some sums, and you get a number you can use to sort a list of vectors by their angles. The inverse function is:

   return P2((a < 2 ? 1-a : a-3),
               (a < 3 ? ((a > 1) ? 2-a : a) : a-4);

This doesn't result in a unit vector, so if you need it to be length 1 you need to normalize the result at the cost of 4 multiplications and one square root, which is still a lot better than any sine or cosine combined.

Check the calculation is correct for x,y>0:

    DiamondAngle(x,y) = y/(x+y)

which is between 0 and 1, so the inverse comes out as:

  InvDiamondArg(DiamondArg(x,y))
                = P2(1-y/(x+y), y/(x+y))

which is inline with (x,y) because both coordinates are positive and if we dot it with the perpendicular:

  Dot(P2(1-y/(x+y), y/(x+y)), P2(y,-x))
                = y - y^2/(x+y) - x y /(x+y)
                = (x y + y^2 - y^2 - x y) / (x+y)

we get zero.

I guess the reason this way of doing it is unpopular is that it looks more complicated.

But if you think about it as projecting the vector down to the piecewise linear diamond shape and then parametrizing by length, it's easy. There's a bit of mess to compress the calculations down and merge the different cases to shorten the code, but once it's there, you don't need to look at it again.

Next week: Encoding 3D angles using the Octohedron

While working on our new trouble-making website project The Straight Choice, I kept accidentally typing the DP Technologies’ Esprit CAM software’s slogan “The Right Choice”. They also like to add the plainly false statement:

The most powerful CAM software ever.

One distraction lead to another, and I was soon surfing their webpage and finding their recent customer spotlight PDF document: Trochoidal machining cuts narrow slots in hardened steel at 12x normal rates.

Let the record show that back in 2006 Martin and I were fruitlessly wandering around the Euromold trade fair in Frankfurt with our one page brochure of our amazing new cutting algorithm, attempting to sell it to various CAM companies who weren’t particularly keen, because they seemed totally happy with their own technology already thank you very much, not interested in anything new.

Chuck Mathews of DP Technology writes in the above article:

Cutting narrow pockets in hardened steel has long been one of the most difficult machining tasks…

Trochoidal machining provides a potential solution to this problem. The basic idea is to move the cutter around in a circular pattern with each circle advancing into the cut…

Conventional CNC programming software cannot generate a program to perform Trochoidal milling. In the past, the only way that it was possible to perform Trochoidal milling was for the programmer to manually code the very complex tool motions involved. This is a very challenging task and there is no way for the programmer to visually check the program without running it on a machine. For this reason, Trochoidal machining is currently used only very rarely…

DP Technology recently added a special routine for Trochoidal milling to ESPRIT Mold software. This routine greatly reduces the amount of time required to produce a CNC program for Trochoidal machining… The user simply defines the solid model of the part that will be cut… The user then selects “Trochoidal milling” and is prompted to enter the diameter of the circle and the advance per resolution. The software then generates the program for machining the part.

Bizarrely, for a four page article about a new type of toolpath, it includes no image of the toolpath in question.

Fortunately, the bottom of the article reports: “This story appeared in the October 2008 issue of Cutting Tool Engineering magazine”, so I was able to look it up and download the October 2008 CTE magazine and find it on p66:

It’s a bit fuzzy, pixelated, but you can see it looks simple-minded enough that it ought to have been a ground-breaking machining feature back in 1978, not something that the “most powerful CAM software ever” would be showing off to the world in 2008, two years after we’d been trying to earn an honest couple of bucks having created the full general purpose solution that rest-roughs and works on different levels with a minimum of configuration and no geometric limitations.

Whatever.

It’s specific, detailed narratives like this which prove to me that the so-called free market in innovation is a total myth. I cannot accept the usual excuse of: “you failed because you obviously weren’t any good at marketing”, because this is an entirely self-referential explanation that deduces our inadequacy from the fact that we failed, and therefore no further information is required.

Of course, you can believe this explanation if you want to, if you’re not interested in challenging the political dogma of our time, but the following observations ought to be important.

Firstly, people at all levels of the engineering industry (from customers to CAM software suppliers) appear to obtain their actionable knowledge from publications such as Cutting Tool Engineering, and not as a result of following their own intellectual curiosity. We’ve never received any questions inquiring about how the algorithm works or offering to collaborate with us on some very detailed cutting experimentation.

Secondly, the articles in magazines such as Cutting Tool Engineering are all written by openly self-interested employees of the companies who advertise, and no one seems to mind. We don’t have resources to buy this space, and anyway it’s not a game anyone should be playing.

What ought to exist are articles reviewing the (now about three) different trochoidal machining algorithms that are available in the market, with critiques from the different cutter makers describing the pros and cons of each approach, and the precise resulting characteristics.

But you don’t ever get that, because every article is by a trade industry man who says theirs is the most powerful CAM software ever (when it clearly isn’t), and spins a line as though nothing else has ever existed. What is the point? Why does there appear to be no hunger for actual information?

Working within this unbelievably defective information environment that defies rational explanation would be known as “good marketing”.

Anyways, since about half of that Cutting Tool Engineering magazine appears to about producing machinery whose sole design purpose is to massacre human beings at a distance, this issue hardly bears any importance.

Just to prove I’m doing a little bit of work on this, here’s what I get from scallop bisectors when I give a bisection angle of 5 degrees and a stepover (distance the bisector extends close to the previous scallop contour) of 20% of the stepover.

The little flower in the top left hand corner looks like this:

While in Matienzo I met someone who actually runs machine tools and cuts parts using CAM software of the kind I write.

He wants only smooth passes everywhere, so he’s not particularly excited by choss like this showing up as a result of running the algorithms — whereas I am.

I say:

“Look, it’s made all these amazingly wiggly contorted self-enclosing paths when I put in these inappropriate numbers — and it didn’t crash or hang!”

You can take for granted that the code is reliable. What makes it reliable is that it’s built to work in all these nasty knotted-up cases first, not just the smooth pretty ones. That’s my style. I find that if the worst case is taken care of, then the easy stuff follows without effort.

I’ve seen geometric coding approached from the other direction — do the easy stuff first, and try to generalize it to the harder cases. You get results faster, and can learn as you go along, but it’s not easy to argue that it’s going to fail. But it does, so there’s no need to argue about it now.

The machinist also told me that his customers wouldn’t allow him to use this scallop machining because it left marks at the sharp corners that couldn’t be polished out.

We couldn’t agree on whether these marks were from the rapid changes in direction, or the excess material that’s left there which would be removed by these scallop bisectors.

I guess some cutting trials are now necessary to prove this.

The scallop/constant stepover cutting strategy is theoretically capable of smoothly finishing irregular surfaces inside irregular boundaries (such as rest machining areas).

Unfortunately, it can result in very sharp corners in some of the offsets and — if you’re unlucky — can leave a double stepover gap in the final area of collapse where the narrowest width is slightly less than twice the stepover.

The fact that it’s one of the most technically challenging algorithms to make work (with regards to crashes, infinite loops, and ugly results) makes it easy to predict the deep reluctance of any programmer to do something more advanced with it.

It barely works under the ordinary specification (just giving the constant stepover offsets) after years of development, so you would be insane to intentionally make it more complicated, liable to be slower, and more likely to break.

And — secretly — the last thing you want to do with a difficult and unreliable algorithm is fix a flaw that everyone has gotten used to, which could make it more popular, so that more people run it on more and harder examples, so you get hundreds of fiendish bugs coming down the line next year. At some point a programmer has to move on, and the guys who take over don’t stand a chance.

Unfortunately, last week I thought of a sneaky way of combining pencil milling and constant scallop in order to insert bisecting curves into these collapsing contours. I had the option to do this, because the pencil and scallop strategies go through exactly the same cellular subdividing code in the HSMWorks kernel.

After three days of solid coding, I got the above result. There are a lot of reliability issues and huge complexities involved in joining up the cells. Not to mention how the linking is going to be programmed — which is hopefully someone else’s problem.

What to do now? There are a lot of advanced scallop bugs/deficiencies which would take reams of new code to solve properly. It’s difficult to justify doing this just for the bugs, but a brand new feature makes it worthwhile. It’s sometimes an advantage to allow problems to stack up.

What about all the other questions?

Well, if I didn’t think I had some sort of ownership stake in this code, I’d've kept quiet about this new idea, and nobody would know. The incentives for creativity do not occur out in the maladministered “free-market” between companies; the incentives — and disincentives — for creativity are actioned internally within each company, and depend on the relationships with their employees and their common morale. It can happen nowhere else.

Not that any of the economic experts seem to pay attention to this dynamic. They all work for universities and have no idea what it’s like to have all your intellectual credit stripped from you systematically by law. Lovely that, isn’t it? They think it’s your own fault for agreeing to be employed under the usual terms and conditions, neglecting to observe that no alternative is ever offered.

Free software is the only way forward.

Meanwhile, over at WorldCADaccess there’s a report of Solidworks and AutoCAD giving free crippled copies of their multi-thousand-dollar products to verifiably unemployed CAD workers, possibly because they’re worried talented people will spend their time working on free CAD software that could ultimately threaten the profitable stagnation of the industry.

The Society of Manufacturing Engineers (“Members consider the consequences of their work and societal issues pertinent to it”) ran the Westec 2009 trade show in Los Angeles, which finished on 2 April 2009.

Blogger Derek Goodwin visited the Mastercam booth there and reported:

I ran into Mike Macarthur, national sales manager for Robb Jack corporation and he showed me some incredible video on his iphone of 1/2″ diameter endmills cutting 1″ deep at 75 inches per minute in 6Al4V titanium, using Dynamic milling, he has promised to forward some links and a presentation, so look for this in a future article.

Now things are gearing up for the sister-show, Eastec 2009, in Springfield MA on 19 May 2009, and Mastercan’s has made its press kit available.

Their new “Dynamic milling” technique looks a lot like our old Adaptive Clearing strategy, which we invented in 2004.

Obviously, it can’t be the same code, or we would have seen some sort of a contract relating to it, got paid a tiny stipend for fixing on-going bugs, and so on. Still, those people at Mastercam have managed to produce a finished product without all the usual embarrassing intervening stages of half-baked flawed and buggy versions that you tend to get in this line of work. They must be much cleverer at programming than we are not to experience all the same set-backs and mistakes. I’d like to hear from them — the people who coded it; not the be-suited managers.

We, at Freesteel, are in eager to share the extremely limited CAM programming expertise there appears to be in the world, and we intend to lend support to any other programming team who is attempting to unnecessarily replicate our work, rather than follow the cheaper and more reliable option of buying the code from us. Programmers must have maximum freedom to pursue whatever apparently irrational course of development they feel is right because — who knows — they might actually be better than us at writing algorithms such as this. It’ll give us something to compete against. Otherwise we’ll get lazy and work on other things.

That’s why a couple of years ago we gave a DLL copy of the Adaptive Clearing algorithm to Delcam so they could bind it into their into the internal development versions of their products and better experiment against it while they were writing their own version.

Since they do not appear to have done this, it can only mean that Delcam don’t feel that this clearing algorithm adds any value to their products. Which is fine. It’s probably the attitude of most of the major CAM companies, most of whom won’t even go that far. Their recommendations of the worth of any strategy doesn’t only depend on whether or not they’ve got it, does it?

Without an organization of any kind representing the interests of users of CAM software, it’s impossible for the ordinary joe to see through the totally self-serving information that comes out of all corners of the business.

Still. It’s not as bad as the financial “industry”. It’s only software, not people’s livelihoods.

Here a snapshot of current development, showing two ways of machining fillets: For roughly horizontal fillets we machine “along” the valley following a spiral, for roughly vertical fillets we machine “across” the valley of the fillet, from side to side.