OpenSource Solutions for Computer Aided Engineering

From the RepRap Wiki:

"The RepRap project is an initiative to develop a 3D printer that can print most of its own components...As an open design, all of the designs produced by the project are released under a free software license...Due to the self-replicating ability of the machine, authors envision the possibility to cheaply distribute RepRap units to people and communities, enabling them to create (or download from the internet) complex products without the need for expensive industrial infrastructure..."

Current versions of the machine are driven by the Arduino open-source micro-controller, which in turn controls a stepper motor controller, the "RepRap Arduino Mega Pololu Shield" (RAMPS). It includes plug in stepper drivers and extruder control electronics.

Everything about the RepRap project revolves around the OpenSource concept, and, were one so inclined, one could build totally from scratch (with the exception, probably, of the Arduino micro controler) from plans readily available on the Internet. All of the required software to make the system work, from the firmware for the Arduino board to the communications software and the software required to create the g-code commands (same as used in conventional CNC) is available as OpenSource.

I am not quite so adventuresome, so I purchased a kit from an outfit recommended on the RepRap organization Buyer's Guide (apparently, there are some shady dealers out there offering "kits" that leave a little to be desired). I have a little over $1000 invested, after shipping and import duties, which is about double what the cost of building from scratch is reported to be. The particular kit supplier I chose happens to have a very active community on Google Groups. For those interested in the details of the supplier I chose (I do not want to mention any particular companies on this blog, per my understanding of CR4 policies), as well as the trials and tribulations of putting together a complicated machine without a proper instruction manual, a more detailed history of my experiences is available here.

Meanwhile, this is what the kit looked like when I received it:

and here is what it looks like after it is put together:

It took us about six days from opening the box to my first print (working in my "spare" time). Some soldering was required, but nothing beyond the skills of a hobbyist. I probably spent a good deal more time surfing the Internet looking for the right instruction sets and software packages than actually building the system (the bane of the OpenSource community!).

Software

There are a number of elements to the software chain, referred to as the "Tool Chain", that must be put together to get things running, described nicely here. Here is a nice picture from the Wiki:

Which should look familiar to those who have read my previous blog on OpenSource CNC.

There are many different options for software for the Prusa Mendel, detailed in part here. This can get a bit confusing, because everyone has their own idea about the "best" solution. One of the issues that must be addressed first is what operating system one is using for controlling the machine. In keeping with the OpenSource spirit, I prefer the Linux operating system (specifically, Ubuntu 10.04 LTS 64 bit- experiences may vary with some of the newer approaches to the graphics desktop being bandied about, like Unity or Gnome 3), but others apparently are working quite nicely with Windows and MAC OS.

We have had a lively discussion in the past on OpenSource CAD packages, and virtually any package that is ultimately capable of generating *.stl files will serve the purpose- even the over-priced commercial packages, if this is your preference. I personally prefer BrlCAD because it uses a CSG (Constructive Solid Geometry) approach, which means one starts with primitive solid shapes and adds and subtracts other primitive shapes to arrive at the final object. OpenSCAD is also offers a CSG approach, but I have trouble figuring out where I am in model space, which makes it difficult to position objects. I have the same problem with FreeCAD. Salome is a nice package as well. My preference for BrlCAD or Salome probably is related to the fact that I am more familiar with these packages. Also, were I more interested in artistic subjects, I would probably prefer Blender, but I find Blender a real trial to use for engineering-type objects (although others have done some pretty impressive engineering illustration with Blender).

Once we have the design in *.stl format, we need to "slice" the model into layers and generate the g-code that will be used to pass instructions to the printer. The easiest approach would seem to be to go with the RepRap basic solution, referred to as the "Host Software" (available here), which also integrates the communications software required to talk to the printer. I immediately had problems with this package, in that it is Java based, and Java has lost it's "cross-platform" advantage ever since Oracle bought Sun- and I am not convinced Oracle is going to leave Java as an Open Source solution. Personal preferences here, compounded by the fact that the RepRap software did not build on the first go on my system, and I have no real motivation to pursue it.

We finally settled on Slic3r, apparently the new kid on the block, but intuitive and very easy to use. This program provides a well-organized GUI that helps set the parameters for the print:

Most of the settings actually don't change that much between print jobs on a particular set-up, and one can save preferred settings in a configuration file. Very detailed descriptions of the various settings and default values are provided on the website. Many "builders" also share their configuration files on the Google Groups site, to help you get started.

Once the settings are where you want them, hit the "Slice" button, the program asks for the *.stl file to operate on, then generates a g-code file ready to print.

Now that we have the g-code, we move on to the communications program. I have opted for a program called "PrintRun":

Pretty intuitive, but the available documentation is severely limited. There is an "Options" menu that allows for setting a number of parameters, but play with these at your own risk. One of the settings that came in handy was the "slicecommand" setting, which allows one to integrate the slicer program with the controller program (I describe how to do this in my detailed project summary). One must turn the extruder heater and the bed heater on to let them warm up, and I always test the extruder with the manual "Extrude" button before printing. When ready, select "Load File" which asks for the g-code file you generated in the previous step, then select "Print" and go off and have a cup of coffee. When you get back, you should have something that looks like this:

Actually, you will only get something like this if you happened to print the same object I printed. Also, bear in mind, this is my first attempt- the "Caged Ball" is my idea of a good "gauge block" for determining the capabilities of the machine. I need to do a lot of tweaking to get a better surface finish (or maybe change to a different material). But it illustrates several features, like plane surfaces, right angles, curved surfaces, bridging over open spaces. I had designed the model such that the ball would be free of the cage when printed, but found that, as the machine is currently calibrated, it could not hold the 0.5 tolerance I had used (I had to cut the ball loose with a hobby knife to achieve my original intent). I also found that the print varied a bit dimensionally from my original model, but all three axes are orthogonal to as close as I can measure by hand.

There is still a lot of tweaking to do, and lots of experimentation awaiting, but I feel this is a pretty good start...

The wife did inquire as to why I printed this particular object, since she could see absolutely no practical use for it. My response? "Because I can..."

While surfing about on the Internet the other day, I came across a hidden treasure of Open Source code hiding in plain sight, sponsored by the United States National Institute of Standards and Technology. The site, NIST Digital Library of Mathematical Functions, is best described in their own documentation:

"In 1964 the National Institute of Standards and Technology...published the Handbook of Mathematical Functions with Formulas, Graphs, and Mathematical Tables, edited by Milton Abramowitz and Irene A. Stegun...The online version, the NIST Digital Library of Mathematical Functions (DLMF), presents the same technical information along with extensions and innovative interactive features consistent with the new medium [of computing technology]...

"...The technical information provided in the Handbook and DLMF was prepared by subject experts from around the world...The validators played a critical role in the project,...[providing] critical, independent reviews during the development of each chapter, with attention to accuracy and appropriateness of subject coverage...All of the mathematical information contained in the [print version of the] Handbook is also contained in the DLMF, along with additional features...The DLMF has been constructed specifically for effective Web usage...The NIST Handbook has...[the] objective...to provide a reference tool for researchers and other users in applied mathematics, the physical sciences, engineering, and elsewhere who encounter special functions in the course of their everyday work..."

The site includes a link to the Guide to Available Mathematical Software, which is a cross index of mathematical software in use at NIST. Of course, not all of the software included in this cross index is Open Source, but that which is available as Open Source (possibly subject to application-specific licensing constraints) can easily be downloaded and used either independently, or incorporated into one's own code. The Guide also provides a cross-reference between commercial and Open Source software packages that implement specific algorithms.

As a quick example of the gems available here, let us look at a small application called "envelope", which is a "program for calculating envelope curves for oscillatory data", developed by Marjorie McClain of NIST, which is in the Public Domain. This program does something I have often felt would be very helpful in the primary stages of studying noisy time-series logged data, and something I have actually done through a time-consuming process of physically observing the data and estimating the envelope from a graph of the raw data. None of the analysis packages (both commercial and Open Source) I typically use provide a simple automated means of accomplishing this (which doesn't mean they don't provide it- it just means that if these packages do offer the capability, it is buried so deeply in all the bloat, it can't be found).

When one downloads the package, one winds up with a *.shar shell archive file, which is essentially an ASCII text file that combines all (hopefully) of the necessary components of the package. One unpacks such files with the simple command, "sh [file name]". This particular package contains a "manual" and some test data. But we also run in to a couple of issues. The program uses an obscure screen graphics render (Volksgrapher) for its output, and the program was originally written in Fortran 77 (which was the de facto standard back when it was written). The first problem is easy to overcome: since we don't need yet another plotting routine, we just comment out the calls to the graphical output in the source code (we could just as easily replace these calls with calls to something like gnoplot, but we are still in the evaluation stage).

The second problem seems a little more ominous at first, because the gcc Fortran compiler (ubiquitous in the Linux community), gfortran, does not like Fortran77 (I suspect this is a problem one will encounter with many of the packages encountered in such repositories). The old g77 compiler is no longer supported, and I don't want to risk corrupting my current libraries with legacy versions. But all hope is not lost. There is a program called f2c, a public-domain Fortran-to-C converter, or the The fort77 utility, which is an interface to the FORTRAN compiler that accepts the FORTRAN-77 language. Since both of these are available from the Ubuntu Software Center for my particular distribution, this seems safer than trying the older g77 package. We try compiling with the sample command provided in the *.shar file with fort77:

f77 -o envelope envelope.f smooth.f efc.f initpt.f env.f pchic.f pchfe.f savenv.f \ r1mach.f vg.a vgx11.a -Bstatic -native -libmil -lX11 -lm

This, of course, doesn't work because the vg.a, vgx11.a and libmil libraries are apparently related to the Volksgrapher package, which we have not built so we do not have them on our system. Also, we note that the flags "-Bstatic" and "-native" are not legal in fort77. By eliminating the plotting routines and the illegal flags, the program compiles the first time around with the command:

f77 -o envelope envelope.f smooth.f efc.f initpt.f env.f pchic.f pchfe.f \

savenv.f r1mach.f -lX11 -lm

(NOTE: it is likely that we could eliminate the link to the X11 library as well).

But, does it work?

The package includes some test data and sample results we can use to evaluate the program, so we run the "envelope" command we just created with the "test.dat" file included with the archive. Our output generated by the program agree exactly with the sample output files, telling us the program is running as it was designed, doing what it was designed to do(and it did it too fast to time!). Using LibreOffice Calc to have a look at the output:

Looks good, exactly what we expected, but this looks like pretty clean data compared to what we are usually working with. How does the program work with some real-world data?

Here is an example of some data from a project:

As seen in the above illustration, the original envelope curves (dashed lines) seem to follow the data fairly closely, but are too close together, missing a number of peaks. We fix this by shifting the upper curve by 0.5 in the positive y direction and the lower envelope curve in 0.3 in the negative y direction. I suspect the reason the curves did not fit the data as well as they fit the test data has to do with the "initial smoothing" routine. But, with these preliminary results (which took all of 15 minutes to develop, including loading the results into LibreOffice Calc to plot them, studying the results, re-running the "envelope" program with new tolerances a couple of times and modifying the plots a couple of times to see the new results, etc.), we now have some valuable information that we can use for further analysis.

This little exercise has been intended to illustrate some of the more esoteric advantages of Open Source software. First of all, we have a public domain tool readily available for solving a particular issue with minimal investment (in both dollars and time). We have a tool that does one thing very, very efficiently, and we do not find ourselves wading through all sorts of bloat in a commercial package (or, even some of the larger Open Source projects)- we get to our solution much faster. If we are not pleased with the way the software works, we have the option of modifying it to suit our own needs (i.e., we dropped the program's original graphic output interface. Note that this did not require a high level of programming expertise to accomplish). The little application is pretty much platform independent, so long as one has the appropriate compiler.

Plus, it is really nice to see our tax dollars going for something that is practical...

The NIST site is not the only site where such practical Open Source software can be found. A couple of others (to which the NIST site also links):

• netlib: A repository of freely available software, documents, and databases of interest to the numerical, scientific computing, and other communities. The repository is maintained by AT&T Bell Laboratories, the University of Tennessee and Oak Ridge National Laboratory, and by colleagues world-wide. Most netlib software packages have no restrictions on their use.
• Collected Algorithms of the ACM: Software published by the journal ACM Transactions on Mathematical Software (TOMS).
• Computer Physics Communications Program Library: Software associated with papers published in the journal Computer Physics Communications.

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

I often hear that people are concerned about the "learning curve" required to switch from a Windows environment to a Linux environment, yet I have found that downgrading to a newer version of Windows from an older version (say XP to Windows 7) actually involves an even steeper learning curve than switching to one of the newer Linux distros. Having installed both Windows and Linux operating systems, my experience has been that Linux is by far the easier to master. And one does not need to abandon one's favorite applications because they are no longer supported by the newer version.

But don't take my word for it. Our friend Garthh was having computer problems a few months ago, and took the opportunity to explore the Linux world. He has become a bit of a proselytizer for OpenSource- his experiences illustrate how easy it is for the newbie to adapt to the latest Linux versions, and how Linux can be used to salvage "challenged" computer equipment. He has allowed us to share his comments:

"Right at the moment my main computer is without a hard drive. I'm running Mint 10 from a 8g flash drive . I've been using Mint, because I'm setting up machines that are going to be used by fairly inexperienced users & stuff like music & video [including dvd's] need to just work. Mint to me seems similar to XP.

"There are a dizzying array of variations of the basic Linux Operating System, which are referred to as 'Distros'. Ubuntu (http://www.ubuntu.com/ ) is another good one, the community [forum] being larger, any solution you find there is going to apply to Mint. The only real difference being Mint already has the codecs installed for most anything you would commonly run into & the layout of the desk top being a bit different. One of the cool things about the Linux operating system is the ability to have the layout & appearance configured."

[EDITOR NOTE: Mint is actually based on the Debian/Ubuntu platforms, and is available here (http://www.linuxmint.com/). The primary advantage of Mint is that is comes with a large variety of proprietary CODECS which are not generally included in the "pure" OpenSource distros]

"I've learned some interesting things about browsers in the process.

"Chrome (http://www.google.com/chrome/?brand=CHMB&utm_campaign=en&utm_source=en-ha-na-us-sk&utm_medium=ha&hl=en) is almost the same as on a fully functioning box [computer]. Firefox (http://www.mozilla.com/en-US/firefox/ ) on the other hand will give lots of gray screens, but never does crash . Opera (http://www.opera.com/) is usable but somewhat slower than Chrome. I'd say this is an indication of how much of the resources of the computer each of the browsers use

"I have a bunch of content [16000 mp3's] on a USB External Hard Drive [Seagate Free Agent Go] I can listen to any song, but if I try to load the playlist of all 80g of my library, it will take a few minutes & slow down some if I try to skip too many songs too quickly, no crashing, just gray screen, while it catches up, playlists of a few 100 songs are no problem. Consequently any programs that require transfers of large amounts of data don't work very well, due to the basic limitation of USB it being 2 twisted pairs.

"I in effect have a personally configured operating system, that works on any machine that will boot from usb, which most modern machines will. The updates are all current, all my saved passwords, my layouts & preferences are just the way I like them. I can have my favorite applications, I just store the content somewhere else. Say I'm using Mint on a stick on a Windows XP machine I can use any of the documents, pictures, music... I don't have to change anything at all on the Windows machine.

"Out of the total 8g on the SansDisk Cruzer Flash Drive, I'm using 6g. I just have to pay attention to what & how much I've downloaded. I transfer anything I really want to keep or send it to myself as an email.

"The process to install the OS on the flash drive, is not very difficult

1) Download the distro

2) burn it to a CD or DVD, described as a "Live CD"

3) Boot to it. On most modern computers [2006 or later] restarting will do it. If this doesn't work, go to the advance settings on bios & change to boot order to 1st=CD, 2nd=USB, 3rd=HDD. In everyday operation, you won't notice any difference at start up, since you won't have a Live CD or USB with an operating system installed

4) Plug in flash drive

5) Click Install on the desktop

6) Follow the instructions, until you get to Prepare Disc Space [step4] where you get a choice of where to install the new OS. Click the dropdown menu, you should see both your HDD & the FlashDrive. You will easily be able to tell the difference by the size. Click on the Flash Drive. Check the box that says use the entire disk. You will have to confirm the information 2 more times. Make sure you are formatting the flash drive.

7) finish the installation

8) when you do the restart as directed remove the Live CD

9) Update your new OS on a stick. play with settings & appearance

10) When you want to go back to your regular OS, shut down the computer, remove the Flash Drive, start the computer

"Here are some screenshots (http://www.pronetworks.org/forums/ubuntu-9-04-installation-screenshots-t108880.html)

"This a easy way to try out different distro's, without committing, to a dual boot or compromising any thing you have on your computer."

An additional note: Due to the fog surrounding the future of OpenOffice as a result of the takeover of Sun by Oricle, I have decided to investigate the new LibreOffice, which is a fork of the original OpenOffice suite. I will not look back. LibreOffice has fixed the two major complaints I have had about OpenOffice:

1. Graphics in the spreadsheet application in the old OpenOffice were painfully slow- not just creating a graph, but editing it (adding/changing titles, resizing, rescaling, etc.) would take forever. The LibreOffice version is nearly as fast as my old favorite standby, Excel 2000.
2. In the word processor application of Openoffice (and in newer versions of MS Word) I have been constantly plagued by my illustrations jumping about all over the place when I change something in the text. Everyone has their own idea about properly anchoring an object, but both OpenOffice and newer versions of Word seem to think they know more about how I want the final layout to look. This does not happen in LibreOffice. Things stay where I put them.

These are major improvements, and surprising, considering LibreOffice, although pretty much being in the hands of the original OpenOffice developers, is a significant improvement over OpenOffice, even though it has only been out and about for a short time.

There appears to be a great deal of interest in understanding basic electronic circuits, and the hobby level design of such. A most important resource necessary for the casual dabbler in electrical and electronic systems is, of course, a good entry-level text. A very good resource can be found at http://www.allaboutcircuits.com/, either for perusal on line, or downloadable in *.pdf format. These series of documents begin with basic electromagnetic theory and work through some basic circuitry.

These volumes also provide a great introduction to SPICE (Simulation Program with Integrated Circuit Emphasis), which is actually one of the granddaddies of OpenSource software, being released as a Public Domain project long before anyone knew what OpenSource meant. Originally developed in the early 1970's at the Electronics Research Laboratory of the University of California, Berkley, SPICE simulation programs combine component models (resistors, transistors, capacitors, IC's, etc) and their interconnections into a "netlist". The component models and netlist are generally ASCII text files. The simulation machine then uses the netlist to build a mathematical model to be solved. (the original SPICE did not include a GUI and schematic capture , having been developed before sophisticated graphics capabilities were available, and produced the output in pages and pages of tabulated data). For the most part, component models and netlists can be developed on one package and analyzed on another, although there are some exceptions to this.

Vendors of commercial software packages and the various free packages available have added schematic capture front-ends to SPICE from which the netlist is automatically generated. In addition, graphing utilities have been added to see waveforms and graphs of circuit parameters. My favorite for years has been a free version of National Instruments Multisim (available free, for instance, from Analog Devices- other component manufacturers have similar packages available to support their product lines). One of my favorite features of Multisim is that the GUI provides graphical models of measuring equipment, such as DMM's or oscilloscopes, that simulate the actual connection and appearance of the instruments (including, for instance the time base and trigger settings for the oscilloscope, which can be quite helpful for the newbie).

Pspice is another popular package (available in a free limited version here). One can find a list of additional free schematic capture and simulation programs here. These packages are usually very well documented and easy even for the newbie to grasp.

The limitations of a free package from a component manufacturer are that component models are generally limited to models of the manufacturer's products (plus a few standard components available in all packages), and size limitations on the circuits one can design (generally not a limitation for the amateur in that the number of elements and sub-circuits allowed are generally quite generous). One can expand one's library either by downloading models from device manufacturers (such as the TI device model library), or, if you are sufficiently advanced in your capabilities, you can edit one of the generic models to more closely match the parameters of the device you want to model.

Most of these packages are available primarily for Windows environments, but those of us living in the OpenSource world (i.e., Linux) have options as well. A lot of the packages will run in a virtual machine such as VirtualBox. A native basic package for Linux that is easy to use and provides the essentials of schematic capture and simulation of simple circuits is called Oregano. Unfortunately, my attempts to link to the developer web site have ended in broken links, suggesting that the development team may no longer be active, but it is still available *,deb package from Ubuntu, and possibly for other distros as well. Www.sourceforge.net still offers the package in *.tar-gz format, although it appears the last update was back in 2004. Here is a sample screen shot of the schematic capture from Oregano:

And a shot of the simulation results:

The the next option we look at is a bit less integrated, but more flexible. The gEDA suite, which includes a schematic capture package (gschem), with a more extensive parts library. However, once the schematic is created, one then must use another program, such as EasySpice or Gspice to do the actual simulation.

Scilab, a "numerical computation package providing a powerful computing environment for engineering and scientific applications", includes a simulation package known as Xcos, an editor designed to build models of hybrid dynamical systems. It is based on the older Scicos developed at INRIA (Institut national de recherche en informatique et en automatique, or, in English, The National Institute for Research in Computer Science and Control, created in 1967 and originally housed at SHAPE, central command of NATO military forces). Scicos may still be encountered in older versions of Scilab, and is still available as a stand alone package. Models are assembled, loaded, saved, compiled, and simulated, using the Xcos GUI. Xcos serves as an interface to the various block diagram compilers and the hybrid simulator scicosim. A sample screen shot from the web site:

Once you have designed and simulated your circuit and determined that it actually does what you intend it to do, it is time to build it. We will assume you have already breadboarded the circuit and proved that it works as the simulation says it does. Now you want to convert it to a printed circuit board. One can always use what are called prototype boards, printed in a variety of patterns and styles (available from your local electronics hobby shop or on line at DigiKey):

or you can build a customized printed circuit board specific to your project. The gEDA project includes a package called pcb which will help you optimize the layout of your circuit, or there is another package called eagle from Cadsoft (available in freeware version). The output from these files is something called a Gerber file, which can be sent off to someone like Sunstone Circuits, or if you are really adventuresome, you can print your own circuit board, using a print of the graphic image created in your layout software as a mask for etching the board. Vendors such as Digikey offer a variety of such kits to suit most any budget, or here is a set of instructions to follow to "roll your own".

The Internet is inundated with many other resources, such as the Analog Circuit Library from Analog Devices that provides a collection of "tested circuit designs that address common design challenges and have been engineered for quick and easy system integration", and many sources of free circuit designs such as http://www.electronics-lab.com/, where "you can find useful circuits with full description, diagrams...electronics articles, links and downloads."

We have only scratched the surface here, and I am sure we have missed most of your favorite electronics sites. Join in with your own recommendations and suggestions!

During some research I was doing regarding some rather unusual effects of lightning strikes, I came across an interesting package for analyzing electrical transients called ATP-EMTP, which stands for "Alternative Transients Program- ElectroMagnetic Transients Program". This is a bit of a diversion away from the OpenSource community, since, although the program is available at no cost, there are some minor restrictions to the license.

From the web site:

"ATP is a universal program system for digital simulation of transient phenomena of electromagnetic as well as electromechanical nature...The birth of ATP dates to early in 1984, some of the original developers did not approve of proposed commercialization of BPA (Bonneville Power Administration) EMTP by DCG (the EMTP Development Coordination Group) and EPRI (the Electric Power Research Institute)...

"ATP is not in public domain. It is, however, available free of all charge to anyone in the world who has not participated voluntarily in the sale or attempted sale of any electromagnetic transients program. ATP licensing is mandatory...After the licensing agreement has been approved, that party is eligible to use ATP program. "

In other words, it is free, but not OpenSource. This program is of primary interest to those who deal with electrical power generation and distribution systems. This program can be used to simulate complex networks and control systems of arbitrary structure. Among the applications they list for the program:

* Lightning overvoltage studies(the area that caught my attention)

* Switching transients and faults

* Statistical and systematic overvoltage studies

* Very fast transients in GIS and groundings

* Machine modeling

* Transient stability, motor startup

* Transformer and shunt reactor/capacitor switching

* Power electronic applications

* Circuit breaker duty (electric arc), current chopping

* Harmonic analysis, network resonances

Among other applications.

There is a very active support group for this package, and extensive documentation, which makes it usable even for a novice such as me. The package is available for multiple platforms (Windows, Linux, MAC).