CR4 - The Engineer's Place for News and Discussion ®
Login | Register for Engineering Community (CR4)


OpenSource Solutions for Computer Aided Engineering Blog

OpenSource Solutions for Computer Aided Engineering

The OpenSource Solutions for Computer Aided Engineering Blog is the place for conversation and discussion about OpenSource Computer Aided Engineering (CAE) resources available for modern personal computers. There are a myriad of solutions available in the marketplace for a number of different engineering and scientific applications, but it is not always easy to find the most appropriate solution for a particular circumstance, because many of the packages emanate from University research departments or Government development projects that do not have access to sufficient resources to publicize their products adequately. While the primary focus will be on numerical analysis solutions (FEA, CFD, Signal Processing, SPICE electronic simulation, etc.), we will occasional touch on other aspects of CAE such as Computer-Aided Drafting (CAD), 3D modeling, data acquisition (Test and Measurement, etc.), and other such technologies that can add value to the engineering process.

Previous in Blog: Notes from the Field   Next in Blog: Hidden Treasures of Open Source Software
Close
Close
Close
4 comments

OpenSource CNC- From CAD to FAB

Posted May 02, 2011 1:00 AM by cwarner7_11
Pathfinder Tags: cad CNC Open Source Software

Before delving into today's subject, a quick update on CAD for Linux:

Dassault Systèmes, those wonderful people who bring us such CAD solutions as Solid Works and Catia, have finally released a free Linux version of their 2D CAD package DraftSight, available here, in either a *.deb (Ubuntu) or *.rpm (Fedora, Mandriva or SUSE) package. One issue: the *.deb package is set up for 32-bit systems, and my 64-bit system does not like that. From Dassault help desk, here's the workaround:

1. Open a Terminal window and run 4 commands one by one to install 4 libraries :

sudo apt-get install ia32-libs Check

sudo apt-get install libdirectfb-extra Check

sudo apt-get install libxcb-render-util0 Check

sudo apt-get install libaudio2 Check

2. In the Terminal window run command to go to the folder where DraftSight.deb package is placed (e.g. Downloads):

cd Downloads

3. In Terminal window run command to force install DraftSight:

sudo dpkg -i --force-architecture DraftSight.deb

And here is a screen shot of DraftSight running on my Ubuntu 10.04 64-bit machine:

Now, on to today's topic. I first encountered "Rapid Prototyping" or "3D Printing" back in the late 1980's, when I contracted with a Canadian company that offered the service based on a process that used a laser to cure specific regions of a soup of liquid plastic. Very impressive, and so was the price- several thousand dollars to produce a prototype that, in production, should have cost less than a dollar. Most of the costs were the result of converting the 2D mechanical drawings (about the only option back in those days, unless you happened to work for a major aerospace or automotive company) to machine code for controlling the laser.

Things have come a long way in the past 20 years or so. Commercial Rapid Prototyping systems have come down in price to a few ten's to hundreds of thousand dollars, with hobby-level systems appearing in the price range of a couple thousand dollars (or less, if you are willing to dig through your scrap pile and build from scratch). CAD has progressed significantly, with 3D modeling becoming very common (and affordable). More traditional machining equipment (lathes and mills, for example) rely more and more on automatic numerical control- CNC, in industry parlance. I myself do not consider this a totally good thing- for me, when I get frustrated or stressed, there is nothing more relaxing than stepping out to the shop and turning some little trinket out on my lathe (akin to the way some people use meditation or recreational drugs). Thus, I am not all that concerned with production costs of my little trinkets. Although I spend a good deal of time analyzing speeds and feeds to determine optimum, I generally operate at 10% of the optimum, just to prolong the experience...However, one of my dream projects is to build my own Rapid Prototyping machine, and for this, numerical control is crucial.

The process of going from the CAD design to finished product consists of:

Giving credit where credit is due: the above is a variation on a diagram available from the pyCAM wiki. I have adapted it to the way I have my system set up, and changed the focus from "PyCAM" to "G-code", because it is the generation of the machine code language from the original graphical design that is critical (this is what drove the cost of the rapid prototyping process back in the 1980's).

G-code is a colloquial name for the RS-274 machine tool programming language. It is not the only language used for machine control, nor is it standard across the industry. The RS-274 standard was developed by the National Institute of Standards and Technology (NIST) in the 1980's. The simplest G-code program is nothing more than an ASCII text file containing a list of movement and coordinate commands. The RS-274 standard does include higher-order features such as arithmetic functions, variables, conditions, loops, and sub-routines. There are other approaches, such as ClassicLadder, that may be of interest to some. Our personal interest is primarily in the "*.ngc" dialog of this language, because that is what EMC2 uses, and RepRap (one of our candidate rapid prototyping systems) already uses it (as described here).

On either side of the G-Code center in the above chart, we see multiple paths for getting from our design to final product. On the right is another program that originated at NIST, "EMC2", which is an Open Source "software system for computer control of machines such as milling machines, lathes, plasma cutters, cutting machines, robots,... etc." and is distributed by LinuxCNC.org on a live CD compiled with Ubuntu (they also offer a "demo" version that can be run on an existing Linux installation, without full functionality- this demo version is what we are working with for this study). According to the EMC2 web site, "The simulator mode is useful for playing with gcode onscreen, but not for measuring jitter or driving actual machinery." We haven't yet built our machine, so we don't need full capabilities yet. The EMC2 program will ultimately read our g-code and send instructions to our CNC machine. EMC2 happens to use its own variant of g-code (officially titled rs274ngc) based upon the NIST standard.

To the left of the G-Code island, we see a number of paths to get from design to g-code. We identify two possible interpreters, which are are the two we have explored, but not necessarily the most appropriate for any given application. Note that the two primary paths are based on either 2D *.dxf original CAD files, or 3D *.stl files. Our initial experiments suggest that the 2D path would be most appropriate for engraving and such, although it should be possible to create a 3D object with multiple views. Since our first experiment involved a 3D milling exercise, however, we opted to generate our *.stl file in Salome (a personal preference, since we are more familiar with Salome than some of our other packages). Interestingly, there exists a python script add-on for Blender that generates g-code directly, which greatly simplifies the procedure, but we find Blender, because it is such a powerful and universal 3D modeler, is a bit cumbersome for simple tasks.

So here is the object we want to mill:

Which was generated in Salome, exported to a *.stl file, then imaged in Blender (just because we can!). Next, we import the *.stl into pyCAM:

After playing around a bit with various selections for tooling, processes, and such (all actually very well-documented by the pyCAM developers), we finally come up with a successful g-code defining our cut (we could have added additional tool paths to include rough cuts and finish cuts were we really going to make this part). We check the tool path by clicking on the "simulate" button. Here's a close-up showing that the tool paths actually follow the contours we are looking for:

Next, to test the EMC2 simulator, we save the g-code we just generated, and load it into the EMC2 simulator. Whoops! EMC2 complains that our model exceeds the limits of the machine in the x direction. It just so happens that these limits are set in a *.ini file, plain ASCII text which we can edit quite easily. This illustrates the versatility of the software. Although the package comes with various *.ini files for a variety of machines, it is relatively easy to modify for any particular piece of equipment. Here is our "mill" cutting one of the grooves:

And here is the "finished" profile:

Of course, this particular exercise does not represent the best way to produce this object (for instance, we would drill the hole, rather than mill it, and we would use roughing and finishing cuts, not just the semi-finish cut we used here). But, this illustrates the basic procedure.

The next step is to explore the python script in Blender. We imported the *.stl file into Blender (which may not have been the proper way to do it- we lost our dimensional reference!):

But we do see the tool path being generated.

There are still lots of experiments to do, and features to explore, but, hopefully, we have demonstrated some of the capabilities for CAD programming that are available within the OpenSource community. For those who would like to explore this subject further, here are some links to get you started:

http://www.linuxcnc.org/

http://sourceforge.net/projects/cncsimulator/ (Windows-based simulator)

http://www.cnczone.com/

http://www.cncinformation.com/

http://christian-kohloeffel.homepage.t-online.de/dxf2gocde.html

http://pycam.wiki.sourceforge.net/

http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?GcodeGenerator

Reply

Interested in this topic? By joining CR4 you can "subscribe" to
this discussion and receive notification when new comments are added.

Comments rated to be Good Answers:

These comments received enough positive ratings to make them "good answers".
Guru

Join Date: Jul 2008
Posts: 1203
Good Answers: 102
#1

Re: OpenSource CNC- From CAD to FAB

05/03/2011 8:59 AM

Thank you for posting this. It is very interesting.

Is there any chance you could tweak your posting a little by replacing the "The process of going from the CAD design to finished product" graphic with one that is a little larger? Even when the image is downloaded and enlarged by another program (Gimp) there are still some items that can not be read.

Thanks,

Bruce

__________________
Few things limit our potential as much as knowing answers and setting aside questions.
Reply
Guru
Panama - Member - New Member Hobbies - CNC - New Member Engineering Fields - Marine Engineering - New Member Engineering Fields - Retired Engineers / Mentors - New Member

Join Date: Dec 2006
Location: Panama
Posts: 4289
Good Answers: 213
#3
In reply to #1

Re: OpenSource CNC- From CAD to FAB

05/03/2011 10:22 AM

The original from which I derived my personal flow chart appears on the pyCAM web site. My edits to the original (changing the central focus from pyCAM to g-code, and adding some resources I have available on my computer that don't appear in the original) are difficult to post here, but if you send me a PM with your private e-mail, I will send you a higher-resolution version. Or I could send you the xmind original, if you have xmind mind-mapping software (another free package that works on Windows and MAC as well as Linux).

Reply
2
Guru
Engineering Fields - Aerospace Engineering - Member United States - Member - Army Vet in the aviation industry

Join Date: Mar 2008
Location: Bridgewater, Va.
Posts: 1659
Good Answers: 90
#2

Re: OpenSource CNC- From CAD to FAB

05/03/2011 9:17 AM

Interesting blog. Thanks for writing it as I am a former employee of 3D Systems, the inventors of StereoLithography, and am also building a RepRap Mendel. I was also, in a former life, a 3/4/5 axis NC/CNC programmer and sometime robotics programmer.

I hope to peruse your writing in greater detail later (especially the flow charts) as I'm very busy at work right now, but I do have one question/observation:

.stl data is a representation of a 3D model in triangular polygons developed from a CAD solid model. The Stereolithography process "slices" that polygon model into discreet sections for painting in the machine itself. As such, fidelity, to some extent, is lost in the translation process as there are no purely curved sections or surfaces in the stl model. Fidelity can be increased by processing the CAD model out at higher precision but there is a fine line between precision needed, time to process the output and resulting stl file size. Experience with the overall process is the only way to truly gauge the needs.

"G code" as processed on a CNC machine, in its purest form, has the ability to circular interpolate curves to a high degree of accuracy (ie; miniscule line segments to create an arc/circle.

My question is - in your outlined process (again I'm in a rush so I might have missed something) you talk about conversions from model to stl to G code. In other words, the process appears to proceed from high fidelity source model, to a lower fidelity stl model, and back to a higher fidelity programming system, which, in a nutshell, gains you nothing except more overall time in the process. Wouldn't it be more productive to use the stl model (as I believe the basic RepRap systems does) directly in the RP machine?

BTW, a StereoLithography machine is not controlled by traditional machine (G) code. The RP slicing process of the STL file produces a proprietary laser/platform control file that runs the STL machine.

Also, on a historical note, 3D Systems informally partnered with a 3D solids CAD system called Cadra (Softech) as the first CAD company to include an STL output option on their systems. It was an order of magnitude cheaper 3D solid modeling system when compared to others on the market at the time.

Hoping to delve more into this subject later.

Hooker

Reply Good Answer (Score 2)
Guru
Panama - Member - New Member Hobbies - CNC - New Member Engineering Fields - Marine Engineering - New Member Engineering Fields - Retired Engineers / Mentors - New Member

Join Date: Dec 2006
Location: Panama
Posts: 4289
Good Answers: 213
#4
In reply to #2

Re: OpenSource CNC- From CAD to FAB

05/03/2011 11:31 AM

Excellent contribution, Hooker! It is always good to hear from someone more knowledgeable in the field than I am.

I am not sure, were I starting from scratch, that I would use the *.stl format for the reasons you mention- although, as you point out, one can control the resolution by refining the mesh. Years ago, with my first experience with Rapid Prototyping, one of the issues I had with the final product was the final finsih- if I remember rightly, they could only provide something on the order of 0.005, which was a function of their finest available step. I needed finer surface...

The other point was that the biggest cost in producing the product back then was associated with converting the drawings to control code (I don't know if they were using g-code or not). I do know, from other experiences with contracting CNC work from others, the cost is in the code generation. I am sure, as a former NC/CNC programmer, you can appreciate the issue. By the way- if I were really going to build my sample part, I would NOT mill the hole (my only curved surface)- I would change tools and drill it. But that is a minor detail at this point (the pyCAM and EMC2 combination offers the capability of changing tools, controlling coolant flow, roughing/finishing cuts, etc- far more sophisticated than my simple example illustrates!)

You will note also that we have an alternative path in the flow chart to go from *.dxf directly to g-code as well- this could preserve some of the precision in the original. If you look at the sources of the original model (the various 3D packages I have to work with), you will note that there are any number of formats that can be generated. All of them have the ability to export to *.stl, which is why that step exists. Unfortunately, the tools that I have available for *.dxf only work with 2D. There may be other tools out there that do a better job...If you come across any, let us know.

I am not sure "precision" (as you probably understand it from your history) is going to be all that critical with the RepRap machine- were one using the powder-and-cure approach, much greater precision could be achieved.

You are correct that RepRap software goes directly from the *.stl model to g-code (essentially incorporating several steps in the flow chart), but I don't know if the RepRap system provides a "simulation" mode for evaluating the tool paths- perhaps not as critical when you are adding material rather than cutting it away...(For me, simulation is critical, because I don't have my machine yet). Also, I have seen references for using EMC2 with RepRap, but I haven't followed these links completely...

Actually, the Skeinforge package may be more appropriate for RepRap than EMC2.

Here's a good list of other CAD to g-code converters not covered in my review (or here).

Reply
Reply to Blog Entry 4 comments
Interested in this topic? By joining CR4 you can "subscribe" to
this discussion and receive notification when new comments are added.

Comments rated to be Good Answers:

These comments received enough positive ratings to make them "good answers".
Copy to Clipboard

Users who posted comments:

BruceFlorida (1); cwarner7_11 (2); Hooker (1)

Previous in Blog: Notes from the Field   Next in Blog: Hidden Treasures of Open Source Software

Advertisement