CAD -> CAM -> G-Code PostProcessor -> Motion Controller -> Drives
A Motion Controller is, well, just that. A structure to control the coordinated motion of at least a singular CNC axis. Motion controllers can be software or hardware based. On the hardware side, the continuum runs from as simple as relay logic through small embedded controllers to complex machine controllers such as the Dynomotion KFLOP.
Software controllers have a distinct disadvantage running under Windows, as it is not a real-time operating system (Mach3, Mach 4). Software interrupts (caused by running other programs or a slow machine), or other normal operations run close to the performance envelope can cause buffer failures, wrecking parts. LinuxCNC runs under a real-time kernel, and as such should not experience such issues.
- GRBL (Arduino Based), GRBLShield
- TinyG, The TinyG Story, ADAfruit TinyG, G2
- Smoothstepper (USB or Ethernet)
- Dynomotion KFLOP (US Based Choice; programmable via C code)
- Planet CNC
- EdingCNC (GUI is very similar to industrial controllers, Input-Output indicators for troubleshooting, built-in feeds and speeds calculator, Conversational programming for Engrave, Pocket and Drill functions)
- Dynomotion KFLOP
Relay or ladder logic controllers only react to a dedicated set of inputs. For example, controlling the end points of travel. When reached via sensors, simply reverse travel at set speed/rates.
More advanced hardware controllers are dedicated and do all of the trajectory planning onboard with higher speed, optimized hardware. The host PC only passes the G-Code file and operational parameters to the hardware controller to execute. As an example, the KFLOP:
“uses a DSP-based microcontroller with 1.2 GFLOPs of processing power, a 100k Gate FPGA, 16 Mb SDRAM, 8 axes of control, lots of I/O and the ability to program in C and do path planning with G-Code”