510,073 active members
3,242 visitors online
Register for free
IndustryArena Forum > OpenSource CNC Design Center > OpenSource Software > Any ideas for open source CAM package?
Page 1 of 3 123
Results 1 to 12 of 27
  1. #1
    Join Date
    Nov 2004

    Any ideas for open source CAM package?

    I'm currently writing a CAM package in Perl. It is primarily designed for my own use for engraving jobs, mold making, and occasional milling of parts.

    It will have the ability to generate G-Code for various kinds of 2D and 3D engraving, store art in a database, and manage orders/jobs. It will also have the ability to generate G-code for lengthy operations like pocket cutting.

    So far, I have a few modules written, and it is able to turn paths in SVG into G-code for 2D engraving. I plan to add support for SVG Text elements too. 3D depth maps and engraving multiple items in one job are also on the to-do list. The frontend is as of yet undecided, but will probably be either console or CGI based. The program will run on *nix.

    Eventually, I may add support for machining 3D meshes, 3D part previews, and time estimates.

    Since there seems to be a huge shortage of open source CAM software and the prices for commercial software are insane, I am planning to release it under the GPL for other people to use, so I want to get some other ideas for features to add. Currently, I am only including support for features I actually use. I only use paths and text in SVG, so other shapes would not be supported. DXF is also not supported, since I use the Sodipodi SVG editor for tracing.

    However, I may add other features if it would be useful to other people and isn't too difficult to do.

    So, what features would you like to see in an open source CAM program?

  2. #2
    Join Date
    Jun 2005
    Hi galacticroot!

    I've just registered so... where are you at right now on this project?

    I use a 3 axis router and I've been wondering about such an open source CAM (CAD/CAM package) into which I could get involved (and benefit to be honest).

    I would have some suggestions if your still interested (and MUCH MORE later...). I find this to be a VERY interesting project... keep me informed.

    My business Web site - USINUM - www.cooptel.qc.ca/~usinum
    My BLOG at Blogger - http://pacosarea.blogspot.com/

  3. #3
    Moderator ynneb's Avatar
    Join Date
    Feb 2004
    So, what features would you like to see in an open source CAM program?
    All the features found on professional CAm programs. Please.

    Did you mean to say it will be written for Linux? Thats a bummer. Why?

    I know nothing about writing programs but I would guess if you got the 2d part done first you could add features as you go.
    Can I suggest you post lots of versions as you go and we can test them and make recomendation about new features. Sort of like editing as you go.
    Being outside the square !!!

  4. #4
    Join Date
    Nov 2004
    the_paco, yeah, you can help with it if you want. I'm not sure how far I'll get with it though. I don't have a lot of time to work on it.

    ynneb, it is written for Linux mostly because that's what EMC runs on and it is the most popular for open source software. However, it should also run on anything with a Unix-like environment and Perl, including MacOSX and Windows with Cygwin, although I don't have those to test it on.

    So far, it is a fairly useful program for engraving with SVG paths. I'm probably going to add text support next.

    I've decided to use a frontend/backend setup for this program. It won't have any built in user interface and will be just a processor. The interface will be provided by a seperate program. This increases the flexibility of it tremendously.

    Here is a gallery of the engravings I have done with it so far on my MaxNC10:

    A couple earlier ones had some errors. Several have lines that don't quite connect because the program was skipping the first segment of each line. The predator has a line that shouldn't be there because of a problem in handling broken paths(ignoring the break). Both problems have now been fixed.

    Here is a chart showing the planned processing steps:

    If I can find documentation about LWO, DXF, etc... file formats, those would be nice to import too, but I haven't been able to find enough information to write a parser in Perl.

    I have the SVG file input done, and the path processor complete enough to be useful. The Frontend, 2D plotter, and post processor functions are currently provided by a temporary test program that works, but is very limited.

    The job assembler is something that I haven't seen very often in other CAM software. It combines multiple programs and handles offsets for making multiple items out of a single piece of material.

    The process macro has the same function as a user interface, except with less interactivity. It is user written and would describe the overall process and required features.

    The feature macros describe machining operations. They are used to generate lengthy operations, like pocket cuts, with a single command.

    The macros and templates should allow this to be very versatile and work on all sorts of machine setups.

    The job/process assembler is a module that would allow almost fully automated mass production of parts when combined with an appropriate process macro. It could be used to cut out many sheet metal parts on a laser cutter and place each in a container with a pick and place manipulator. I haven't seen this in many CAM packages, and I haven't decided on the details of it yet. It might be better to have this as a seperate and more powerful program.

    Here is the perl code for the SVG module. It supports paths with the M,L,C, and z commands so far(which is what I usually get with SodiPodi). These are translated into line segments and move to commands. The data structure it produces needs some reworking. Also, the XML::Parser tree output handling needs to be rewritten. It only looks for paths on one level. There are other things that should be done better but don't really cause any serious problems.

    Here is parser/svg.pm in its current state.
    #SVG parser and processor
    package parser::svg;
    use XML::Parser;
    sub new {
        my $self = {};
        bless $self;
        return $self;
    #Parse an XML SVG file
    sub parsefile {
        my $self = shift if @_;
        my $fname = shift if @_;
        my $parser = new XML::Parser(Style => 'Tree');
        $self->{svgtree} = $parser->parsefile($fname);
        return 1;
    #Extract path coord lists
    sub extractpathcoords {
        my $self = shift if @_;
        my @coordlists;
        #Search through the tree
        while(my $attrib = shift(@{@{$self->{svgtree}}[1]})) {
            if($attrib eq 'path') {
                print "path\n";
                my $params = shift(@{@{$self->{svgtree}}[1]});
                my $pathdata = @{$params}[0]->{d};
                print "DATA: $pathdata \n";
                my $coordlist = $self->plotpath($pathdata,.05);
        return \@coordlists;
    #Handle plotting of SVG paths
    sub plotpath {
        my $self = shift if @_;
        my $data = shift if @_;
        my $curvestep = .1;
        $curvestep = shift if @_;
        my @commands = split(/ /,$data);
        my $points = {};
        my @coordlist;
        while(my $command = shift(@commands)) {
    	if($command eq 'M') { #Moveto
    	    my $x = shift(@commands);
    	    my $y = shift(@commands);
    	    $points->{current} = [$x,$y];
    	    $points->{start} = [$x,$y] unless defined $points->{start};
    	    push (@coordlist,["M",$x,$y]);
            } elsif($command eq 'L') { #Line to
                my $x = shift(@commands);
                my $y = shift(@commands);
                $points->{current} = [$x,$y];
                $points->{start} = [$x,$y] unless defined $points->{start};
    	} elsif($command eq 'z') { #Return to start
    	    $points->{current} = $points->{start};
                my @point = ("L",@{$points->{start}});
    	    push (@coordlist,\@point);
    	} elsif($command eq 'C') { #Cubic bezier curve, absolute
    	    my $x0 = @{$points->{current}}[0];
    	    my $y0 = @{$points->{current}}[1];
    	    my $x1 = shift(@commands);
    	    my $y1 = shift(@commands);
    	    my $x2 = shift(@commands);
    	    my $y2 = shift(@commands);
    	    my $x3 = shift(@commands);
    	    my $y3 = shift(@commands);
    	    print "CBCurve:$x0,$y0,$x1,$y1,$x2,$y2,$x3,$y3\n";
    	    my @newcoords = $self->plotbeziercubic($x0,$y0,$x1,$y1,$x2,$y2,$x3,$y3,$curvestep);
    	    $points->{current} = [@{$newcoords[scalar(@newcoords)-1]}[1],@{$newcoords[scalar(@newcoords)-1]}[2]];
    	} else {
                die "ERROR: Unknown command \"$command\" in path.\n";
        return \@coordlist;
    #Plot a cubic bezier curve
    sub plotbeziercubic {
        my $self = shift if @_;
        my $x0 = shift if @_;
        my $y0 = shift if @_;
        my $x1 = shift if @_;
        my $y1 = shift if @_;
        my $x2 = shift if @_;
        my $y2 = shift if @_;
        my $x3 = shift if @_;
        my $y3 = shift if @_;
        my $step = shift if @_;
        my $cx = (3*$x1) - (3*$x0);
        my $bx = (3*$x2) - (3*$x1) - $cx;
        my $ax = $x3 - $x0 - $cx - $bx;
        my $cy = (3*$y1) - (3*$y0);
        my $by = (3*$y2) - (3*$y1) - $cy;
        my $ay = $y3 - $y0 - $cy - $by;
        #Compute coordinates
        my $t = 0;
        my @coordlist;
        while($t <= 1) {
    	my $x = ($ax*($t**3))+($bx*($t**2))+($cx*$t)+$x0;
    	my $y = ($ay*($t**3))+($by*($t**2))+($cy*$t)+$y0;
    	$t += $step;
        return @coordlist;
    This is the small test program I mentioned. It generates G-code with the above module:

    #!/usr/bin/perl -w
    use parser::svg;
    my $svg = new parser::svg;
    $svg->parsefile('something.svg'); #Process this file
    my $coordlistsref = $svg->extractpathcoords();
    #Generate G-Code
    my @gcode;
    my $d0 = "0";
    my $d1 = "-.1";
    my $feed = "20";
    my $sfactor = ".011"; #Coords are mult by this to convert to inches
    my $maxx=0;
    my $maxy=0;
    my $retract = 0;
    my $lcounter = 0;
    foreach my $coordlist (@{$coordlistsref}) {
        if(@{$coordlist}[1]) {
            #Begin cut profile
            while(my $coord = shift(@{$coordlist})) {
                my $mode = shift(@{$coord});
                if($mode eq 'M') { #Go to
                    if(!$retract) { #Ignore if already retracted
                        print "LINE:  $lcounter RETRACT to $d0\n";
                        push(@gcode,"N" . $lcounter . "G00Z" . $d0); #Retract blade
                        $lcounter += 1;
                        $retract = 1; #Retracted
                    my $x = smult(@{$coord}[0],$sfactor);
                    $maxx = $x if $x > $maxx;
                    my $y = smult(@{$coord}[1],$sfactor);
                    $maxy = $y if $y > $maxy;
                    print "LINE: $lcounter RAPID to $x,$y\n";
                    push(@gcode,"N" . $lcounter . "G00X" . $x . "Y" . $y); #Go to coord
                    $lcounter += 1;
                    print TESTFILE "M $x $y ";
                } elsif($mode eq 'L') { #Cut a line
                    if($retract) { #Insert blade if retracted
                        print "LINE: $lcounter INSERT to $d1\n";
                        push(@gcode,"N" . $lcounter . "G01Z" . $d1 . "F" . $feed);
                        $lcounter += 1;
                        $retract = 0; #Inserted
                    my $x = smult(@{$coord}[0],$sfactor);
                    $maxx = $x if $x > $maxx;
                    my $y = smult(@{$coord}[1],$sfactor);
                    $maxy = $y if $y > $maxy;
                    print "LINE: $lcounter CUT to $x,$y\n";
                    push(@gcode,"N" . $lcounter . "G01X" . $x . "Y" . $y . "F" . $feed);
                    $lcounter += 1;
                    print TESTFILE "L $x $y ";      
                } else {
                    die "ERROR, unknown mode.\n";
            print "LINE: $lcounter RETRACT to $d0\n";
            push(@gcode,"N" . $lcounter . "G00Z" . $d0); #Retract blade
            $lcounter += 1;
        } else {
            print "NOTICE: Blank path detected.  Omitting.\n";
    #Write Gcode
    foreach my $line (@gcode) {
        print GCODE $line . "\n";
    print "Max X: $maxx\nMax Y: $maxy\n";
    sub smult {
        my $one = shift;
        my $two = shift;
        if($one && $two) {
            return $one*$two;
        } else {
            return 0;
    This code works with plain SVG code produced by SodiPodi on Linux as long as all points are corners. It hasn't been tested with other editors. The $sfactor is used to convert the internal SVG coordinated into inches for the CNC machine. It isn't quite .011, but that worked for me. It will tell you the highest X and Y values seen when it processes a file, so you can use those to adjust it a bit. The variables above it are for configuration of feed and depths. The ones below it initialize those counters to 0, so don't change them.

    You should probably use a g-code preview program to make sure there aren't any errors before making anything with it.

  5. #5
    Join Date
    Jun 2005
    Hey galacticroot!

    I must confess first that I'm currently LEARNING C... but I still wish to get involved into a similar project. I too don't have a full time schedule to allow... but good thing do take a moment! Maybe "we" could get more people involved too; I have a couple of friends that I thinking of...

    So what would be a "start"?...

    I primarly use Windoze since most of the CAD/CAM (and other softwares) that I use run on it... could I try/test your program ?

    Can this be usefull to you:



    Tell us more... :wave:

    PS: WOW!!! I did'nt thought you were already carving 3D out of latex(http://ldwp.com/hosted/CNC/Acrylic%2...iette.jpg.html)?!?!?
    My business Web site - USINUM - www.cooptel.qc.ca/~usinum
    My BLOG at Blogger - http://pacosarea.blogspot.com/

  6. #6
    Join Date
    Aug 2004
    can we beta it?

  7. #7
    Join Date
    Nov 2004
    I spent a few hours working on it today. It still does the same thing, but the postprocessor is now template driven.

    I must confess first that I'm currently LEARNING C... but I still wish to get involved into a similar project.
    It is written in Perl, not C, since that is what I know best. I could port the code to Python or C, although I would have to change the name to something other than PerlCAM.

    WOW!!! I did'nt thought you were already carving 3D out of latex
    LOL. I traced that in SodiPodi for the acrylic panel.

    Anyways, I've attached the current code as a zip file. You should be able to run it on Windows if you install Cygwin and run it in that. To change the cutting depth, you can edit the templates. The default is -0.1.

    It includes a test SVG file that should work.

    I have not yet tested this version on my CNC machine, so I'm not sure if the g-code output is correct or not. I'll probably test it later today. I haven't found any good CNC backplotters that work with Linux yet, so testing takes a while.

    The easiest way to engrave something with it and SodiPodi is to load the original drawing or photo in SodiPodi, trace it with the freehand draw tool, and use the node edit tool to fit the curve better. .20 was a good line size for this. As long as all the nodes are either straight lines or cornered bezier curves, it should work. Smooth curves aren't supported in the parser yet, but the cornered ones do everything they do and more.

    Also, the output will be mirrored from the SVG file, since the origins are different(top left vs bottom left). You can mirror the drawing in the SVG editor to fix this. I'll add a mirror translation option in the program later.
    Attached Files Attached Files

  8. #8
    Join Date
    Nov 2004
    Quote Originally Posted by ynneb
    All the features found on professional CAm programs. Please.
    I think I am going to start with a controversy, but I do not think that loosely defined "professional" CAM programs need most of the features they have. It is amazing, but they also lack almost all of he features that they need.

    Wife studied MasterCAM. This was where my Quest for The Perfect CAM begun. I have almost 20 years of software experience, but my entire non-autodidactical part of education is entirely in physics. Toss in the thing that my father was an engineer, often working at home, so I drafted 3D parts at 9. And — most fortunately! — I have never seen a CAM program till then.

    Now I was seeing did not match my idea of a software made in 2001 (maybe it was 2002). I saw a piece of software made in the late 70s. Carefully ported from DOS to Windows 3.1, preserving all peculiarities of DOS. Then ported to Win32 — it is simply unbelievable — I do not think that I know how to do that in Windows, not that I ever needed that, of course — instead of sitting still and waiting for a keyboard or mouse stroke etc, like all Windows programs do, the thing polls for user's input in a tight loop, eating 100% of the CPU while idling!!!. This is what DOS programs do —but that was long before 3.2 GHz CPUs consuming 130W at full load! 8086 did not change its temperature with load; it was 10 C above ambient without a heatsink and a fan at all times.

    She thought the notebook was broken — it became very hot, ran fans at full RPM and ate the battery in 40 minutes! I taught her to quickly press any keystroke that brought up any Windows-style dialogs when she needed to turn to a book — the program pauses its endless loop while in a dialog. Over 1 hour on a battery! Next thing I bought a second battery for her laptop. Oh well.

    But most amazing was that the program did not do anything I expected from a CAM program at all. Remember, I have never worked with any of them.

    Here is how I think a CAM algorithm should work. The task is rather well formalizeable, albeit extensive. I give it models of a blank and of a finished part. I define both machine kinematics (how fast and how far the tool can move? tolerances on motion, backlash and squareness) and dynamics (spindle power; feed power and perhaps its change over speed; rigidity of different parts of the machine). I define geometry and precision of tools. I define properties of part's material.

    Ok, in this task I even decide how to fix the blank. I supply fixture models. I also specify tolerances of dimensions and roughness of surfaces (mom, tell me, if STEP that much better than IGES, why then hardly anyone prefers it in practice?)

    So far so good. Many CAM programs make use of this data. But this is not the best use. The problem, as I see it, is that this data is principally complete to compute tool path for removing material that can be removed from the blank on its way to the finished part, while no program is even close to that; what they do is alllow me to stage virtual experiments.

    I want to digress here to explain how a small design twist can turn into a gross bogosity. I came to a web site where I had an account to fetch some range of past transactions. I went to the history page, and there were controls for beginnig and ending dates of the range I want to fetch. There was also a notice that only the last 90 days of activity were available. It was roughly the time when that transaction I was looking for must have occured, so I decided to fetch all transactions.

    It's worth noting that the Web application was designed fairly good, so least of all things I expected the blow it dealt me. When I entered dates from January,1 to some mid-May, a then-today, the program gave me an "input error" notice that the date span was greater than 90 days. Damn, but I needed all 90 days! I approximated the start date 90 days in the past and tried it. No dice, still greater than 90 days. Next day - still too far in the past. Next trial.... The 5th or 6th one returned the records. I solved their quiz!

    So what essentially has happened? The program, instead of making computations for me, confronted me, in its best area which is also my worst - computational abilities. I did not have any chances from the very beginning!

    Now, with a CAM program, I feel myself exactly in the same weird postiton. While posessing all data to crank out an answer which is close to the best possible, it lets me play with parameters and see how good my random exercises are! What is faster here - a spiral or a lacing movement? Let's try... Can I still cut this with Z-planes spaced at 6mm? Hmm...

    Do you know any reason behind "constant-Z roughing???" There is absolutely nothing in geometry or physics of cutting that makes the plane z=const special in any way. There are actually 2 weak statements that could attempt to explain why this mode is in every CAM program, the first being "This is what you do on a manual mill", and the second "program's designers could not grok 3D geometry sufficiently well. It is simpler for them to write software this way", but they are obviously too weak to prefer this particular mode of cutting to any other one.

    The task of time-optimized roughing, for example, is very simple to state: remove as much of excess material as circumstances allow: say, machine and part strength if process time is the only criterion, or fixed cutter load if optimizing for tool life etc, observing also geometrical constrains, i.e. not cutting fixtures and the table. The solution to this task is, however, computationally intensive. While on local scale, motion computation is quite easy, the overall "strategy" of motion, for example, arranging the trajectory so that the cutter stays in material all the time and close to capacity (that spiral vs lace question, but when there is no predefined lines at all), may amount to direct enumeration of hundred thousands variants. But this is what essentially the user of the program does, only he has identified from his "education" and "experience" a few typical patterns.

    "Experience" stems from all CAM programs offering the same set of path patterns. "Education" gained from teachers with the same experience. Nobody teaches an imaginary CAD, right?

    A toolpath, in almost any CAM program that I tried, is "optimized", but with most of variables locked by the user or a preset path pattern constraint. The generated result is so suboptimal, that in (rather extreme) cases I could imagine it shortened 3-4 times, judging from an animation. I could fix it, but no easier than splitting "const-Z-roughing" into single-pass layers, and defining "depth-first" areas within space that was "breadth first" by default. Not a viable type of a workaround.

    How thick a shell must be left there after roughing? I would say as little as it is safe, accounting for machine, cutter and part elastic behavior, because an extra 0.02 mm may equal one more finishing pass - slow pass over big area. And this kind of thngs cannot be even modeled in any of the programs I saw. It was like the thing asks me how much material to leave? deformation of the whole machine, the cutter and the part, partially cut, in its current state??? No, I am sorry, I cannot do tensor calculations and spatial integrals in my poor head. I can barely guess 90 days back from today, 5 times incorrectly, but at the 6th attempt ok. Leave 1 mm. It will be safe for sure. I might have overestimated it by 2 orders of magnitude. But I do not have a — what, I do not have a computer?

    I have not yet started the talk about fixturing — again, finding the best way to clamp work, in terms of minimizing the number of reclampings on the same machine, and, next, for maximum rigidity. Arguably, the part is the most elastic part of the whole gig (unless you are cutting porcelain; however, considering that hard brittle materials would require soft jaws and clamps to hold down, the softest part conjecture might be true even in this exotic case.

    I am not fantasizing. These tasks well fits into modern raw CPU power. If you compare the sitation with, for example, chess game, programs that play at the master level exist for 20 years. Not many people can beat a chess master. I am sure that a "master-level" CAM program would "beat" that "educated", "experienced" NC engineer!

    All in all, after looking at around 20 different pieces of software — "professional" , I found that MasterCAM was not as ugly on the background of the rest of them. Also, it was the second of only 2 progams where I came close to virtually cutting my test small 4-axis part.

    I do not do enumeration or comparison of software here. I can only say that "professional" CAM packages look like — well, maybe first demos of a beginning research project? The tragedy is that they have long ago petrified in that stage. Do not ask for "all features of professional CAM" software. IMO, we can move on from this point only asking for features missing from it.

  9. #9
    Gold Member
    Join Date
    Jun 2003

    Most excellent post. Now get to work and help out with this project!

    No greater love can a man have than this, that he give his life for a friend.

  10. #10
    Gold Member
    Join Date
    Jun 2003
    A very good post. Comming from a EE background, I have had some of the same thoughts. To me the perfect cam package is you first tell it about the machine, i.e. setup. That would include travels, power, speeds, spindle speeds, anything that defines the capabilities and limitations of the machine. At that point the cam package would understand the machime and that aspect would stay forever as long as the machine wasn't modified or changed. Then for each part to be cut, you give it the geometry of the finished part, the geometry of the raw stock and the stock's properties, and cutter(s) loaded. From there the CAM package should do the rest.

    Phil, Still too many interests, too many projects, and not enough time!!!!!!!!
    Vist my websites - http://pminmo.com & http://millpcbs.com

  11. #11

    Path from test file

    Running Linux, I used RoboFac's simulation mode to take a look at the path from "out.t" as included in your distribution. I have attached a screenshot of the result.
    Attached Thumbnails Attached Thumbnails robofac-path-perlcam-test.png  

  12. #12
    Join Date
    Jun 2004
    Hi there,

    I'm not sure if this is in the scope of what you are doing, but there really isn't any 4-axis cam software around that is free or really cheap. I've looked all over and there really isn't much to be found.

    The other thing that I would find very useful (although not really cam), is some kind of software that can convert point clouds from digitising into a form that CAD packages can understand.

    Maybe one day I'll make an effort to learn how to actually program, but I doubt that'll happen any time in the next 10 years... I've got too much other (cool) stuff to do!

    Have a nice day...

Page 1 of 3 123

Similar Threads

  1. Student Versions of CAD and CAM Software
    By Jcadwell in forum Uncategorised CAM Discussion
    Replies: 8
    Last Post: 08-04-2008, 03:22 PM
  2. CAD CAM Demo strategy questions?
    By Idle hands in forum Uncategorised CAM Discussion
    Replies: 6
    Last Post: 05-24-2005, 07:45 PM
  3. Newbie CAM questions
    By WoodSnarfer in forum Uncategorised CAM Discussion
    Replies: 3
    Last Post: 11-12-2004, 02:15 PM
  4. Looking for a simple cam package
    By M@T in forum Uncategorised CAM Discussion
    Replies: 1
    Last Post: 12-12-2003, 06:35 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts