GreatLight CNC Machining Factory logo
CNC Machining
Rapid Prototyping
Materials
Industries
News
About GL

Get Instant Quote

FPGA-based motion control

How FPGAs Build a Flexible and Effective CNC System

A flexible and effective CNC system moves hard real-time work into programmable logic: step generation, encoder counting and I/O. This page explains where the FPGA sits, what it buys you, and when a plain MCU or a bought controller is the better call. Written for machine builders and control engineers who have to pick an architecture before the schematic is frozen.

1–4 axis loopsnanosecond jitterreflash instead of redesignISO 9001:2015
Control cabinet of a flexible and effective CNC system built around an FPGA board
Where the logic goes

What Makes a Flexible and Effective CNC System

A flexible and effective CNC system splits work by timing, not by feature list. Trajectory planning, G-code parsing and user interface sit in software. Step pulse generation, encoder counting, PWM and limit-switch handling sit in hardware that never misses a deadline. The dividing line is the one that matters: anything that must respond inside a few microseconds belongs in logic.

FPGAs fit that second half because their behaviour is defined by configuration, not by copper. You can wire 4 independent encoder counters, 6 step generators and a PWM block inside one mid-size device, then rewire them next month without touching the board. A microcontroller gives you fixed peripherals; you work around what the vendor shipped.

That difference shows up as jitter. A software step generator on a 200 MHz core drifts by tens of nanoseconds when an interrupt lands late. A dedicated counter in fabric drifts by one clock, about 5 ns at 200 MHz. On a 5 mm lead screw that is under 0.1 μm of position error per pulse, which is why the loop stays quiet at high feed rates.

The practical benefit is not raw speed. It is that adding a fourth axis, a tool probe or a second spindle costs you logic cells instead of a new control board. Machine builders who iterate on prototypes feel this first, because the electrical design stops being the bottleneck.

Inside the fabric

How FPGA Motion Control Works in Practice

The FPGA does not run the machine. It runs the parts of the machine that cannot wait. A soft core or an external CPU computes the trajectory and writes setpoints into a register map every servo cycle, typically 100 μs to 1 ms. The fabric reads those setpoints and does the fast work.

Step generation is a phase accumulator. The CPU writes a velocity word, the accumulator overflows at a rate proportional to that word, and each overflow toggles a step pin. Acceleration becomes a ramp on the velocity word. No timer interrupt, no missed edge, and the pulse train stays uniform even when the CPU is busy parsing the next block of G-code.

Encoder feedback runs the other way. A quadrature decoder counts edges, a position latch captures the count on an index pulse, and a comparator checks the count against a software limit every clock. If the axis runs past the limit, the fault output goes low in one clock cycle, well before software could react.

Interpolation between axes can also live in fabric. A Bresenham or DDA block consumes two setpoints and produces coordinated pulses, so a 2-axis arc does not depend on how fast the CPU services a timer. This is the piece that separates a flexible and effective CNC system from a board that merely drives motors.

The register map is the contract. Keep it small and documented: velocity, position, enable, fault, status. Every firmware change then stays local, and the machine integrator never has to read the HDL.

When it pays off

Fits, Limits and Real Design Constraints

An FPGA earns its place when timing or I/O shape is unusual. Examples: 4 or more coordinated axes, encoder feedback above 1 MHz, hardware fault interlocks that must trip in microseconds, or a machine that will change axis count between builds. If none of those apply, an MCU with a good timer peripheral is cheaper and faster to ship.

The costs are real. You need someone who can write and verify HDL, or a vendor IP block you trust. Place-and-route adds a step to every change. Bring-up needs a logic analyser, not just a debugger. Budget two to three extra weeks on the first board and far less on the second.

Clock discipline matters more than device size. A single 50 MHz or 100 MHz oscillator shared by all counters keeps axes coherent. Mixing clock domains without synchronisers produces occasional one-count errors that look like mechanical backlash and waste days of debugging.

Safety is a separate layer. An FPGA can trip a fault output in one clock, but that output still has to drive a hardware stop circuit with its own certification path. Do not claim a safety rating from the logic alone. In the EU, a machine stop function is judged as a whole, not by the chip that requests it.

Thermal and supply design also bite. FPGAs draw more current than a small MCU, so the cabinet needs airflow and a clean 1.0 V or 1.2 V core rail. Cheap switching regulators with poor transient response cause random configuration errors that are hard to trace.

Prototype loop

From Prototype to Production Hardware

Most teams start with a development board, prove the motion loop, then spin a custom PCB. Keep the first board close to the reference design: same device family, same clock source, same power sequencing. Every deviation you add early is a variable you cannot debug later.

For the mechanical side, the enclosure and mounting parts should be machined to the same tolerance class as the machine itself. A control bracket that flexes under vibration will show up as encoder noise in the logs. GreatLight machines such prototypes from aluminium 6061-T6 to ±0.005 mm, with 16 simultaneous 5-axis centers and a 4,000 mm maximum processing size for larger frames.

Run the loop at the final servo rate before you commit to production. If 1 kHz works but 4 kHz does not, the problem is usually clock routing or an unsynchronised input, not the algorithm. Fix it on the bench, not in the field.

Document the register map and the fault behaviour in the same file. The next engineer who touches the design will need both, and a mismatch between them is the most common source of a machine that stops for no visible reason.

Pick by requirement

FPGA vs MCU vs Bought Controller

Timing need drives the choice more than axis count.

CriterionFPGA-basedMCU-basedBought controller
Step jitterOne clock, ~5 nsTens of ns under loadVendor specified
Axis count changeReflash, no new boardLimited by timersBuy a bigger model
Encoder rateSeveral MHz per channelUsually below 1 MHzModel dependent
Custom I/OAny pin, any logicFixed peripheralsFixed terminal set
Development timeWeeks to monthsDays to weeksHours to days
Unit cost at volumeChip plus FPGALowestHighest
Best fitMulti-axis, tight loopsSimple 2–3 axisStandard machines

When to Use Which

Pick an FPGA-based design when you need 4 or more coordinated axes, encoder rates above 1 MHz, or custom fault logic; pick an MCU when 2–3 axes and standard I/O are enough; buy a finished controller when the machine is a standard platform and time to market beats unit cost.

FAQs

Common Questions

Do I need an FPGA for a 3-axis router?

Usually not. A 3-axis router with stepper drives and a 100 kHz step rate runs fine on a Cortex-M4 or a small Linux board with a real-time patch.

Choose the FPGA path when you add a fourth coordinated axis, closed-loop encoders, or a fault interlock that must trip faster than the software loop.

How much jitter is acceptable in step generation?

For microstepping at 1/16 on a 5 mm lead screw, a few tens of nanoseconds of jitter is invisible. Above roughly 200 kHz step rates, timer interrupt latency starts to matter.

Hardware counters keep jitter at one clock cycle, which is about 5 ns at 200 MHz. That headroom is the main reason builders move the pulse generator into fabric.

Can an FPGA replace the whole controller?

It can host a soft core that runs the trajectory planner, and many designs do exactly that. The trade-off is toolchain complexity and slower iteration on the planning code.

A common split keeps the planner on an external CPU and the timing-critical blocks in fabric, connected by a simple register interface.

What encoder rates are realistic?

A basic quadrature decoder in fabric handles several MHz per channel without strain. The limit is usually the receiver and cabling, not the logic.

Above a few MHz, use differential line drivers and terminate properly, otherwise edge noise will produce counts that look like real motion.

Does an FPGA design raise unit cost?

At low volume, yes. You add a configuration flash, a second core rail and a more complex PCB. At higher volume the FPGA often costs less than a comparable industrial controller.

Compare total cost, not chip price: board area, connectors, firmware effort and inventory of multiple controller models all count.

How do we keep the design flexible without endless rework?

Freeze the register map early and keep the fabric blocks small and single-purpose. Changing a block then stays inside one file.

Version the bitstream with the firmware that matches it, and record the clock plan. Most integration failures trace back to a bitstream and firmware pair that were never tested together.

Send Us the Parts Around Your Controller

Upload your control enclosure, brackets and mounting plates for a DFM review and a quote within 12 hours. Tolerances to ±0.005 mm, 100% inspection before shipment, and an NDA on request.

12-hour quote100% inspectionNo minimum order quantity

Follow

More from GreatLight

We publish setup notes, tooling trials and inspection data from the factory floor.

FacebookTikTokYouTubeLinkedInInstagramThreadsPinterest

Trusted by engineers and manufacturers worldwide

Tesla Ford Motor Company BYD Auto Denso Magna International Boeing Airbus Medtronic KUKA FANUC