Skip to main content

Introduction to Kynetic CNC

  This project started as a result of the the wildly successful Teensy 3.5/3.6 kickstarter.  At the time I was amazed by the specifications of these microcontrollers and thought, "With all of that processing power, could I create from the ground up a completely new 32bit 3D print engine that would improve upon the capabilities of the current 8 bit printer controllers?"  Soon after that, I started making notes about how I would do motion control if not limited by the power of the processor.
  After two years of part time work on this project (I have a full time job and full time family),  I'm now ready to discuss the details and where it is going.
  After that brief introduction, here's the current capabilities and future improvements:

  • All of the core functionality in Kynetic has been written from the ground up to avoid compromises inherent in most current 3D print engines that are either running on 8bit hardware or 32bit hardware running code that was originally designed for those slower microcontrollers.
  • Constant acceleration trajectory planning with look ahead is fully functional
    • In the near future I will be moving to a minimum-jerk trajectory planner to make movements even smoother
  • Look ahead for trajectory planning can work up to 100 lines of program ahead to insure smooth moves even if printing at high velocity on a extremely tightly tessellated models.
  • Intelligent motion smoothing to reduce vibration when cornering while maintaining geometry fidelity.
  • Stepper pulse generation can generate theoretical speeds up to 600mm/s on typical 3D print hardware (although most machines are not robust enough to take advantage of speeds this high).
  • Stepper pulses are generated using an innovative dithering algorithm that allows for increased smoothness and more precise speed output at high velocities.
  • Currently Kynetic supports these machine types:
    • Cartesian
    • CoreXY (H-bot)
    • Delta
  • Machine inverse kinematics are computed at 4000Hz for smooth motion on any machine type
  • Programs currently execute from the on board SD card
    • In the future, programs will also be able to execute from a serial connection
    • Compatibility with OctoPrint is on the to-do list
  • Beta controller hardware is functional
    • Planning has started for  a v2 controller with more features
  • Here are a couple of videos of Kynetic printing (the delta linkages rattle, so sorry about the extra noise):

  These videos are random recordings I've made as I've been testing and debugging.

  Please let me know what you think and if you have any questions.  I will try to post updates as I continue to refine Kyetic.  Currently the code is in a private Github repository, but long term I expect to make it open source.

  If you are interested in this project, please follow by clicking on the "Subscribe" link at the top or using the "Follow by Email" option on the sidebar.




  1. This is a great body of work, 2years, right??? I would love to discuss where this goes and what can be done to get it there. #bigfan

    1. Thanks Tariq! At this point in the project, there's ~5500 lines of original code. My current focus is on testing and completing core features. If there is sufficient interest, I could envision a future kickstarter to allow people to buy the hardware for retrofit into printers with legacy hardware. I'm not sure the world needs another 3D printer manufacturer for consumer level hardware, although I'd certainly entertain supplying controllers for an established machine builder who wants to add a premium option to their product offering. For now I am just working on creating a no-compromises controller.

    2. I've been doing the same thing, you do, plus autoleveling in 3 dimensions and scanning at the same time :)


Post a Comment

Popular posts from this blog

Computing Junction Deviation for Marlin Firmware

  As part of developing my own 3D printer firmware, I also keep an eye on what is happening in other firmware.  One feature that is causing confusion in the Marlin community is the junction deviation setting.  Up until recently, Marlin used the jerk method (hence forth referred to as "archaic jerk") it inherited from Grbl for computing corning speed (junction velocity).  With the option now in Marlin to use junction deviation instead of jerk, there are many people who want to know what are good settings for junction deviation to insure they get reasonable movement while printing.  In this post I will give an equation for converting the jerk values into junction deviation and my derivation of this equation.

Extra Smooth Moves

  In an effort to provide a no compromises motion controller, one major milestone is converting the trajectory planner and motion control from constant acceleration to minimum jerk.  For simplicities sake, the original Kynetic motion controller was done as constant acceleration.  I have now completed the work to make it use the much smoother minimum jerk algorithm.