FPGA CNC

When you think of a CNC controller you probably think of a PC with a parallel port or some microcontroller-based solution like a Smoothie Board. [Mhouse1] has a different idea: use FPGAs as CNC controllers.

FPGAs inherently handle things in parallel, so processing G code, computing curves and accelerations, and driving multiple stepper motors at one time would not be an issue at all for an FPGA. Most computer-based designs will have slight delays when trying to drive everything at once and this introduces some mechanical jitter. Even worse jitter occurs when you have an old PC trying to run everything when some other task takes over the CPU.

In all fairness, [Mhouse1’s] design does  include an Altera CPU on the FPGA to handle some tasks that CPUs are good at, but the FPGA allows the design to create I/O devices specifically for the task at hand. The CPU is also running an RTOS (MicroC OS II) and a Python GUI that runs on a controlling PC.

There’s an older article about using an FPGA to control a CNC machine that has a lot of good information about designing such a beast, if you are interested. However, that design is a lot less ambitious than this one. [Mhouse1] wants the controller to be machine agnostic, and he’s demonstrated it on a cheap DVD-based laser cutter as well as a modified Shapeoko machine.

If you want an introduction to FPGAs, you might want to get started with our tutorial on cheap FPGA development. Or, you can learn a lot with just your Web browser.

18 thoughts on “FPGA CNC

  1. It’s not that hard for a CPU to perform all these tasks at the same time, without any jitter. Use PWM hardware and fast interrupts to drive the steppers from a queue with straight line motions, and use a lower priority process to keep the queue filled.

    1. Actually, when you take into account the fact that you need to accelerate/decelerate the step generation, and keep them perfectly synchronized, it’s not that easy. We set the step pins to be hardware-pwm-capable on the Smoothieboard, but no-one ever figured out how to actually use that. I don’t know of any microcontroller-controlled CNC board that actually uses PWM. The PWM peripherals are not really that convenient for this.

        1. Well your main concern is going to make sure they don’t get out of sync over the course of a long move ( one axis finishing before another ). If that is taken care of, then you want them to be within a few microseconds ( ideally less than one ) of each others along the move.

          1. Why would they get out of sync ? You can calculate exactly how many steps need to be done before you start a move. And timing 3-4 axis within a microsecond is certainly achievable with a ~100 MHz ARM Cortex.

          2. On Smoothie, in my opinion the axis loss of synchronization is totally a software bug. Many ways to fix that, too bad my simple one was considered too hacky.

            But that still gets you only within the 10us step ticker resolution. Microsecond precision on LPC1768 would be quite hard due to the lack of timers – on STM32 or similar with plenty of timers one could get rid of the step ticker completely and only update the timer registers at lower freq.

        2. PWM is great for regular pulse stream, but if you have to synchronize several motors, you have to have several PWMs be pulse-synchronized. As long as you are not touching their settings, they will run synchronized, but when you change their settings, the PWM units’ autonomy actually gets in the way.

          Say you want to slow down one motor: you write new parameters, but how do you know where in the cycle the PWM was–was the pulse for this cycle already out or not? I don’t believe you can control the update timing vs. the output pulse timing—so when you update multiple PWMs you’re basically in a race condition.

          There may be some clever way of doing it, but as Arthur is saying, it’s not simple.

    2. Sure, you CAN do anything in software. But there are many software implementations that are sub-optimal which doesn’t mean you can’t write better software. However, when you have your 15 year old PC with a printer port running Windows, the quality of your software isn’t even the real issue.

      I’m not asserting that it is not possible to write good software. I’m saying that this is case where the FPGA’s inherent parallelism fits well. Think about, say, logic analyzers. You can make a logic analyzer with a computer. If you try to do all the logic on a Windows box, you’ll struggle. If you try to do it all under an RTOS, you’ll have better luck, but still have a few issues. But doing it on an FPGA is an easy project.

      It is possible the approach here, could be easier than trying to get it all running on a CPU–especially since there is a CPU with an RTOS on board to handle the heavy lifting. If you think about it, he’s using the approach you suggest: a CPU with dedicated peripherals. He just makes his own peripherals instead of selecting an off the shelf chip that has the blend of what he wants. Plus he can add and modify those peripherals at will.

  2. It will surely get better performance than one 8bit PIC tasked with “driving everything at once” , but wouldn’t this solution be excessively expensive? Wouldn’t you get better performance at lower cost by simply using one $0.50 PIC per motor. The PIC has an ECCP module which simplifies stepper motor control to simply modifying one 16 bit register.

    This ECCP is essentially an analog solution which gets better performance than even the FPGA … in regards to handling the actual motor stepping of one motor. The module frees up processing time that can be spent doing things like monitoring current and ramping. All that would then be needed is to feed the PIC a sync clock and a list of coordinates from something like an ARM which is outputting a sync clock for each PIC/driver. Overall it’s a comparatively cheap solution.

    The smoothie board looks like the thought process was to throw horsepower at a problem. This FPGA thing feels the same.

    1. I agree. I feel it’s more practical to let a single microcontroller do the stepper/closed loop control for each motor. One can just design a single axis controller that accepts the typical step/direction input and let a different processor handle the motion planning, pulse generation and communications through an ‘exotic’ interface, without having to do much more work to add more degrees of freedom to your machine.

    2. What sort of clocks are these pic’s going to be running at once you get into servo’s and linier scales where you need to read multiple encoders and make decisions based on the feedback, needing to compensate for the different accelerations of the different axis’s while looking up the lead screw mapping’s for it’s access & how are 8 bit pic’s at FP64 calculations?

  3. The problem isn’t jitter, that’s been solved many ways. Grbl, Mach3, linucCNC etc have solved that with their own implementation. One of the biggest issue is constant velocity (CV) and anti- jerk implementation that works well. LinuxCNC 2.7 has a new CV that I haven’t tested yet. I use Mach3 and its CV sometimes ignores your max acceleration limits. GRBL is ok but at high speed it rounds corners to much. My CNC has a heavy gantry and is capable of moving upwards of 400+IPM. It’s hard to come close to that speed most of the time because the gcode is made up of short line segments and you get a machine gun effect that literally shakes the table. Good look ahead CV will try to smooth the gcode so the CNC can operate as intended. There has been a lot of work lately in linuxCNC to make it better. Still I don’t think it comes close to what the big industrial CNC’s like HAAS or Mori can do. Those types of machines can operate at 1000+ IPM, moving hundreds of pounds and still accurately position and stop less than .001″ error without tearing the machine apart. All at super high acceleration and velocity. Pretty amazing actually.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.