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

Hi, I have v8

@muvideo
Can you share pinout config if different from any existing?

@TOLP2
I have strange error with loading driver

---

svb@LiteX-dev:~/CNC/LitexCNC-e2/examples$ halrun
halcmd: loadrt litexcnc
Note: Using POSIX realtime
litexcnc: Loading Litex CNC driver version 1.0.0
halcmd: loadrt litexcnc_eth config_file="./75b_cut2.json"
litexcnc: loading litexCNC etherbone driver version 0.02
litexcnc: Connecting to board at address: 192.168.2.151:1234
rtapi_app: caught signal 11 - dumping core
<stdin>:2: waitpid failed /usr/bin/rtapi_app litexcnc_eth

<stdin>:2: /usr/bin/rtapi_app exited without becoming ready
<stdin>:2: insmod for litexcnc_eth failed, returned -1
halcmd: show
Loaded HAL Components:
ID      Type  Name                                            PID   State
     7  RT    litexcnc_eth                                          initializing
     6  User  halcmd188820                                    188820 ready
     4  RT    litexcnc                                              ready

---

I'm run this from VirtualBox environment.
All other drivers including MESA running OK.
With this driver i'm have core dumping.
Now i build image for OrangePi4 and try to run from it.
Also if i run modified halcompile, for unknown reason drivers making without linking libjson-c. Halcompile from your repo.
For building i copy Makefiles to folder with driver source and modify it by hand, after that driver linked with library.
My distribution is a Ubuntu 22.04LTS and kernel 5.18.0-rt11
LinuxCNC v2.9.0pre

litexcnc_eth (and litexcnc_debug also) starting, send and receive 1 packet from board, and panic.

For a now i try on 5a-75b v8.0 board.
 

Hi, the pinout I'm using with 5a75e V8 Is the default 5a75e v6

@muvideo: It is indeed the case that the write buffer in your case is too big, causing a shift in the data read from the device. The suspect is the encoder you added in the config file. The encoders are not finished yet and not tested either. Can you try to remove the encoders from the config-file and recompile both the firmware and the driver.

Edit: I have updated the algorithm of the stepgen's to get more smooth behavior when the acceleration limit is not obeyed by the motion planner (or you're using not a motion planner, but siggen instead). I tested it with a square wave from siggen and it looks very smooth. Basically, as soon the stepgen cannot follow the commanded position, it will set the `catching_up` flag. The speed is increased using the maximum acceleration (97.5% of maximum value, a small overhead is kept for catching up with small deviations from the perfect path). The speed is increased until the maximum speed, which is based on the error and the time it takes to take to decelerate to the normal speed (to prevent overshoot). The resulting graph is now as shown below.

 

Edit 2: Fixed the last overshoot

@svb: The error you see is most likely not the cause of the json not being linked. I think that when the packet is received, something is not up to the liking of the driver. An error occurs in the the error handling.

Could you please do the following:
1) ping the board to make sure it can be reached (the ping command is outside halrun);
2) if possible, try to use LinuxCNC 2.8.x. This would help me in the further development. As it works under 2.8.x, but not under 2.9.0pre, I have to modify the code for the coming release.
3) share your configuration, so I can try build it here and try to get the same error.

TOLP2 wrote:

@muvideo: It is indeed the case that the write buffer in your case is too big, causing a shift in the data read from the device. The suspect is the encoder you added in the config file. The encoders are not finished yet and not tested either. Can you try to remove the encoders from the config-file and recompile both the firmware and the driver.

 

I'll do, a pair of questions:
1- Should I recompile the driver? If I understand the workflow, driver should not need to be recompiled in case
I change the json configuration, am I correct? otherwise there is something basic I'm missing.
2- I'm also working with 2.9 pre, so this is a problem, right?

Edit: removed encoders, behavior is the same, maybe I should start with a simpler configuration under 2.8 and
then increment the complexity step by step.


Thanks