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

"Your pull request will be more then welcome to help with writing things down!"
I've created the pull request here:
github.com/Peter-van-Tol/LiteX-CNC/pull/2

Kind regards,
Cedric

I will look into the merge request and will definitely cherry pick some components from it.

Small update: At this moment I'm designing an S-curve planner for the driver, because I was not happy with the smoothness of the current driver. What does S-curve mean? At the end of each cycle the stepper will run at the commanded velocity (calculated as the velocity to get from the old position to the new position). Any error will be corrected by accelerating faster and slower during a part of the cycle. For small errors this can be obtained within one cycle, for large errors the cycle will be stretched.

Another reason to re-write the driver is speed and readability of the code. It is much cleaner now and there are less corner cases as the formulas used will be all physics and areas of triangles. There is however one square root to solve when the error gets too large, bu I accept that for now as it runs faster then the previous version.

Before I push this new driver, there is one problem to solve: the calculation blows up when jogging and a constant speed is obtained (possibly a division by zero error). But the acceleration phase is smooth as a possibly can be.

I have expanded the README some more [1]. It now also has the instructions on compiling the firmware for the FPGA.

I also reworded the intro, so it's more clear that it acts as a bridge between a computer running Linux CNC and the hardware inside a CNC machine.

I have just received my FPGA board and a couple of programmers, so I can now test and document flashing the FPGA.

[1] github.com/Peter-van-Tol/LiteX-CNC/pull/2

I came across this module. [1] It consists of a TM1638, buttons, LED's and 8 LED's digits. it would be nice if the FPGA could receive the current position from linuxCNC, and display it on a couple of these displays.

After a bit of searching, I found some information on the communication protocol [2], and 2 Verilog implementations [3],[4]

Is it an idea to add this driver to LiteX-CNC?

[1] nl.aliexpress.com/item/1005002010612236.html
[2] www.electroschematics.com/tm1638/
[3] github.com/DelboyJay/TM1638_FPGA
[4] github.com/alangarf/tm1638-verilog

One can directly include verilog source, like it was done in initial version

Please feel free to make add / contribute to the code. If the referenced module is standard, then the driver should not be too difficult, just send 8 bytes for the digits and 1 extra for the LEDs. The buttons can be labeled as GPIO_ext inputs. I can create the driver module also, but I don't have that specific board laying around. The verilog can be indeed imported.

In the meanwhile I have been busy updating the stepgen. Yesterday finally found the bug which was frustrating the test. The designed stepgen is an S-curve profile for each cycle. Means within each cycle is a acceleration and possibly a deceleration phase. The latter phase was never activated. As I found finally out, the apply time of the second phase was written over by the new data of the next cycle.

Does it work now? Unfortunately, still not as smooth as I wanted. Things to do before I commit:

• restarting the board must ensure standstill. In some very specific circumstances (Linuxcnc crashes) it needs a power cycle before restarting Linuxcnc.
• there is still some minor following error which should theoretically not there.

Update:
The uncommanded motions have been resolved by setting the apply_time on reset to MAX_INT and stop the motion. Now it is safe to restart LinuxCNC in any case. The following error has been boiled down to a difference in the actual period of LinuxCNC (and any possible jitter around it) and the number of clock cycles of the FPGA. Om average the FPGA is a little faster then the computer, leading to compensation happen all the time. Now the timing of the stepgen is determined by the clock-cycles of the FPGA. Going to test tomorrow and push these changes.

Good to hear that the code is progressing nicely.

I have now successfully flashed my FPGA board. I'll add that to my push request.

Keep up the good work, and thank you for creating exactly what I was looking for.

I have received my Colorlight 75e card. it has hardware version 8.0. LiteX doesn't know about the connections between the FPGA and the headers yet.

Therefore I am planning to build gateware that outputs an unique pattern on each pin of the FPGA. Therefore I need a file that describes the physical connections from the FPGA die to the balls on the FPGA package. Do you know where I can find such a file (or how I can make one)?

DePrutser wrote:

I have received my Colorlight 75e card. it has hardware version 8.0. LiteX doesn't know about the connections between the FPGA and the headers yet.
 

Please use v6.0 definition for 75e v8.0

How can I guarantee the hardware definition for v6.0 are completely valid for hardware version 8.0?