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

Today some fun with the problem with the stepgen. After flattening some bugs in the code, I was getting some stability problems with the position, which happened periodically. The problem arises from the stepgen module handing off all acceleration calculations to the FPGA, similar as the implementation of the software stepgen of LinuxCNC. When going to 50 MHz the acceleration per timestep gets infinitely small, as the time component is being squared. Result is that while the driver thinks acceleration is handled by the FPGA, the FPGA sees a max acceleration of 0 and hence applies the commanded speed directly. Why does the spikes occur periodically: basically it is a combination of chance (the thread period is not really a constant) and an ever increasing error.  Note: this figure is already after optimisation of the algorithm.

 

OK: what happens if we throw in some values which make sure that the max acceleration which is send to the FPGA is not equal to 0. So, we use a relatively high acceleration. Now we see we get a relatively smooth curve. We are not there yet, as the orange line depicts the speed of the stepper engine fluttering around. The most probably cause is now in the speed prediction.

 

When flattening out the last bugs in the speed prediction it now looks reasonable. The reason for the spike at the start is that the position-cmd is directly coupled to the signal generator. So when starting, the commanded position does not adhere to any acceleration limits. The stepgen therefore has to catch up

 

The code is not yet on GitHub, because:

• needs some good cleaning up (too tired for today);
• it only works with large values of accelerations (20,000 steps/second²), this needs also to be addressed.

Today I pushed 5 commits for various reasons:

• the 50% duty-cycle for PDM on start up has been resolved;
• several errors in the Stepgen firmware have been resolved. The firmware now does exactly what the computer commands it to do; no question about it. Took some time to debug the reset mechanism. In Python it is easy to say if not ... , In Verilog ~... doesn't do the same. It is a bit-wise operator, so when one of the bits is zero, it still returns True. That was unexpected ... stems from mixing two languages together (Python / Verilog).
• the driver for the stepgen has been overhauled to resolve the instabilities of the stepper. As long as the acceleration limits are respected, the driver follows very well. As soon as there is a following error, it takes longer then my liking to reduce this error. At this moment I'm more focused on unconditional stability (thus damping) then reducing the error as quick as possible for the case where acceleration limits are not taken into aacount.
• added a flag for showing debug output of the stepgen (<card-name>.stepgen.##.debug). This shows the state of the hal-pins commanded position, position received, position estimate at the start of next cycle, speed received, speed estimate at the start of next cycle, required average speed for next cycle, match time (time required to get to that speed) and new commanded speed (including method how it is arrived.
• added a flag for debugging the data-stream between the machine and the FPGA (<card-name>.debug). @muvideo: can you set this flag  to True and see whether the FPGA sends the data to the PC when you apply your GPIO in and post the results here? Easiest way is to first start the HAL, set the input of the GPIO and then set the pin to True. Note, this will generate a lot of output on your screen, only one cycle will suffice to post here.

For the data enthousiast, the current following behavior of the stepper is shown below. All is nice and smooth.

 
 

Hi
Hope tomorrow to be able to test stepgens.
If you didnt touch anything on gpio I can anticipate you that the inputs are not being communicated from firmware.
It can be seen on the etherbone packet in wireshark, where the register field corresponding to gpio in Is stuck.

By the way, if you want to test yourself the capacity of the firmware to read an input, you can without modifying the board.
As a quick and dirty test you can probe the inputs of the buffers (side A, the ones that are connected to fpga) using a resistor,
a safe value can be 3k9 or 4k7 ohm, just connect one side of the resistor to 3V3 and GND alternatively, and with the other side
touch the right pin of the buffer, if the FPGA is configured correctly that pin will be input both from FPGA side and from Buffer side.
If it is configured as output from the FPGA then the resistor will avoid overloads. You have only to be careful touching only
one pin at time, pin pitch on buffers is tight, a magnifier will greatly help,
and connect the GND or 3V3 side of the resistor first, in order to avoid ESD.
If I remember right you have a 5A75E board, for the version 7 chubby75 github page has the listing of connections pins to buffer.
For version 8 (and 6) I can help you locating the right buffer in relation to pin.

Now I'm going to mod my 5A75E in the same way of my 75B.

Fabio

@TOLP2
I tried with new implementation of stepper, there is something I must be doing wrong,
I see only garbled numbers coming from counts and position feedback.
Did you had a chance to test the stepgen on your 5a75b board? If so can you share
your hal file?
Thanks!

In my system (raspi pi4) with the latest driver, read is shifted by one register.
I'm attaching two examples here, as can be seen comparing input values
on top and register values on bottom, the gpio in is reporting the value of
the register at address 0x00000098 (MMIO_inst_stepgen_0_position)
instead of 0x00000094 (MMIO_inst_gpio_in).
Problem is 0x00000094 is still stuck at 0.

Read addresses:
 

Read values, input color, green is 1 red is 0 (top left)
here the value is 620, last 3 digits of address 98
 
the value is 89f, last 3 digits of address 98

 

That is strange. It looks like the write buffer is one too short, causing the read to start at the wrong address.

Can you share the following files, so I can reproduce:
- your config file;
- the csr.csv file describing all addresses;
- when adding the Fpga to the hall, the first few lines of the stdout. This describes the modules and memory buffers.

At this moment I only have a 5A-75E to experiment with. This error did not occur with my setup, although I don't think it is board related. Has to be solved.

Hi
this is the console output, in attachment the files you requested, board is 5a75e host raspberry pi 4




 

@muvideo
Hello. What 5a-75e board version you have?
I receive on this week 5a-75e v8.0 and 5a-75b v8.0
 

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.