Hi All,

I’m asking similar questions on the CNC forums but I thought I’d ask here too.

I intend to purchase a pretty basic CNC kit based on the OX. I know enough about the mechanical aspect of the kit and could customise so that it perfectly suits my needs, but have decided to start with something that just works OOTB then create its replacement separately after I have the workflow dialed.

The part of the CNC process I don’t quite understand yet is the CAD->motion.
Most of the kits seem to be targeted towards people with no CAD experience, so the software seems to be more wizard based where you feed in a DWG and it gives very little control but spits out G-code.

I understand that CAD data needs to be interpreted by CAM software (ie. MadCAM) which will export toolpaths (assume these are g-code?) MadCAM is the software I intend to use since I’m already comfortable in Rhino and since I’m studying again I’ll get access to their education pricing.

I also understand the stepper motors need to be driven by ‘driver’ like the Gecko G540.

so just to clarify, my understanding of the dataflow is this:

Rhino->MadCAM->Toolpath file
Toolpath file->Mach3 (or other CNC controller software) ->Ethernet Smoothstepper -> Gecko G540 ->motors

is the Mach3 required? or does it just handle converting CAD into toolpaths?

Mach 3 converts g-code into machine commands to be interpreted by the stepper motor drivers. Mach 3 is not specifically required, in fact some hardware may not be supported by it, though it is a pretty general piece of software with wide applicability.

There are other programs which perform the same function as Mach3. When you know which CNC machine you will use, ask the supplier what driver they recommend. They may even supply one with the machine. The program which generates the g-code will probably have a library of templates for a variety of CNC machines and you will need to ensure that you have compatible capabilities all along the line.

Thanks AIW,

Found this - while looking for mach3 compatibility list - after reading your reply which really helped too.

Even went as far as explaining that a hardware controller (eg. smoothstepper) may remove some processing load off the mach3 workstation.

Sounds like I need an Ethernet daughter board for the file server (which lives in the garage with CNC) to connect to the network switch & the eth. Smoothstepper.
Then I can work in the office or remotely on laptop and network my gcode to he file server and set up the file on mach3 from there…

Also need to confirm that mach3 will work with my MadCAM files & is compatible with the smoothstepper:eth + Gecko G540 combo… pretty sure it is (found people positing online with similar setup) but worth me confirming…

Thanks again

madCAM has many post-processors, which can easily be edited to work with any controller. I wouldn’t worry about the madCAM side of this project.


Thanks @DanBayn ,

If I buy MadCAM do I need the mach3 software at all? Or can MadCAM drive the smoothstepper directly?

You need controller software.

1 Like

Thanks mate, thought it sounded to good :blush:

It kind of goes like this:

Rhino creates a model. madCAM creates g-code. Mach3 (or Fanuc, Heidenhain, Mitsubishi, etc.) read the g-code and convert that to machine movement.


I built an OX CNC two summers ago, and it was quite fun. I ended up going with a TinyG CNC controller. I did not want to pay for CAM software, so I ended up using Fusion 360. Transferring Rhino models to Fusion was not as smooth before, but now Fusion will import Rhino models. CAMing in Fusion is really easy to pick up (there are help dialogue windows for everything).

Yeah, Fusion is getting pretty popular. Pretty hard to compete with free. The advantage of madCAM (or Mecsoft’s RhinoCAM) is that you don’t have to leave the Rhino environment to create your toolpaths. Our main CAM software is WorkNC, and that requires exporting an IGES file, creating a “workzone” in WorkNC, then creating toolpaths. If the part changes, you pretty much have to start over. If you can stay in Rhino, then you cut out a lot of steps, and changes are easy.



[quote=“DanBayn, post:10, topic:42191”]… you cut out a lot of steps, and changes are easy.

That directive has informed almost all of my decisions on this project. Less time hacking, more time creating…

Hi there. I built a Workbee CNC (the updated OX) and I’m driving it with the Xpro controller version 4 and the OpenBuilds software. I learned barely enough Fusion360 to make something simple and create some G-code to explore Fusion’s CAM capabilities on the Workbee. I know Rhino and RhinoCAM pretty well, and I gotta say it has been rough trying to get geometry from Rhino into Fusion360 to make G-code for the Workbee. Do you have any suggestions on getting the curves to transfer? I have gotten my models to transfer as DXF depending on the complexity of the model, and had better luck just opening them as 3DM files but none of my curves are in the Fusion workspace. Any Suggestions?

DWG usually works for the curves. I generally assume no curves will transfer through with 3DM, so I have to export an additional DWG file if curves are applicable. You may need to tinker around in the export options. You will just need to import the DWG file into the 3DM file once you have it open in Fusion.

Thanks, I will give it a shot. Much appreciated!

Don’t know about Fusion’s import, but IGES is also good for curves on export…

The best bet for transferring curves and surfaces to Fusion is DWG or DXF. DWG\DXF will transfer surfaces, curves and meshes.
This is the export scheme I use.

Blocks in the design will be converted into components and sketch layers to sketches.


Prehabitat, I run MadCAM in Rhino which generates G-code that I then move to my CNC machine’s computer. There, I run the file in Mach 3 or Mach 4 (dual boot Windows XP/Windows 7) and send the output thru the LAN port to an Ethernet SmoothStepper which drives my Gecko 540. You could save the dollars on the Ethernet SmoothStepper by connecting your machine via the printer port, but you’d be limited to only running WindowsXP and Mach 3, or Linux and LinuxCNC. This is because the printer port output can be affected by other machine tasks and cause your CNC machine to “lose steps” so that the actual motion is not what was commanded. Only WindowsXP and Linux are stable enough to let your machine do any extensive cuts (>5 minutes or so) using printer port output. I’ve tried with Windows 7 and it just doesn’t work, and newer versions of Windows only make it worse. If you run WindowsXP you’ll need Mach 3, but if you run Linux you can save the Mach 3 dollars by running LinuxCNC (free).

If you want to run any other Windows operating system you’ll need the Ethernet SmoothStepper or equivalent to “bridge” between computer and CNC machine. If you go that route, you may as well get Mach 4. That said, I think your understanding of the SmoothStepper is lacking. The SmoothStepper uses a dedicated Ethernet port on your CNC-dedicated computer. You’re “not on the network,” but just sending output to the SmoothStepper (and receiving input from it) via the Ethernet port. If you want to be on a LAN, you’ll need a separate Ethernet port to connect to your hub/switch/whatever. Unless you’re running a SmoothStepper or equivalent, you DO NOT want your CNC-dedicated computer to be on a LAN, wired or wireless – the CPU activity to service the LAN will cause you to lose steps and your cut part will not match your expectations.

Finally, regarding CAM software. I much prefer to keep the CAM inside Rhino. Exporting to Fusion 360 and such is a pain. I prefer MadCAM over RhinoCAM because the former is “transparent.” By that I mean the MadCAM-generated toolpath output is stored right there in your drawing file as Rhino drawing entities (on its own layers) and you can edit the lines and copy them and move them and stuff like that all you want. RhinoCAM makes all that invisible by (apparently) storing toolpath info as invisible user data somewhere within the drawing file. You can see the toolpath in your Rhino drawing, but you can’t touch it or edit it. RhinoCAM makes some really nice toolpaths, true, but that one day when it just won’t quite put the tool where you want it to go will vex the heck out of you. Then you’ll end up learning to manually edit G-code (you’ll end up learning that anyway, eventually) but you’ll not want to manually edit thousands of lines of G-code for that one instance when a whole slew of step-over points just won’t quite line up to give you that cool Guilloche-like tooled look on your finished product that you wanted. But, in MadCAM, you can just draw your toolpath directly on the part surface using standard Rhino drawing tools to replicate it those thousands of times, then offset it above the surface appropriately for the particular tool you’ll be using and edit it into a MadCAM toolpath to replace the MadCAM generated toolpath with your own. Boom! Much more elegant than editing G-code, and you can see what you’ll get as you work.

Some caveats about MadCAM: It sometimes makes your “rapids” at the wrong height – those times when the tool is simply repositioning but not supposed to be cutting anything will occasionally be placed too low in height to clear the intervening part resulting in an inadvertent cut and possible tool breakage since the machine is rapidly translating and crashing the tool into the part at greater than desired cutting speed. This is easily fixed using standard Rhino drawing tools to edit the toolpaths, but adds an all-too-easily forgotten step to your workflow. Also, MadCAM is a one-man-show software house, and Joakim seems to have no timeline for addressing bugs, flaws, or customer complaints. YMMV, but I think he’s getting old and tired of it. There’s been no activity since last summer.


That has not been our experience with RhinoCAM. We’ve processed thousands of toolpaths with RhinoCAM and I can’t think of a single time we had to manually edit the g-code because we couldn’t get what we wanted from the software. There have been times the toolpaths weren’t optimal, but it’s always been the result of the programmer making bad choices in settings, not the software letting us down. But we get that occasionally with our “high end” CAM software as well. Like the saying goes “garbage in… garbage out”.


Tweak the G-Code, tweak the code that generates the G-Code, tweak the settings for the code that generates the G-Code, tweak the operator who tweaks the settings for the code that generates the G-Code, it’s all the same thing.

With MadCAM, however, I can directly draw the toolpath I want. I can’t do that with RhinoCAM and for my application that makes all the difference in the world.

Not even close to being the same thing.

But whatever. If madCAM is working well for you then that’s great. I still have an interest in what happens with madCAM as I worked closely with Joakim for 9 years helping him develop it. A lot of what you have in madCAM today came from that collaboration.

We moved on to RhinoCAM because we needed more than madCAM could offer, and the pace of development slowed down to a crawl. I’m not even sure if Joakim is still working on madCAM. I have a feeling he retired and is spending time with his family, gardening, boating etc. I don’t know if it was a coincidence, but it seemed that madCAM development slowed down dramatically after his grandchild was born. Whatever he is up to these days, I wish him the best.


1 Like