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

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

It is correct that packages have to travel through the network, but that travel takes most of the time in the loop. I've cross-checked my code for the communication with the EtherBone protocol with the other drivers and there is no difference; it is implemented everywhere the same. Therefore it seems strange ti me that my driver performs worse then the others.

However, there is a remote chance that the size of the package adversely affects performance. In my case the package is larger (60 bytes of data + headers) then the other drivers (20-ish bytes of data + headers) for the same functionality. The core difference is the implementation of the stepgen, where more variables can be changed during the loop (acceleration and timings can be variable in my implementation).

Tonight I'm going to vary the size of the package to determine how the size of the package affects the speed of sending and receiving the data. two scenario's are possible:
1. The speed is linear with the data. In this case it is either accept the timings or revamp the driver to send less data.
2. The speed is non-linear with the data (i.e. exponential). In this case it might be beneficial to send several smaller packets instead of one bigger one.

We will see.

@TOLP2 please pay attention to colorlight.py, lines 43-49:
self.add_etherbone(
phy=self.ethphy,
mac_address=config.etherbone.mac_address,
ip_address=str(config.etherbone.ip_address),
buffer_depth=255,
data_width=32
)
this increases available working frequency in timing report from 43 MHz to 115 MHz in rgmii clock domain

Changing the data-size of the packets did not affect the timing of the loop that much. It will definitely not optimize the code bij splitting in multiple chunks. Setting the data_width to 32-bits seems to improve the read speed from the device, write speed is unaffected.

The timings I posted earlier are affected by the time it is required to make the timings. PWM does not read anything back from the FPGA and therefore has an empty function. I assume this function is optimized by the compiler (should really test this assumption). This gives an estimation of the time used by the timing function it self, this is in the order of magnitude of 3000000 ns per 1000 loops.

About uncommanded movement: I was able to reproduce it this evening finally. Have to investigate the cause of it further (I would assume the machine to be at standstill).

As soon as LinuxCNC runs, packets will be send to the FPGA; thus the Watchdog does not bite when the machine goes into E-Stop (why was I thinking this). This means the E-Stop should be communicated to the FPGA by disabling all movement at the FPGA (safety first).

svb wrote:

vit74vit wrote:

svb please post you hal file. I can try testing Fabio firmware

 

File Attachment:

File Name: svb-FABIO_...8-01.ini
File Size:3 KB

 




 

@svb:
I finally was able to put together a working machine around my board and the firmware.
I'm not sure about the source of your disconnection problem, but I have a pair of ideas.
Surely in future the error messaging need to be updated, because now is too crude to be
meaningful.
In the meantime I'm comparing your ini and hal files with mine, I have noticed a pair of things.

First I would strongly suggest to not use directly joint.n.vel-cmd as input for stepgen velocity command.
I have had problem with this because joint.n.vel-cmd can have some discontinuities, for example in my case there is backlash compensation.
The correct approach should be to use joint.n.motor-pos-cmd as input.
Since this is a position signal, the solution is to use a pid that takes the joint motor position as input and gives back the requested motor velocity as output.
So you will have joint.n.motor-pos-cmd -> pid.n.command pid.n.output->Lcnc.00.stepgen.nn.vel-cmd
A basic pid setup shoud be simple just to have the system going:
first order feed-forward: FF1=1 all others zero
Pgain high, but significantly lower than the value at wich the motor start self oscillating
I term some value that zeroes the residual error fast enough.
This removed the strange random joint following error that I was experiencing.

Second Is the enabling-disabling of the system, I've made it somewhat different than you,
honestly don't know if this has any influence on your system behavior, but:
in my system I'm using iocontrol.0.user-enable-out connected to Lcnc.00.enable
then iocontrol.0.user-request-enable to Lcnc.00.enable-request to request the enabling of the system.
Lcnc.00.enabled is the feedback that I'm using for powering the hardware and
(negated) used also for resetting the stepgens in case of problems.
In my case I have an input from external drivers alarm that will stop the machine and reset the stepgens also, it is ANDed with Lcnc.00.enabled.

You can use as reference the files I've uploaded here:
[url] github.com/faeboli/Lcnc/tree/master/support_files/LcncMill [/url]