Category: CAM

Offset ellipse

Contacting a toroidal cutter (not shown) against an edge (cyan line), is equivalent to dropping down a cylindrical cutter (lower edge shown as yellow circle) against a cylinder (yellow tube) around the edge, with a radius equal to the tube-radius of the original toroidal cutter.

The plane of the tip of the cylindrical cutter slices through the yellow tube and produces an ellipse (inner green and red points). The way this example was rotated it is  obvious where the center of the ellipse along the Y-coordinate (along the green arrow) should lie. But the X-coordinate (along the red arrow) is unknown. One way of finding out is to realise that the center of the original toroidal cutter (white point) must lie on an offset-ellipse (outer green/red points). Once the X and Y coordinates are known it is fairly straightforward to find out the cutter-contact point between the cylindrical cutter and the tube, and from that the cutter-contact point between the toroid and the edge. Finally from that the cutter-location can be found.

Something to implement in opencamlib soon...

Spherical drop-cutter

For spherical cutters (a.k.a. ball-nose), the vertex-test (green dots), and the facet-test (blue dots), are fairly trivial. The edge-test (red-dots) is slightly more involved. Here, unlike before, I tried doing it without too many calls to "expensive" functions like sin(), cos() and sqrt(). The final result of taking the maximum of all tests is shown in the "all" image which shows cutter-locations colour-coded based on the type of cutter-contact.

The logical next step is the toroidal, or bull-nose cutter. Again the edge-test is the most difficult, and I never really understood where the geometry of the offset-ellipse shows up... anyone care to explain?

Drop-cutter Tux

After the kd-tree search is done, I've added an overlap-check which leaves only triangles with a bounding box intersecting the cutter's bounding box for the drop-cutter algorithm. It's seems like a band-aid kind of hack to get it working, I think if the tree-search would be bug free the overlap check would not be needed...

The HD-version of the video is much better, once youtube has finished processing.

Youtube vs. Vimeo

I've continued to translate into C++ the old cam-experiments I wrote in C#. The kd-tree search for which triangles lie under the cutter seems to work, and the best way to visualize what is going on is through a video. Trying Vimeo for a change, to see if it's any better than youtube for these CAD/CAM-visualizations, since they advertise HD.

There are 360 original frames captured from VTK, and the original was created with

mogrify -format jpg -quality 97 *.png

followed by (copy/pasted from some site google found for me...)

mencoder mf://*.jpg -mf fps=25:type=jpg  -aspect 16:9 -of lavf -ovc lavc -lavcopts aglobal=1:vglobal=1:coder=0:vcodec=mpeg4:vbitrate=4500 -vf scale=1280:720 -ofps 30000/1001 -o OUTPUT3.mp4

If anyone knows something better which produces nice results on youtube or vimeo, let me know.

The original is 1280x720 pixels, so it's better to jump out of the blog to watch the videos in native resolution.

Youtube: http://www.youtube.com/watch?v=k3uCpWYm174

Vimeo: http://vimeo.com/10215501

Drop-cutter toolpath algorithm development, part1 from anders wallin on Vimeo.

OK, so the video doesn't really show what is going on with the kd-tree search at all 🙂 . It only shows two toolpaths, one coloured in many colours which is calculated without the kd-tree, and another one (offset upwards for clarity) that is calculated, much faster, using the kd-tree.

Drop-cutter again

This is about my third rewrite of this fairly simple cam-algorithm where the cutter is dropped from above until it touches a triangle. It's now in C++ with Boost-python bindings and with visualization using vtk.

The cutter-location points are calculated by bringing the cutter into contact with the vertices of the triangle (green cl-points), the edges (red cl-points), and the facet (blue cl-points). Then the cl-point with the highest Z-value is selected as the final cutter location. At the white points we did not make contact with the triangle at all.

If you look closely enough, all surfaces in the world are made of triangles, even Tux:

Due to compression, the video might not show enough detail, so here's a screenshot:

frame059

I wonder if anyone is still interested in this stuff? Given enough time I would like to develop waterline-paths and an octree-based cutting simulator also. It would help if these algorithms were incorporated in a CAD-program, or someone would develop a GUI.

Learning VTK

I'm trying to learn how to render and animate things using VTK. This is the result of a python-script which outputs a series of PNG-frames. These are then converted to jpegs by this command:

mogrify -format jpg -quality 97 *.png

mogrify -format jpg -quality 97 *.png

and converted to a DIVX movie like this:
mencoder mf://*.jpg -mf fps=25:type=jpg -ovc lavc -lavcopts vcodec=mpeg4 -ac copy -o output.avi -ffourcc DX50

This should lead to the revival of my old Drop-Cutter code in the near future. This time it's going to be in C++, with Python bindings, and hopefully use OpenMP. Stay tuned.

Mowing video moved

Jumpcut is closing, so I needed to move this video to youtube. This relates to my earlier posts here
http://www.anderswallin.net/2007/12/mowing-tactics/
and here
http://www.anderswallin.net/2007/06/an-emergent-spiral/

When I find time to work on this next, there are many ideas for improvements: How to specify only climb/conventional milling (allowing only the right or left side of the cutter to be used). Using a variable step length for the simulation. Simulating dynamics of the macing (controlling the tool with a trajectory generator with acceleration/speed limits etc). How to implement rapid feed between cutting moves? how to choose among many allowed starting points for the cut? Should this use an adaptive resolution model, like a quad-tree? How should G-code be output, a filter which outputs G-code within a specified tolerance of the simulated path would probably be best?

Timing build_kdtree()

Drop-cutter requires a fast way of searching for triangles under the tool. A kd-tree (4-dimensional in this case) is suggested by Yau et al. I've tried to implement one here (look in trunk/Project2). Just ran some timing tests using Stopwatch() on it, and indeed the build_kdtree() function which takes a pile of triangles as input and generates a kd-tree seems to run in O(N*log(N)) time as it should.

I've never drawn this type of plot before, and I was surprised at how close N*log(N) is to N - in a loglog plot they are almost equal!

This is a recursive function. I wonder if there's a good way of multi-threading recursive functions? My laptop is dual-core and a modern desktop PCs is likely a quad-core - so let's try to write these things multi-threaded from the start.

Next up is a function for doing the orthogonal range-search for triangles that lie under the tool. That's supposed to run in O(N^(1-1/D)+K) time, where D is the dimension of the tree and K is the number of reported triangles - so O(N^(3/4)+K) in this case. I'll try to get that done during the weekend.