Close

FPGA CNC control with nmigen

A project log for open hardware fast high resolution LASER

bringing additive manufacturing to the next level

HexastormHexastorm 3 days ago4 Comments

It has been a while, the last months I worked on adding motion control to the FPGA.
I ended up starting from scratch. I wanted to move from migen to nmigen and structure the FPGA code better.
A proof of concept is seen in the very rough video below;

Motors are sampled at 1 MHz. The circuit operates at 50 MHz.  The system can account for; jerk, acceleration and velocity. 

The software consists out of the following elements;
   * SPI command interface  (receives command and words, copied from Luna)          
   *  Transactionalized FIFO (buffers instruction in sram, copied from luna)
   * SPI parser (basically an extension of SPI command interface, with specifics for my                            
                        project)
   *  Dispatcher; picks up commands from the FIFO buffer and dispatches instructions to                            
                          actual hardware
    * Polynomial integrator: creates pulse train for stepper motors; basically you send the                        
                                           coefficients for the polynomial and the number of ticks in a segment.


The motor follows the path, coef_0 * t + coef_1 * t^2 + coef_2 * t^3.
The trajectory of a motor is divided in multiple segments where a segment length is typically 10_000 ticks. If is longer, it is repeated. If it is shorter, this is communicated by setting ticks to lower than 10_000. I looked into using bezier curves for motion control. The main advantage is that they are calculated on the circuit straight from actual positions using de Casteljau Algorithm. My FPGA does not have a hardware multiplier, so I didn't implement it.
At the moment, I will focus on adding the possibility for controlling the laser and "finally" do more experiments.

Code is available online, it was quite a lot of work. Especially the boring stuff which "should be easy" took a long time. Thanks go out to Kate Temkin and her work on Luna.

Discussions

Hexastorm wrote 2 days ago point

Thanks.. might be an idea for the future.. but it seems a FPGA was not used and no code is shared...

  Are you sure? yes | no

Gravis wrote 2 days ago point

Well there is the paper( http://www.roboticsproceedings.org/rss10/p42.pdf ) detailing the algorithms and if I understand it correctly then it's really just calibration and can be applied in software.  This thread ( https://discourse.odriverobotics.com/t/anti-cogging-feature/293 ) provides insight on understanding the output of their implementation of the cogging torque mapping algorithm.

  Are you sure? yes | no

Hexastorm wrote 2 days ago point

True they did write a very nice paper... which is probably more insightful than the code... thanks

  Are you sure? yes | no

Gravis wrote 2 days ago point

If you are shooting for smooth and accurate movement then you should definitely look into incorporating anti-cogging: https://hackaday.com/2016/02/23/anti-cogging-algorithm-brings-out-the-best-in-your-hobby-brushless-motors/

  Are you sure? yes | no