PDA

View Full Version : Working on a new open source 3D CAM program



galacticroot
08-22-2007, 03:18 AM
Hi all, I mentioned something about this in the "ideas for an open source cam" thread, but I've started my fourth attempt at an open source CAM program. So far, I've got about 80 hours of work put into it. See the attached screen shots for an idea of the current state. Yes, I fixed the speed issue mentioned in the other post and got some form of G-code output working by the weekend :D .

I'm going to try to keep working on this until either it or another open source program becomes a usable 3D CAM tool.

MeshMill is the working name for it at the moment since that's what it does, although I may change it to something more creative avoid confusion with MeshCam.

Anyway, the planned features of version 1 will be:
-Load/save STL files
-Load/save G-code files
-Load/save cycle configuration
-Hierarchical cycle tree with "supercycles" for patterning, mirroring, etc... groups of cycles
-Milling simulation/3D backplot
-Toolpath optimization
-Large set of highly configurable machining cycles
-5 axis support through patterning of 3 axis cycles

It is written in Java, so it should work on Linux/Mac/Win/etc...

I am currently working on implementing tool size/shape compensation. I am not sure what algorithm would be best to use for this.

Another thing I'm not sure about is how to implement simulation/backplotting. I plan to have the stock material represented by a mesh and "virtually mill" the mesh away in an accurate way. To maintain a relatively high performance level, I know that I will probably have to dynamically subdivide and optimize the mesh.

Any thoughts on either of these problems?

Also, is there anyone here who would be interested in working on this? As I said, it is all Java.

WayneHill
08-23-2007, 01:53 AM
galacticroot,

Looks good.

twistedfuse
08-23-2007, 02:17 AM
galacticroot,

Always good to see someone who is willing to do something for everyone else. i second waynes comment. Looking great. We definately need a good free cam program to use as it is always the hardest to find to suit the needs. Keep up the good work and hopefully look forward to a proto version of MeshMill.

Daniel

galacticroot
08-23-2007, 03:26 AM
Well, I've applied for a Sourceforge project. The program will now be called "ThreeCAM". Assuming Sourceforge approves the project, I will make the source available there.

Development wise, I a lot of the day thinking about a way to handle the size/shape of the tool and haven't come up a good solution yet. In the meantime I added a really crappy way (inaccurate) of doing it. I made a variety of small improvements including support for tool tables.

Again, I will probably need some help with this. I am neither a professional programmer or mathematician and without help it would likely take years for me to develop this into a high end CAM package.

j_e_f_f_william
08-23-2007, 10:31 AM
Well, I've applied for a Sourceforge project. The program will now be called "ThreeCAM". Assuming Sourceforge approves the project, I will make the source available there.

Development wise, I a lot of the day thinking about a way to handle the size/shape of the tool and haven't come up a good solution yet. In the meantime I added a really crappy way (inaccurate) of doing it. I made a variety of small improvements including support for tool tables.

Again, I will probably need some help with this. I am neither a professional programmer or mathematician and without help it would likely take years for me to develop this into a high end CAM package.

Hello,

I might be interested in helping out. I say might as I am not sure how much time I will be able to spend on it (due to family, work etc). That said I program in Java for a living and am a solftware architech for a software company in the telecommunications area.

The Java 'gotcha' is that I do 99.8% of my Java codeing in the 'backend' side of things, EJBs, integrations, webservices etc and therefore little experience with the graphical side of things.

The CAM 'gotcha' is that I have no experience with CNC at the moment. I know no G code etc. I have a mill I am thinking of converting and a lathe as well so I am researching. I have come to the conclusion though that a free CAM program would make things easier as I model eveything in Alibre before manually machining so if I CNC a machine I would like to 'automate' the process as much as possible.

Have any 'design' written out or a plan? If you get others to help there will need to be some design and architecture by the brains of the project or it might get out of hand quickly. Then again that might just be my software architecture brain talking :)

PM me if you want to discuss more how I might be able to help or let us known once the project is publicly available.

TTYL, Jeff

galacticroot
08-24-2007, 02:03 AM
OK. I've got a basic web page up at http://www.threecam.com/. The SourceForge project page is at http://sourceforge.net/projects/threecam/.

The current code is available through subversion at threecam.svn.sourceforge.net/svnroot/threecam/ThreeCAM. I would recommend importing it in Eclipse using subclipse (http://subclipse.tigris.org/). It requires the Java3D library.

Normally, I would start a project like this by creating a detailed design specification, flowchart, etc..., but when I first started this I was mostly interested in seeing if it would work or not, so I just started coding with only a very general design in mind. I now need to retrofit a formal design to it and I haven't really decided on some of the specifics yet. I am very much open to suggestions.

The code is messy in some places, since I was trying out a variety of methods to do various things. I am working on cleaning it up.

harryn
08-24-2007, 02:54 PM
Hi, I wish I had the skills to help. Just curious, have you considered working with some existing open source CAM projects ? I have no idea which ones are "good" vs "ok", etc, but here is a link to one I have been watching.

http://gcam.js.cx/index.php/Main_Page

I know he is looking for help on his project. It would be really neat if you could help him get it into 4 axis capability.

Take care

Harry

rippersoft
08-24-2007, 04:40 PM
GalaticRoot:

I took your source and moved it into Enterprise Architect and ArgoUML. I am attaching a ZIP of both files.

If you go get ArgoUML version 0.24 and install and then open the project ThreeCam.zargo you can make you documentation. ArgoUML is Java based.

You can export to XMI and then import to Eclipse if you want. Or use Argo to do the UML.

Enterprise Architect offers a 30 day trial.

RipperSoftware

galacticroot
08-25-2007, 01:18 AM
rippersoft:
Hmm. I haven't ever done anything with UML before, only simple flowcharting, but it looks handy. I'll have to learn some more about it. I downloaded ArgoUML and am currently reading about UML.

I'm currently documenting the classes and methods in eclipse.

harryn:
I was actually thinking about GCAM earlier. I downloaded a copy and tried it out. I thought it would make a good compliment to a mesh based cam. I could see it becoming sort of a graphical parametric program generator. As for adding features to it, I'll have to look at the code sometime and see what I can do.

WayneHill
08-25-2007, 03:56 PM
Java Netbeans IDE interface is free.

http://www.netbeans.org/

It would be nice if everyone involved use the same development software for the project. If everyone starts going in their own preferred IDE, then it will be like herding cats.

Am I missing anything here? Does it matter what complier is used?

galacticroot
08-25-2007, 08:17 PM
I have currently have both JavaBeans and Eclipse, but I switched to using Eclipse a couple years ago.

It probably doesn't matter much which IDE is used. For Eclipse, there are a couple metadata files with Eclipse project information (which are only used when the project is initially imported), but Eclipse will work with any Java code. If the code is edited with another IDE, it will still work with Eclipse. The only problem I could see is variation in the comment syntax. For example, comments starting with "TODO" are treated specially in Eclipse, although this can be configured on a per-project basis to work with any tags. In the end, all you are doing is editing text files.

I could see the NetBeans GUI editor being problematic, but that is only a problem if it is actually used. I don't remember how it worked exactly, but I remember that it generated code blocks which could only be changed with the GUI editor.

The compiler is completely separate from the IDE. I have been using the Sun JDK 1.5. Other compilers can be used for development, but it might be best to create releases with the official Sun JDK.

Eclipse is open source and can be downloaded at:
http://www.eclipse.org/

WayneHill
08-26-2007, 12:51 AM
Which version of Ellipse are you using?

galacticroot
08-26-2007, 12:33 PM
Version 3.3.0.

WayneHill
08-26-2007, 01:50 PM
galacticroot,

I have Java Eclipse configured and running ThreeCam on WinXP !!
Woo Hooo :)

j_e_f_f_william
08-27-2007, 08:48 AM
Java Netbeans IDE interface is free.

http://www.netbeans.org/

It would be nice if everyone involved use the same development software for the project. If everyone starts going in their own preferred IDE, then it will be like herding cats.

Am I missing anything here? Does it matter what complier is used?

Hello,

I use NetBean for work at the moment and I have Eclipse now as well for this project. Both are free. I might try to create a project in NetBeans for ThreeCAM if I get a few extra cycles today.

That said I work at a dev shop and until recently I think the core team used NetBean, ViM, jEdit, Eclipse, ThinkPad and one guy was using an editor he wrote himself. So the IDE doesn't really matter as long as the strucutre is followed and the developer likes his setup.

BTW I have successfully run ThreeCAM with JDK 1.5 and 1.6 and with some ant files I think we can compile it etc without an IDE.

TTYL, Jeff

j_e_f_f_william
08-27-2007, 09:07 AM
Hello,

1. so to manage discussion on this project do you plan to continue to discuss it in this formum or will there be an e-mail based list or such? Thoughts?

1a. As I stated above I am used to doing backend non-graphical work and quite honestly I think if I get involved I would want to keep it that way as my GUIs are usually painful and ugly :) That gets to me to tookpaths etc...

2. Do you have an idea on the type of toolpath algorithm we want to have? I was wondering if it might be a nice thing to have a plugable system where you implement an interface and can write your own toolpath generators. I am guessing that any cam SW is only as good as it's toolpath determination.

2a. Related to that. I am still learning about CAM etc and I was wondering if someone could explain something. Is it normal for the CAM SW to take the object and your tool catalog and determine the best tool and path for the job? Or does the user usually specify the tools (endmills etc) to use the the toolpath is generated based on that?

The FreeSteel (http://www.freesteel.co.uk/html/faq.html) guys have some interesting comments on toolpath generation. I'm going to try to ping them and see what they say for pointers. You can also find some algorithm stuff at
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?List_Of_CAM_References

3. galacticroot: is there a way in the current code to define the 'block' that the object will be eventually cut from? I can run the program and I can even load some complex STL files exported from Alibre. I was playing around with toolpath ideas on the weekend on my whiteboard trying to figure out how the algorithms work and no matter what we need to start with the source material block.

BTW I like the Tool Library edit capability of VisualMill. I have been playing in their demo version.

TTYL, Jeff

WayneHill
08-27-2007, 12:01 PM
The programmer selects the tool according to the application.

j_e_f_f_william
08-27-2007, 05:29 PM
The programmer selects the tool according to the application.

Hello,

Oh good, as I was trying my damnest to figure out how the toolpath algorithms figure it out from the tool catalog of the system :) I could only come up with a repetitive trial and error approach.

Jeff

galacticroot
08-27-2007, 06:16 PM
-Forums/mailing lists: There is a forum for developers as part of the SourceForge project page. I can also set up mailing lists through SourceForge.

-Toolpath generation: Toolpaths are generated through the cycle classes. This is set up to allow for easy addition of new cycles, and plugins would certainly be a possibility.

Currently, there is only one toolpath algorithm and it is incomplete. It simply moves the tool to all X and Y points in a grid and sets the Z position at each point to the minimum height for which the tool will not intersect the object.

Calculating the minimum height is tricky. At the moment, it simply solves for the intersections between a series of five vertical lines (front, left, right, back, and center of the tool) and the mesh. This will ignore small triangles which lie inside the lines and is not sufficient.

I am working on a few other methods which would improve this. Currently, the most promising one uses a different algorithm for each tool shape, but should be fast. Here is a quick summary:

Square tool: There are four possibilities for the intersection between a square tool and a triangle:
1. It may not intersect if the triangle lies completely outside the tool's vertical profile. In this case, the triangle is ignored.
2. It may intersect at one point, along the corner of the tool.
3. It may intersect at an infinite number of points in a plane if, and only if, the triangle is perpendicular to the Z-axis.
4. It may intersect at an infinite number of points along a line if, and only if, the triangle is parallel to the Z axis.

Ball tool: There are three possibilities:
1. It may not intersect (same as above)
2. It may intersect at a single point on the ball surface, tangentially. The point of intersection can be found using the slope of the triangle as calculated from the dot product of the triangle's normal and the z axis.
3. It may intersect at an infinite number of points along a line (as above).

Cone tool: Five possibilities:
1. May not intersect.
2. May intersect at the tip of the tool if, any only if, the triangle's slope is less than the slope of the cone.
3. May intersect at along a line if the triangle's slope is equal to the slope of the cone.
4. May intersect at a point along the base of the cone if, and only if, the triangle's slope is greater than that of the cone.
5. May intersect along a line (as above)

The applicable case can be determined quickly and easily ahead of time. Each case is handled separately. The process is repeated for each triangle in the vicinity and the highest compensated Z value is taken (as in the current code).

The advantage of this algorithm is that it would be about as fast at the current one and work fairly well. The disadvantage is that the only way to work with odd tool shapes would be to combine primitive tool shapes and do multiple passes.

-Stock material: Yes, this will be a major part of the program. While it would be possible to simply specify the bounds of a rectangular prism, I think using a mesh for the stock material would integrate very well with the planned simulation and optimization features. It would be possible to add something temporary though.

-Tool selection: It would be possible to select tools automatically, but I'm not sure what, if any, benefit it would have over manual tool specification. One special case would be later on if feature recognition was implemented and the program could do things like select a correctly sized drill bit to make a hole. I do have some ideas for implementing automatic feature recognition, although it isn't a high priority.

BTW, Jeff, I sent you an E-Mail. Did you get it?

j_e_f_f_william
08-29-2007, 08:30 AM
Hello,

For those of you interested in using NetBean with this project I have attached a ZIP file with a nbproject directory and build.xml. UnZIP this in your ThreeCAM directory after getting it from SVN and it should work in NetBeans.

TTYL, Jeff

galacticroot
08-30-2007, 02:21 AM
Update: Currently I am working on developing an improved algorithm which takes the tool shape into account. There are some details I still haven't worked out and I've spent a lot of my free time this week working on another project.

I also realized there is another case to add to those in the previous post where an edge or vertex may touch the tool at an angle (I was thinking about planes before).

After tool compensation is working, the next thing would probably be to either:
1) Get all the current features working well.
2) Implement simple toolpath backplotting.
3) Add the next cycle (probably the common cycle which generates contour lines and makes a pocket cut on the empty side, I'm not sure if there is an official name for it).
4) Work on milling simulation/stock material functions.

WayneHill
08-31-2007, 12:47 PM
3) Add the next cycle (probably the common cycle which generates contour lines and makes a pocket cut on the empty side, I'm not sure if there is an official name for it).


http://www.cncmagazine.com/archive01/v2i05/v2i05g-CAM.htm

Pocketing – removes material from the inside of a boundary to create a cavity in the stock. Good 2D pocketing avoids islands within the pocket, and does not force the cutter into an area that is too small for it. Pocketing can be done in several different ways:
1. Zigzag pocketing moves the cutter back and forth across the cavity with the same step-over for each pass.
2. Spiral pocketing starts at the inside or outside of a pocket and spirals out or in until the stock is removed.
3. One-way pocketing creates a series of parallel passes in the same direction, allowing all cutting to be climb or conventional instead of a combination of the two.
4. Morph pocketing creates a spiral toolpath that gradually changes from an internal to external shape, keeping a constant load on the cutter.
5. Facing cleans material off the top of an area that may lie between depths, such as the top of an island.
6. Pocket re-machining identifies areas left uncut from a previous operation and cleans out those areas with a smaller cutter.

galacticroot
10-22-2007, 05:24 PM
This is just an update. I haven't really done a lot of work on this since the last post, since I currently have classes and the remaining free time I would normally spend working on it is going into another project. I will probably resume work on it sometime next year. In any case, I do plan to continue to work on it.

harryn
11-03-2007, 05:35 PM
Hi, I am still a new at this, but I am coming to realize the value of being able to machine parts in "layers" that can be assembled for larger "depth". (Think of trying to machine the car in the first post by starting at the radiator and moving to the back, 2 - 4 inches at a time.

Anyway, interesting start. I guess this is sort of like mesh cam ?

andy55
11-04-2007, 01:51 PM
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-monkey ;) can 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/drop-cutter-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/2007/02/one-tapered-tool-diagram-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/projects/pocket_off/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...)

Horsedorf
11-19-2007, 09:28 AM
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? :)