RepRap meets CNC

I already have a CNC milling machine running DeskCNC. According to the documentation DeskCNC already handles STL files.

I am building RepRap Extruder head and plan to fix it in the toolholder of the mill (motor stopped of course). As the XYZ of the milling machine already works perfectly building a Cartesian Assembly seems unnecessary.

The problem is my CNC mill (like most CNC machines) works with GCodes. The RepRap software is designed to drive the Cartesian Assembly using the PIC controllers using a serial link and your one protocol.

My plan is to modify the RepRap host software to drive a GCode based machine. To control the the extruder I could use standard CNC On/Off codes such as coolant. The temperature could also be set using motor speed but a knob is my first option. ;-)

There are a lot of enthusiasts like me with CNC machines and this "fork" would allow them to get into the world of RepRap without have to find time or space for another machine in the workshop. This could only be good for RepRap in my view.

Before I go too far with this it would be interesting to see if others in the RepRap group are already treading this path.

Of course any code produced would be open sourced and probably placed on Sourceforge.

It's been a long time since a project lit me up but RepRap pressed a lot of buttons all at the same time. It's serious fun!

David

I don't know a hill of beans about the RepRap code generator; it might be easy to do in that program, but here's my 2 cents...

There are programs that will generate G-code for you. I don't know much about the software stuff, but what I would look into doing would be to use one program to slice the model you wish to create into the thin planes, as normal, and use a separate program to convert them each into G-codes. It would be easier to make some type of batch conversion process, since the slices will be small and there are a bazillion of them. Once they all get converted they would also need to be placed into the *same* g-code file, with the Z-positioning added in- if you g-code converted the slices individually, there would be z-axis values, but they would correspond to zero and not-zero, whatever thickness it was supposed to be at. A small program could sorta easily go though each generated g-code file and add a small amount to each z-value (cumulatively, though, it wouldn't be the same value added to each one).

I know you probably can do all that but it always helps to hear someone else's opinion, in my book.

The one problem, by the way, with the above setup is that it would be hard to say, do an infill pattern. The g-code generator software would have to know you wanted to do that- typically the RepRap code does a circumference and infill, and on a CNC machine it doesn't matter what order you cut in.

Maybe that's way too complicated, lol it probably is, but I figured I haven't helped much so I'd say something!

I've heard a steady refrain about converting the output from the various printers to G-Code for the past year or so. I finally got interested enough to go back and look up a few references on just what is in it. I ran across this interesting passage in Wikipedia...

"G-code is a common name for the programming language that controls NC and CNC machine tools. Developed by the Electronic Industries Alliance in the early 1960s, a final revision was approved in February 1980 as RS274D.

Due to the lack of further development, the immense variety of machine tool configurations, and little demand for interoperability, few machine tool controllers (CNCs) adhere to this standard. Extensions and variations have been added independently by manufacturers, and operators of a specific contoller must be aware of differences of each manufacturers' product. When initially introduced, CAM systems were limited in the configurations of tools supported."

[en.wikipedia.org]

From my admittedly casual investigation, it would appear to me that G-Code is effectively a dead standard that has speciated into a multiplicity of dialects unless I've missed something major.

Given that, wouldn't "adapting" Darwin, Zaphod and Tommelise outputs to G-Code be more than a little like trying to translate American English into "European" or worse still Latin, and expecting to have somehow standardised?

Thanks for your thoughts guys.

First, GCode might have suffered from some deviations but it is far from dead. Since there is a standard (RS-274D) then the core codes usually work the same from machine to machine. Most CAD systems have GCode generators and a all of a the open-source CNC and paid-for hobby systems run them.

And that is my point. A lot of amateurs have built CNC machines in one form or an other. Usually milling machines and lathes but plasma cutters and routers are also quite common. The XY table is the same as the basic carriage of a RepRap and the Extruder would be fitted to the tool holder which is the Z axis.

The trick is to take the RepRap software and, at the point where the X,Y,Z movements are created, convert them into GCodes. Since we cannot extrude at high speeds then it could be done with just one GCode - G01.

Anyway, if it doesn't work I can always make a complete RepRap and use the standard PIC based controllers. The Extruder would be the same whatever I use to move the substrate.

Either way it will be fun trying!

Regards

David

Howdo folks,

G-code describes toolpath motion. The great difference between 3D printers and CNC machine tools is that 3D printers fill a space whereas CNC tools carve it away. The fiddly thing about writing decent G-code generators is figuring out the order in which to cut away the material, this is lots easier for 3D printers which just have to fill a space.
My 2 cents, the actual description of G-code belies the complexity of generating the toolpath, something I don't think the RepRap code needs to address. So why describe the extruder path using a different notation which is not reusable on a CNC machine? What did I miss?
My 3rd cent.. out here in East London we still use G-code and variants thereof, I don't see a competitor arriving too soon. On the smaller, more modern SRP mills we use antique plotter languages like RML-1 and PLT.. a step backwards. Try describing a bezier spline in G-code.

Inversely, you COULD use the RepRap software to run a CNC machine. All voids would have to be fully accessible from the top. You'd have to take and boolean subtract your object from a block. The only other software modification I can think of is that the system would have to bring the tool to it's Z+ starting offset whenever transitioning from one "extrusion" start to another.

RML-1 and PLT? I'll have to look into those. I'm curious to use the RepRap/RepStrap platform with a secondary plotter/cutter module running some common printer code. The only one I knew off the top of my head was HPGL and Windows includes an HP HP-GL/2 print driver (or at least it's on mine). Hopefully this would be some standard.

RML-1 is the Roland plotting variant of HP-GL/2. I found that the Roland MDX-20 seems to accept HPGL reasonably gracefully. But its still controlling the Z-axis with Pen Up, Pen Down commands. The standard is not widely published and can sometimes turn up on FabLab sites.

It may indeed be possible to use the RepRap software to drive a simple mill, but I think there are fewer demands placed on calculating the extruding head speed in general.

I feel that it is eminently possible to clamp a Dremel in to the cartesian frame and perform light 2.5D milling. Useful for circuit boards and carving foam/wax for mold masters.