OpenCAMLib
28 Apr 2010 13:06 #2731
by awallin
OpenCAMLib was created by awallin
I've been working for a while on a C++ library with python bindings for calculating toolpaths:
code.google.com/p/opencamlib/
anyone with an interest in open-source CAM, please take a look and comment on what you would like to see or work on.
thanks,
Anders
code.google.com/p/opencamlib/
anyone with an interest in open-source CAM, please take a look and comment on what you would like to see or work on.
thanks,
Anders
Please Log in or Create an account to join the conversation.
28 Apr 2010 15:49 #2735
by tenaja
Replied by tenaja on topic Re:OpenCAMLib
Let me know when you've achieved that "world domination" goal, and I'll be sure to try it out!
Please Log in or Create an account to join the conversation.
11 Jul 2010 11:01 #3328
by awallin
Replied by awallin on topic Re:OpenCAMLib
a status update on what has been going on lately.
The drop-cutter algorithm has been optmized a bit, and the Toroidal/Filleted endmill case, which is the hard one computationally, has been improved.
OpenCAMLib now supports cylindrical, spherical, toroidal, and conical tools. A CoumpoundCutter class can combine these shapes to produce e.g. an APT-style cutter (cone at the center, toroid in the middle, and then another cone).
There is a cutter.offsetCutter() function which returns an offset-cutter for producing stock-to-leave paths.
There is a simple CL-point filter which detects collinear points and removes them. This example shows the raw CL-points close to the surface and the filtered ones offset upwards:
www.anderswallin.net/wp-content/uploads/2010/07/line-filter.png
a good addition to this filter would be an algorithm that detects circular arcs for output as G2/G3 moves in G-code.
There is an experimental octree-based cutting simulation:
and
building the octree which represents the cutter-swept-volume for each G1 move at a reasonable resolution takes about 3s on my machine, so that is the bottleneck now. I have not looked at all at optimizing how the octree is rendered (now all faces of all cubes are rendered, which is slow).
If these problems can be overcome this can be the basis for a very general cutting simulator. 4/5-axis, undercuts, lathe-ops, and arbitrary cutter shapes are in principle possible.
I would like to work on waterline or z-slice toolpaths next, similar to this picture:
www.grzsoftware.com/nimage/waterline.png
This will again be based on a triangulated surface and "sampling" or calculation of a number of valid cutter-locations which then are linked together into a toolpath.
Anders
The drop-cutter algorithm has been optmized a bit, and the Toroidal/Filleted endmill case, which is the hard one computationally, has been improved.
OpenCAMLib now supports cylindrical, spherical, toroidal, and conical tools. A CoumpoundCutter class can combine these shapes to produce e.g. an APT-style cutter (cone at the center, toroid in the middle, and then another cone).
There is a cutter.offsetCutter() function which returns an offset-cutter for producing stock-to-leave paths.
There is a simple CL-point filter which detects collinear points and removes them. This example shows the raw CL-points close to the surface and the filtered ones offset upwards:
www.anderswallin.net/wp-content/uploads/2010/07/line-filter.png
a good addition to this filter would be an algorithm that detects circular arcs for output as G2/G3 moves in G-code.
There is an experimental octree-based cutting simulation:
and
building the octree which represents the cutter-swept-volume for each G1 move at a reasonable resolution takes about 3s on my machine, so that is the bottleneck now. I have not looked at all at optimizing how the octree is rendered (now all faces of all cubes are rendered, which is slow).
If these problems can be overcome this can be the basis for a very general cutting simulator. 4/5-axis, undercuts, lathe-ops, and arbitrary cutter shapes are in principle possible.
I would like to work on waterline or z-slice toolpaths next, similar to this picture:
www.grzsoftware.com/nimage/waterline.png
This will again be based on a triangulated surface and "sampling" or calculation of a number of valid cutter-locations which then are linked together into a toolpath.
Anders
Please Log in or Create an account to join the conversation.
- Dan Falck
- Visitor
11 Jul 2010 13:00 - 11 Jul 2010 13:03 #3329
by Dan Falck
Replied by Dan Falck on topic Re:OpenCAMLib
Anders,
Thank you so much for doing this. I've been using the HeeksCNC implemented version of your software and I am very impressed.
Dan Heeks also set up the 'Attach' machining operation to your libs and now we have some really interesting options for machining surfaces and machining on surfaces.
Thanks,
Dan
Thank you so much for doing this. I've been using the HeeksCNC implemented version of your software and I am very impressed.
Dan Heeks also set up the 'Attach' machining operation to your libs and now we have some really interesting options for machining surfaces and machining on surfaces.
Thanks,
Dan
Last edit: 11 Jul 2010 13:03 by Dan Falck.
Please Log in or Create an account to join the conversation.
12 Jul 2010 07:10 #3335
by awallin
Replied by awallin on topic Re:OpenCAMLib
Hi Dan F,
It's nice to see that someone actually uses OCL. The foam spider on your blog may have been the very first part anyone has ever cut with this code!
Once the basic routines for cutter-location (drop-cutter which is done, and push-cutter which I am working on slowly) are done, as well as offsetting and a few other things are in place I think there is potential for a lot of different things. For hacking, the closer you can go and take a peek at the low-level functions in the python-code the better.
I've really only been visualizing things with VTK so far, but as heeksCNC improves I might switch to developing OCL under it.
Ofcourse OCL is not tied to HeeksCNC and anyone could come up with another GUI if they wanted (Coin3D, VTK, etc. etc.)
I am very slowly working on a lathe project, and if/when that machine starts making chips later this year then I will take a look at 2D lathe operations. These should not be so different from the 2D offset or waterline ideas/algorithms which are needed for 3-axis milling anyway.
Anders
It's nice to see that someone actually uses OCL. The foam spider on your blog may have been the very first part anyone has ever cut with this code!
Once the basic routines for cutter-location (drop-cutter which is done, and push-cutter which I am working on slowly) are done, as well as offsetting and a few other things are in place I think there is potential for a lot of different things. For hacking, the closer you can go and take a peek at the low-level functions in the python-code the better.
I've really only been visualizing things with VTK so far, but as heeksCNC improves I might switch to developing OCL under it.
Ofcourse OCL is not tied to HeeksCNC and anyone could come up with another GUI if they wanted (Coin3D, VTK, etc. etc.)
I am very slowly working on a lathe project, and if/when that machine starts making chips later this year then I will take a look at 2D lathe operations. These should not be so different from the 2D offset or waterline ideas/algorithms which are needed for 3-axis milling anyway.
Anders
Please Log in or Create an account to join the conversation.
- Dan Falck
- Visitor
13 Jul 2010 01:36 #3341
by Dan Falck
Replied by Dan Falck on topic Re:OpenCAMLib
Hi Anders,
I think it was Brad (sliptonic on IRC) that did the spider. He's got a cnc router set up for doing a lot of fun wood projects for his family and friends. That's one of the things that I love about this sort of thing- you can amaze your family and friends with awesome work.
I see your code unleashing a wave of creativity that hasn't been seen before in the open source cadcam world. I know that it could be used for all sorts of things- guitar parts, surfboards, jewelry...
I especially like the fact that you and Dan Heeks are working together on this. Dan's 'Attach' machining operation is especially powerful in combination with your code.
Thanks for all the hard work with this.
Dan
I think it was Brad (sliptonic on IRC) that did the spider. He's got a cnc router set up for doing a lot of fun wood projects for his family and friends. That's one of the things that I love about this sort of thing- you can amaze your family and friends with awesome work.
I see your code unleashing a wave of creativity that hasn't been seen before in the open source cadcam world. I know that it could be used for all sorts of things- guitar parts, surfboards, jewelry...
I especially like the fact that you and Dan Heeks are working together on this. Dan's 'Attach' machining operation is especially powerful in combination with your code.
Thanks for all the hard work with this.
Dan
Please Log in or Create an account to join the conversation.
14 Jul 2010 09:44 #3352
by awallin
Replied by awallin on topic Re:OpenCAMLib
I have made some experiments with creating waterline-toolpaths today. The pictures only show one triangle, but extending this to STL-models with many triangles is not far away.
www.anderswallin.net/2010/07/waterline-toolpath-experiment/
www.anderswallin.net/2010/07/waterline-toolpath-experiment/
Please Log in or Create an account to join the conversation.
28 Dec 2022 10:18 #260458
by dset
Replied by dset on topic OpenCAMLib not compiling
Hi all, I'm trying compiling opencamlib on linux and I'm following the passages described in when I start last command to install the following error appears:
can someone help me?
git clone https://github.com/aewallin/opencamlib
cd opencamlib
mkdir build
cd build
cmake .. -D CXX_LIB="ON"
make . # try make -j4 for a faster build if you have a multi-core machine
make install .
make: *** No rule to make target 'install'. Stop.
can someone help me?
Please Log in or Create an account to join the conversation.
Moderators: Dan Falck, Skullworks
Time to create page: 0.077 seconds