## One whole week of close-crossover misery

Sunday, November 26th, 2006 at 9:48 pm

I was going to do something useful this week, until I rashly tried some different examples on my scallop offset algorithm, and crashed it. I made an attempt to fix it quickly, and then spent two days further attempting to make the fix work until the whole thing collapsed completely with the entire function wrecked and infested with special cases that didn’t work.

I had to take the problem calculation out and to the front of the agorithm, and restructure it so that all the inconsistencies could be dealt with in advance.

The problem has to do with the way I calculate and model areas. A zprofile contour is an area, obviously, but so is a scallop toolpath — the toolpath is along the edge of the area, and with every stepover the area is shrunk.

Some implementations of these features use a tracking algorithm, where the cutter is tracked along the intended path which is at the boundary of some kind of volume.

A more robust method works out the area as it is embedded in some kind of a mesh, by considering perpendicular lines and finding the points where the lines enter and exit the area.

I’ve never found the right terminology for this type of algorithm, but it’s the basis of nearly everything I do.

I call the individual lines “fibres” and the mesh structure a “weave”. Suppose you print some kind of image on the weave; then when you unravel it the individual fibres simply have solid bits of colour that change at different points along their lengths.

To reverse the operation, all you have to do is write a function to calculate the positions of these bits of colour before you thread it all together.

This function can operate in parallel on multicore processors.

Unfortunately, there is one level of consistency which must hold, or the whole thing doesn’t work. It is that when two fibres cross they have to both have the same colour at the point of crossing.

If you are unlucky enough for your boundary to go exactly through such nodes, then the natural imprecision of the computer calculation of this point of change along the two different axes are likely to disagree. I’ve made an awful mess getting it dealt with properly.

As always, there is a quick fix that would have dealt with it in about five minutes rather than five days. The quick fix involves displacing all the fibres to the side by a distance such as 0.1274819302742mm, thus putting them in an In General Position, which means the likelihood of the boundary hitting one of these crossing points is reduced to less than one in a trillion.

Why didn’t I do it like that? I’ve done this type of quick fix before. Perhaps it’s the sense for this error, while I could take a good guess at its source, I couldn’t be sure that this accounted for it all. While this quick fix would have patched over this problem, it could have also been covering over some other problem I did not know about. As a result, I’d be getting slightly bad results in years to come and, since this algorithm is central to all that comes later, quite a lot of future code would have to make allowances for it.

I decided that since I was going to have to be responsible for thiscode for so many years to come, I’d better not take chances. Oh well. I had a cold anyway.

• 1. Neel replies at 27th November 2006, 12:40 pm :

Is it possible to view the mesh in camdemo.exe ? Is there any key that will display this mesh during toolpath display?
Also is it possible to select different strategies in camdemo.exe , eg : pencil , scallop , adaptive.
Is it possible to have a exe for constant scallop toolpath ?

Best of luck for Euromold .

• 2. Julian replies at 27th November 2006, 1:13 pm :

Later maybe. Are you able to cut with them, or do you just want to look?

There’s no UI for drawing the mesh. You saw the mess we made of the multicore processor settings. I get it by hacking the code.