In understand it'll be a while before we're using those mills in earnest, but in the mean time since it has been over 20 years since I've worked on a CNC mill, I am wondering if there is a freely-available tool chain that we'll be preferring (or training on) that I can start to build competency with.

The way I understand it, the problem breaks down into three domains:

1) 3D CAD. Design of the actual part.

2) Translation of the 3D part into gcode tool paths, including compensation for bit diameter, multiple passes, etc.

3) Actual machine control, i.e. interpreting gcode into actual motor movement. It seems that there is a solid open source solution for this, but since the mills came with control software built for the devices, we currently won't need a solution.

Do I have the problem space basically right? And, if so, what sort of tools do we see working for us?

Thanks much,

Scott

You've absolutely got the problem defined. There isn't a very good open source solution for truly CADing parts yet, yes, there are plenty of programs out there to generate 3D models, but none of them are focused around the engineering aspect of modeling a part. If you're interested you could take a look at:

Google SketchUp
AOE
Blender

But I'd like to use something closer to:
Unigraphics NX
Solidworks
ProE
AutoCAD

I've used NX and Solidworks extensively, I know there are student licenses floating around for AutoCAD. Fortunately (maybe) Solidworks is in town, I need to get a phone call out to them to see if they'd be interested in donating a few licenses so we can legitimately use their products. Down the road I could certainly see Sector67 investing in a license to one of these programs and providing it as a service available to members.

As far as getting code from CAD to gcode (CAM), there are lots more programs to choose from, many of which are free/cheap/open source. One of the great things is with the Makerbot/RepRap projects there is tons of interest in generating gcode, so we're fortunate to have:

Skeinforge:
http://replicat.org/generators
Unicorn:
http://wiki.makerbot.com/unicorn-mk1-usage
MeshCAM:
http://www.grzsoftware.com/

I have experience using FeatureCam and MeshCAM, but we could certainly use the open source versions to avoid dealing with licensing/costs.

The mills have Anilam CNC retrofit kits and use belt driven DC servo motors, a 1100M and a 3300M controller. The 1100M works great (currently running), the 3300 isn't turning on which hopefully turns out to be something simple. We'll be using the 1100M as a full 3 axis (when necessary, 2 axes cover about 90% of runs) and the machine with the 3300 will be used as a manual mill with the CNC system serving as an expensive digital readout (once it's working. . .) since the mill still has an intact quill feed.


If you're interested in learning/helping getting the machines running you're more than welcome to lend a hand (anyone else?), I don't have any experience with these particular CNC controllers but one of the people from the shop they came from has volunteered to stop out when we have them assembled and answer any questions about them. The good thing is the interface with all of these systems is relatively unsophisticated and Gcode is pretty straightforward (/have played with CNC equipment for 4 years) so we won't have any major things to learn, but I can guarantee hiccups and bugs as we define a toolchain to get from model to part in hand.

Alibre design wants to be a cheep AutoCAD replacement.
I didn't pursue this because it lacked the 2d vector import capabilities i need for work.
Personal edition is $99 with a free trial.
http://www.alibre.com/products/hobby/

As for machine control I have used EMC2,Mach3, and turbocad.
All use the same basic hardware setup threw the parallel port.

Linux
http://linuxcnc.org/
Windows
http://www.machsupport.com/
Dos
http://www.dakeng.com/turbo.html

http://brlcad.org/ Looks like it might have some potential also, haven't played with it myself though.

Some notes on progress we've made so far with a basic tool chain for the mills in the space.

I've started with Inkscape for a simple 2D "CAD" tooling. It is not very CAD-like, but provides reasonably accessible vector drawing capability.

For gcode generation, I'm using the gcodetools plugin to Inkscape. Its a bit rough around the edges (on one installation, I had to re-install python to get it to work), but again it provided a simple interface for etching/drawing gcode generation. I have yet try it with areas or tool compensation.

For mill control, we are using the Anilam 1100 control software that came with the mills. We have a digital version of the manual for those that might be interested. That software requires a conversion process from standard gcode to proprietary "mcode", but we were able to ultimately get the mill to draw the S67 logo (it is currently on the mill if you stop by the space).

There were definitely some non-obvious steps involved:

1) Files transferred to the mill via 3 1/2" floppy need to be on DOS or ANSI encoding. Unicode files will not be ready properly.
2) The gcode to mcode translator does not work properly for G02 or G03 (cw and ccw arcs). It translates the gcode relative coordinates as absolute. I wrote a quick-and-dirty python mcode post-processor that I am currently testing as a workaround to this problem. Our worse (but quicker) workaround was to use Inkscape to convert the S67 logo's curved paths to small line segments and then generating the gcode for those paths. There may be a marginally better option to configure gcodetools to not perform arc interpolation, and only use linear interpolation.
3) Gcode with inline comments is not translated properly (the lines with comments were ignored). Gcode comments should be stripped prior to running through the mcode translation process. This bit us when the G21 (mm units) command was not interpreted by the translation process due to a comment on the same line, and the mill on restart defaulted to inch mode.
4) If you are refining a gcode program but keeping the name the same, you may need to delete any existing .M and/or .S files (an Anilam-generated file whose contents I have not looked at) before re-conversion to avoid strange translation errors. We encountered a defect that is not totally understood that seemed to be resolved by deleting the .S file, causing the Anilam software to re-translate the .M file.

All-in-all the process could be greatly improved, but we have made significant progress.

Chris has of course been a great help in all of this.

If you have any thoughts on this or suggested improvements, definitely please do weigh in.

Thanks,

Scott