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

Hello Peter.
Get github.com/Peter-van-Tol/LiteX-CNC branch envoders and commit 66133fb94c625df9d0f9fedc6b5239ec517e1d84
Make build test system for i386.
Work ok ! BUT! the movement of the motor is somehow "torn", not smooth.
And the system resource usage is very high, the Fabio driver consumes much less.
Tested on the same computer.
Computer configuration:
RAM DDR3 16Gb,
CPU i3-4130
Video card onboard (Intel)

With Fabio driver motor running very smooth without any "torn"

If I look carefully to your video, I see two problems:
- the motion is not fluent;
- when an error occurs (for example due to joint follow error), the motion is not stopped, but it continues to move.

It looks like the communication is not optimal between the FPGA and the LinuxCNC. This means updates of the position are missed by LinuxCNC and the motion is jerky therefore. Another explanation is the high CPU usage, which may lead to the GUI being 'paused'. The only way to confirm this is too actually attach a motor to the system. I use myself another GUI (gmoccapy) on a way less powerful PC and didn't experience this. My suspicion is that this behavior is due to the calculations required by the stepgen. Can you try whether having only 1 stepgen solves the jerky behavior? If so, I know which part has to be revised.

The lack of communication will also result in joint follow errors, after which the card should be stopped. Will investigate why the card is still commanding movement.

PS: the driver should also work on a 64-bit system now.  

Hello Peter
As I wrote earlier, I just have the motor connected. And jerks on the screen coincide with jerks on the engine.
I've tried different GUIs: gmoccapy, axis, qtvcp axis. Everywhere the behavior is the same.
Moreover, if I use the Fabio driver and firmware, everything moves smoothly, without jerks, with any GUI, qtdragon also tested.

Also with the Fabio driver, the CPU usage is much less.
On a 32-bit system, this is noticeably even stronger.

Update: After 11 runs of the 3D_Chips program on a 32 bit system, the driver went into the same uncontrolled movement as in the 64-bit version.

Hi, about packet loss behavior, you can try to raise the value of Lcnc.00.tx-max-retries, this Is the Number of missing packets that Will trigger the board self disabling. Default value Is 5, you could set it to some value higher than timeout, for example 100.

Update: Due to complaints on speed and stability, I've made some changes in the stepgen algorithm (aims at solving both uncommanded / wrong movement and jerky motion). Also added now timing on all components to find out which function causes a high CPU usage. Tomorrow I'll be able to test it on my FPGA whether it works and will share the timing results. Feel free to test it earlier.

muvideo wrote:

Hi, about packet loss behavior, you can try to raise the value of Lcnc.00.tx-max-retries, this Is the Number of missing packets that Will trigger the board self disabling. Default value Is 5, you could set it to some value higher than timeout, for example 100.

Ok, i change it to 100000.
Result the same
I try to remove cable from board for 0.1-0.2 sec
100000 retries for 10 sec, i'm right?

100000 should last about 100s before reset, but I've never timed this, I was more interested in the number of consecutive Lost packets. In this scenario the watchdog will bite for sure way before the 100s, depending in how it is configured.
I've noticed that if I disconnect briefly the cable, the connection Is fully restored only after several seconds, and I dont know why.
Maybe in the next iteration I should introduce better error messages so that the reset reason will be more clear.
My machine Is now fully cabled, I'll soon be able to test the sw on actual hardware.

Video

Just did some timings on the LitexCNC-driver. It was not the stepgen causing the problems, it is the communication with the board which consumes most of the time:
It is the communication with the board which takes up most of the time (reading takes up to 25% of the cycle time). Lets focus on bringing these numbers down (without incurring package loss).

Edit:
Some additional timings from the etherbone protocol:
OK: I can optimize the creation of the packet (this very slow given the little complexity it has), but the real pain is in the sending and receiving the data from the FPGA. 
 

Well, if I understand you correctly, given numbers must be divided by 1000 to calculate time per cycle.
There are some unpredicted delays: time that is needed for travelling of packet across the Linux network stack - between "send" call and actual reception of packet in FPGA and in the opposite direction