Guys, I'm almost done with a 5' x 4' table for computer controlled engraving and routing. Now's the time to buy good drawing and g-code translator software. I'm thinking of CorelDraw Suite 11 and BobCad. Any other suggestions?
CNC Routing Software
Jan 15, 2004
13 Replies
Try the new group http:\\cnczone.com , alot of people doing what you are doing. Al
Gary, Until you find your good software, here's some not-so-good that you can play around with. At least it's free!
formatting link
for your engraving you probably want raster to vector to dxf to g-code. keep your wallet open!
Rudy
Gary,
Look at DeskCNC. It has integrated CAM and machine controller. It runs on Windows 98 or later and does a good job of machine control on even pentium 200mhz computers. The cam capability includes contouring, pocketing, drilling, engraving, raster to vector, tracing and 3D engraving (image files), printed circuit board (gerber and excellon) files, 3D .stl machining, and it also includes 3D surface probing capability with direct creation of a machinable surface from the probe measurements.
Then all you will need is a drawing program that can create DXF files.
You may also be interested in VectorCam as it has an integrated CAD and CAM capability. The CAD is available with a nurbs based 3D surface modeler, and as wireframe, both integrated into the cam capabilities.
formatting link
We are the source for low cost cad-cam.
Fred Smith - IMService
group and hobby discounts are at:
formatting link
Fred - If you're dedicating a macine to the controls, you can have a look here
formatting link
You can find other software in the links section of
Regards,
Tom
I'm not. I'm recommending that people use windows that they already know and build on that with a program that both runs a machine and quickly creates toolpaths and CNC programs. DeskCNC has smooth continuous contouring, tool and work offsets and cutter compensation, and integrated surface probing with the low cost probes.
Fred Smith - IMService - THE source for low cost Cad-Cam
formatting link
for hobby discounts.
Well ... what *I* already know is unix, of which linux is but one example. :-)
Hmm ... perhaps for stepper motor driven systems, where if the CPU halts, so does the feed. But with a servo-motor driven system, I shudder at what could happen when the system gets a BSOD (Blue Screen Of Death) in the middle of a fast move -- since without the CPU, there is nothing to change the output voltage command to the servo amplifier which is what determines the motion speed. (Well ... the limit switches would stop it -- but not gently. :-)
Granted -- most hobby machines will use steppers, so this is not a problem, but some of us prefer servos for various reasons.
Enjoy, DoN.
That makes you part of a very small minority when it comes to personal computer users. Most people use Windows, barely and will not stomach the interface presented by the command line in DOS and linux operating system controllers. Free or not.
DeskCNC has an inexpensive external controller card that handles any problems associated with using Windows, or any software controlled by a PC OS, for that matter.
I have always wondered why it is that unix and apple users so predominantly get the blue screen of death on Windows. I know that Apple users tend to use Adobe products which I have found to be particularly unstable on Windows. What is it that unicers do that causes the problems? Urban legend perhaps? Further, if you don't like or use Windows, how can you even get the BSOD?
;-)
Fred Smith - IMService
Of course, the difference in the graphical user interface between any two versions of Windows is as great as or greater than that between a version of Windows and a Linux system with a graphical user interface chosen to please ex Windows users. There is no need to ever see a command line, if you don't specifically want to. UNIX is all choice. Windows is "where does Microsoft want you to go today?".
But hey! to each his own. :-)
-tih
As has already been pointed out, in another followup to your most recent posting, a command line is not necessary -- unless you
*want* to use it. (I tend to run my unix windowing systems with multiple command-line windows, but have the option of a full GUI should I so desire it. (I don't, because I find that I can do a lot more with a command line than I can with a GUI.) [ ... ][ ... ]
I *don't* get it -- because the two systems which (sometimes) run Windows -- one laptop and one tower -- both are rather minimal systems -- I don't load them with tons of applications vying for screen space and CPU at the same time, which is what seems to most often trigger the BSOD problem. (That, and the progressive congestion of a disk which needs defragging -- something which none of my unix filesystems need, as they were designed to avoid such problems in the first place. :-)
I also don't keep the Windows system running very long, so it doesn't have the time to build up its problems. In contrast, my unix machines tend to run for months without a reboot. Here is the uptime for the machines on my network at present:
====================================================================== cadeau up 5+09:11, 0 users, load 1.00, 0.77, 0.64 ceilidh up 12+07:29, 0 users, load 0.08, 0.10, 0.11 chipmakr up 71+21:27, 0 users, load 0.00, 0.00, 0.00 curlmakr up 42+00:21, 0 users, load 0.13, 0.11, 0.08 fuego up 5+05:29, 2 users, load 0.00, 0.01, 0.01 hendrix up 5+05:34, 0 users, load 0.00, 0.00, 0.01 izalco up 12+05:41, 0 users, load 0.09, 0.11, 0.09 nibblets up 4+06:11, 0 users, load 0.05, 0.08, 0.07 popocat up 21+09:52, 0 users, load 0.08, 0.01, 0.00 popocat-2 up 21+00:51, 0 users, load 0.12, 0.11, 0.08 shindig up 21+09:34, 0 users, load 0.05, 0.03, 0.03 sponge up 13+07:15, 0 users, load 0.12, 0.10, 0.08 stromboli up 12+14:34, 0 users, load 0.00, 0.01, 0.01 twenty20 up 21+10:04, 0 users, load 0.00, 0.01, 0.01 ======================================================================
At the moment, the longest time is curlmakr (a linux box with EMC installed), which is on its own UPS. Several of the others are connected to a big UPS which needed to have its batteries replaced (after four years of continuous service), which rather forced a power down. Some of the others have had hardware upgrades (faster ethernet cards installed), or are testbeds of various sorts, so they have been rebooted more recently. The most recent reboot is nibblets -- the laptop -- which was used for converting and uploading a few images from Cabin Fever.
The units following the word "up" in each line are
days+hours:minutes
Before Isabel came through, with a long enough power outage to require shutting everything down, some of the systems had been up over a year.
I don't trust a Windows system running a combination of a machine controller, a CAD program, plus internet connections to download files from other systems to not experience such BSOD problems however. And one which is getting games played on it is even more vulnerable, because games under Windows tend to take direct control of the screen hardware, and the keyboard, and lots of other things -- and don't gracefully let go of them.
A possible contributing factor for problems with Adobe image processing software is that it tends to try to do its own virtual memory, ignoring whatever the OS might or might not offer.
On the unix systems, the only Adobe software I run is Acrobat, and I usually prefer to run xpdf for the purpose, as it is much faster to load and to change images.
What I use Windows for is two things -- which I can't avoid:
1) Running the necessary plugin to convert the weird variant of TIF images produced by my rather strange cameras into normal TIFF or JPEG or whatever. The plugin needs PhotoShop (an Adobe program), and I use Photoshop Elements -- the simplest version available. Someday, I will decode that weird TIFF and write my own unix conversion program, but for the moment, I just pop a different disk drive into the laptop, load and convert the images, and then upload them to my unix network. Then I restore the disk which is booting OpenBSD, which is my current favorite unix on Intel -- in part because it is the most seriously security-focused version.2) The annual Income Tax rites. Nobody makes an Income Tax program for any of the flavors of unix which I run -- because most purchasers run either Windows boxen or Macs, so that is where the money is for the vendors.
The rest of the time, both of the above Intel boxen are running OpenBSD, or occasionally, I will be playing with a linux version. I've recently wound up with a copy of Sun's Solaris for Intel processors (X86) when I bid on Solaris 9 for SPARC, so I guess that I'll be trying it out, too, since he won't take it back, because I opened the shrink wrap before discovering the error. (He had *described* it as for SPARC, so I think that he did not know what he had.)
Enjoy, DoN.
Neither do I, on the Windows box I use for administrative tasks at work. It's properly installed and configured by a colleague who knows Windows, and I only use a handful of major applications from reputable companies. I do not install stuff myself, and the machine never runs games.
As a result, that box *never* crashes, and I don't even bother to log out, except when needed, e.g. because of the installation of a patch which requires a reboot.
-tih
Not with CNC machine controller software.
Fred Smith - IMService
Most people can't and don't want to. Which is my point.
The limit switches would have no effect on the servo system because it stops as soon as the PC ceases to operate, whether Windows or Linux. DeskCNC stops very gracefully thanks to an external controller, others perhaps dead in their tracks, but they still stop.
We are talking about step and direction driven servos, like Gecko and DeskCNC and Rutex.
You seem to spend a lot of energy complaining about a problem you don't have.
Fred Smith - IMService
[ ... ]
Those are *not* true servos -- those are steppers -- or servos with electronics around them to emulate steppers. They don't offer what I want out of the motion controllers -- smooth slow motion so you can cut shallow angles without generating visible steps. A true servo assembly has a motor, a tach feedback generator, and an amplifier which controls the power to the motor to maintain the speed information from the tach generator balanced with the command voltage from the control electronics.
The control electronics processes a digital command signal through a D/A converter, to produce a voltage which is fed as the speed command to the servo amplifier.
If the CPU stops (e.g. BSOD), the voltage remains the same, so the motor keeps moving the table or spindle in the direction, and at the speed at which it was last commanded.
I was simply warning about the potential of a problem with a combination of true servo motor assemblies (which *you* don't have), and an OS which is known for locking up without warning. This problem does not exist with stepper motors -- or servo motors with electronics which make them emulate steppers.
I like what I see of the Gecko products, and have been waiting for them to offer true servo amplifiers. They have not yet done so -- and some studying of their online manuals for the stepper emulators shows that they don't even use the tach feedback, so I guess that I should stop expecting them to make true servo amplifiers.
*You* took my pointing out a problem in some possible configurations using Windows and *true* servo motor assemblies as an attack on your product, and jumped up to defend the OS itself.Enjoy, DoN.
Join the Discussion
Have something to add? Share your thoughts — no account required.
Didn't find your answer?
Ask the community — no account required