ColorCNC Colorlight 5A-75E/5A-75B as FPGA controller board

Everybody can now contribute to Litex-CNC by adding new, customized, modules to the eco-system. I've made a cookiecutter template which prepares all the boilerplate code for you. Just add the driver logic and the firmware and you can use the new module alongside the exisiting modules. 

Quickstart
Install the latest Cookiecutter if you haven't installed it yet (this requires Cookiecutter 1.4.0 or higher):
Generate a LitexCNC module template:
Then:

• fill in the requested data;
• open the project in your favorite IDE and start hacking.

By default you can directly use the driver and firmware, as the template will compile without errors. However, as there is no logic inside the module, it won;t do anything. You can try things out by printing something out to the shell.

Usage in HAL
Both the firmware and driver are automatically picked up in the CLI commands, it is unfortunately not yet automatically available in HAL. To register your new module in HAL, you have to explicitly load it, e.g.:  

This behavior might be improved upon in the future.

Want to try it out?
Great! But Litex-CNC is under development and so is the template. Feedback is welcome!

As long as Litex-CNC is not yet on pypi.org, one should use the following command when using the template:
This will modify the setup of the template to use the branch which supports extending Litex-CNC with new modules. Happy hacking!
 

What kind of modules have you in your mind?
Like hal components? Or what is the purpose for these modules?

I tried to start in my virtual machine and got this....

 full_name [Peter van Tol]: peter
email [peter.van.tol@example.com]: peter@gmx.de
module_name [Litex-CNC module]: test_module
module_slug [test_module]: test_module_slug
version [0.1.0]: 0.1.1
module_short_description [Module Boilerplate contains all the boilerplate you need to create a Litex-CNC module.]: description
fingerprint [0x923e1bd0]: 0x923e1bd0
Traceback (most recent call last):
  File "/home/oj/.local/bin/cookiecutter", line 10, in <module>
    sys.exit(main())
  File "/home/oj/.local/lib/python3.7/site-packages/click/core.py", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "/home/oj/.local/lib/python3.7/site-packages/click/core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "/home/oj/.local/lib/python3.7/site-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/oj/.local/lib/python3.7/site-packages/click/core.py", line 760, in invoke
    return __callback(*args, **kwargs)
  File "/home/oj/.local/lib/python3.7/site-packages/cookiecutter/cli.py", line 207, in main
    accept_hooks=_accept_hooks,
  File "/home/oj/.local/lib/python3.7/site-packages/cookiecutter/main.py", line 120, in cookiecutter
    accept_hooks=accept_hooks,
  File "/home/oj/.local/lib/python3.7/site-packages/cookiecutter/generate.py", line 351, in generate_files
    unrendered_dir, context, output_dir, env, overwrite_if_exists
  File "/home/oj/.local/lib/python3.7/site-packages/cookiecutter/generate.py", line 205, in render_and_create_dir
    name_tmpl = environment.from_string(dirname)
  File "/home/oj/.local/lib/python3.7/site-packages/jinja2/environment.py", line 1105, in from_string
    return cls.from_code(self, self.compile(source), gs, None)
  File "/home/oj/.local/lib/python3.7/site-packages/jinja2/environment.py", line 768, in compile
    self.handle_exception(source=source_hint)
  File "/home/oj/.local/lib/python3.7/site-packages/jinja2/environment.py", line 936, in handle_exception
    raise rewrite_traceback_stack(source=source)
  File "<unknown>", line 1, in template
jinja2.exceptions.TemplateSyntaxError: unexpected '}'

Did some bughunting and the last commit a } was missing. The error description was not very clear, so it took some time to find the error. With the latest commit it should be solved.

The goal of this template is to make extra modules easier. The two projects I have now in mind:

• toolerator. Basically a port of an old project for my Emco 5 turret. The caroussel component still requires some work to get it working, so I decided I want to send a tool number to the FPGA and it selects the correct tool.
• hy_vfd: A little more far fetched, as my current mill does work well, but I just want to have less cables.This module should offer the same functionality as the component with the same name: sending commands to a HuangYang VFD. 

Nice.
I also would like to have a serial port on the board. With a rs232 to rs485 converter I send commands to my VFD.
Wrote a hal component for my Mesa 5i25 and it works good.
On my 7i96 I get warnings, because the hostmot serial driver seems to have some problem over ethernet....

I would be more then interested if such a component / module is available for LitexCNC as well. For me, the VFD is secondary priority now, as I want to finish the Emco5 first. 

Thanks to the power of Python (or OOP in general), I was able to re-use large parts of the stepgen module for the toolerator. I have added a position mode to the stepgen. In this mode the stepgen will move to the commanded position while adhering speed and acceleration limits. In this mode it is not required to (ab)use the motion planner of LinuxCNC. The accuracy of the position mode is depending on the acceleration of the stepper motor. The motion is stopped whenever the error is smaller then 5 times the acceleration per clock cycle. When using an acceleration of 200,000 steps/s² and a FPGA clock speed of 40 MHz, the accuracy is within 10E-7 steps!

A caveat is that changing from velocity to position change (if required) can only be done at stand-still, or otherwise the movement might overshoot a little (10E-4 steps) the first time the stepper comes to a standstill. This overshoot might trigger an extra step.

When a tool change is requested, the toolerator:

• translates the tool-number to a position in the turret, this position is send to the FPGA;
• based on the current position of the turret, the turret will move forward to the new position plus some amount of overtravel;
• to lock the tool in place (it is a ratchet type), the tool changer is moved backwards;
• when the turret has stopped moving, the tool change is reported to be ready.

This means that all the heavy lifting is done by the FPGA and the motion planner is not bothered by this addition. When simulating this design (the driver is not ready for testing), the profile generated is given in the picture below.



I believe that this module gives some possibilities to create programs with the FPGA, not necessarily tied to LinuxCNC