DXF Offset Pocketing loops

Some basic pocketing loops generated on the train today.

Using pycam's revise_directions() function it is possible to clean up the DXF data and classify polygons into pockets and islands.

There's a new parameter N_offsets

  • N_offsets=1 generates just a single offset at a specified offset-distance.
  • N_offsets=2... generates the specified number of offsets. Possibly with an increment in offset-distance that is not equal to the initial offset-distance. This happens e.g. when we want the final pass of the tool to be one cutter-radius from the input geometry but the material is difficult to machine and we want the "step-over" for interior offset-loops to be less than the cutter-radius.
  • N_offsets=-1 produces a complete interior pocketing path. Offsets are first generated at the initial offset distance and successive offsets are then generated at increasing offset distance until no offset-output is generated.

Todo: Nesting, Linking, Optimization.

There's no nesting among the loops here. The algorithm will have no clue in what order to machine the offset loops. A naive approach is to machine all loops at the maximum offset distance, then move one loop outwards, etc. But this is clearly not good as the tool would jump between the growing pockets during machining. Nesting information should be straightforward to extract from the voronoi diagram during offset-generation. The nested loops form a tree/graph, which we traverse in some suitable order to machine the entire pocket.

Also, there is no linking of these loops to eachother. For a machining toolpath one wants to link the offsets to each other so that the tool can be kept down in the material when we move from one offset loop to the next. A simple algorithm for linking should be straightforward, but I suspect something more involved is required to prevent overcutting with sufficiently complex input geometry.

When one has nested and linked offset paths, in general there still will remain "pen-up", "rapid traverse", "pen down" transitions. An asymmetric TSP solver could be run on this to minimize the rapid traverse distance (machining time).

Jakob halvmaraton

I ran my 5th and fastest yet half-marathon in 1h 41min 52s (4:49/km) yesterday in Jakobstad.

Splits and pace for 5ks: 23:47 (4:45/km) , 24:17 (4:51/km), 24:20 (4:52/km), 24:09 (4:50/km)
Splits and pace for 10ks: 48:04 (4:48/km) , 48:29 (4:51/km)

The first 5k was maybe slightly too fast, but the last kilometer from 20k to 21k was the fastest, 4:43, so that shows there was plenty of energy in the legs at the end.

McMillan's calculator says a 1:42 half-marathon means a 10k should be doable in 45:45, and the full marathon distance in 3:35!

I ran this event in 2010 also.

Here's a graph of the km-pace for the five half-marathons I've run:

Valio-Jukola

I ran the second stage of the Jukola relay around 1am to 4am on Saturday-Sunday night:

KU-rastit, Böleberget

Last orienteering practice before the Jukola relay. 5k course at Böleberget in Sipoo.

Slightly nervous right at the start on #1, OKish #2, then I probably unnecessarily avoided a green area that was marked slow on the map en route to #3.  Then mostly OK through #7. Going towards #8 there's an extra U-shaped bit which should have been straight. But then on the shortest leg of the course between #9 and #10 I somehow lost it and spent 8 minutes searching for #10. Probably frustrated by that I drifted too much down and right on the way to #11, almost stumbling on #12 instead.