Hi all, just found this thread since I don't read cnczone that often. Mailing-list would definitely be better for me.
As someone else already pointed out the toolpath algorithms are the hard core part of this kind of project. Any code-monkeycan then do GUI, file-import, OpenGL views etc. (even CAD) around that...
For any open-source CAM work I would strongly suggest that the core algorithms are well documented. That means pictures, formulas, and text in addition to the code itself. There seems to be a number of projects going on, but none of them are really useful yet. Documentation will help porting good algorithms between systems as we find out which projects are going to survive in the long term.
For the 3D surfacing operation you have already been looking at (the car pic/toolpath screenshots) what you want is probably something called 'drop-cutter'. For each X,Y point you drop down the tool along the Z-axis until it hits the model. The model would be an STL representation so it consists of triangles. (any other parametric surfaces etc. need to be converted internally to STL representation before toolpath generation)
I've played around with this in C#, a blog post here:
http://www.anderswallin.net/2007/08/...utter-in-c-v2/
and the code is here:
http://code.google.com/p/monocam/
trying to stick to what I said above I've documented the idea and the algorithm in a series of posts here:
http://www.anderswallin.net/category/cnc/cam/
I've done it for flat, filleted, and ball-nose endmills. An extension would be to include tapered cutters also, but I haven't been using those personally and I don't know how useful that would be. A diagram of a tapered cutter on the freesteel blog:
http://www.freesteel.co.uk/wpblog/20...ram-coming-up/
(the freesteel blog is a good source of information. answers by email from the two guys are sporadic and not always helpful for a beginner - but hey these guys are pros who've been coding CAM for 10+ years, and they're trying to make a living...)
The drop-cutter algorithm is well-documented in the literature, I have a few pdf papers if anyone is interested.
my time is also very restricted so I haven't really had time to look at anything else besides drop-cutter. As mentioned on my page it still needs an algorithm that looks at the STL file and determines its 'silhouette' from above and then generates the zigzag pattern in the XY plane. Also a bucketing scheme or a kd-tree data-structure for speeding up the triangle tests is needed.
As mentioned in the post above creating 2D offset curves is probably a central algorithm that needs work next. I've been reading Martin Held's book (http://www.springerlink.com/content/h6k007p63577/) on this subject and the Voronoi diagram approach. There are a ton of algorithms for 2D offset of line/arc segments but the Voronoi approach seems to be well documented and robust.
http://www.cosy.sbg.ac.at/~held/proj...ff/pocket.html
Held's work is not open-source IIRC, but there must be open-source code for creating voronoi-diagrams that could serve as a starting point.
I will probably spend my (little) CAM-coding time on the 2D offset/voronoi thing for the next couple of months and see if I can generate robust offsets from multiply connected pockets with islands.
An even more simple task would be optimization of 1D/Drill paths. this is basically the traveling salesman problem, which would find use in other more advanced operations too (optimizing the order in which to machine multiple pockets etc.). Genetic algorithms and/or simulated annealing come to mind as useful approaches for this when N becomes large.
I'm a graduate student (in Physics) so I have good access to academic papers on computational geometry and toolpath generation. I have a ton of pdf's on this but you really have to search for the useful papers. If there's a wiki somewhere and I could get some help maybe it would make sense to catalog the papers a bit?
Finally on the subject of languages/platforms: any benchmarks out there comparing C#/NET/mono against Java? I am asking because I do think cross-platform (win/mac/linux) functionality is important, but that needs to be balanced against performance...
regards,
Anders W
(sorry for the long post, hope someone made it to the end...)
SOoooo.. linear algebra to the rescue. I've been giving some thought to toolpathing and the use of a system of defining tool shapes using vectors.. when you take a point in space and rotate it about it's center, it defines a volume. Once the volume is determined, the proximity fo this volume to another volume (the object being milled) can also be determined, and this used to determine an appropriate tool path. The reason I'm going in this particular direction is that it provides a generalized solution that can be solved with some matrix math.
Any one else thinking along these lines? Or should I just go crawl back into my shop and keep pondering?![]()