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

romanetz wrote:

I'm not sure if I use the latest version.
Yosys 0.16+61 (git sha1 c785cb7fe, clang 10.0.0-4ubuntu1 -fPIC -Os)
nextpnr-ecp5 -- Next Generation Place and Route (Version nextpnr-0.3-14-g20cfafa1)
Project Trellis ecppack Version 1.0-496-g7454564

Info: Max frequency for clock                 '$glbnet$crg_clkout0': 43.53 MHz (PASS at 40.00 MHz)
Warning: Max frequency for clock '$glbnet$eth_clocks_rx$TRELLIS_IO_IN': 116.63 MHz (FAIL at 125.00 MHz)
 
 

It looks like your are partly ahead of my setup and with the packing tools you're behind:
More important, yours works, mine not. Have to improve the version of the software to see whether it has impact. Thanks for the versions!

Edit:
After trying some versions of oss-cad-suite I've found one which is stable. I included this one in the command-line tools of LitexCNC, so it can be installed by any user. With this version I could compile the firmware during lunch. The timings also look much better now:

I noticed such a strange behavior of board: it accidentally stops to respond to incoming packets. Even for icmp. Unplugging with following plugging of ethernet cable recovers normal operation.

What is the period of your servo-thread. Maybe there is a clash of packets somewhere, which causes this behavior. Slowing hings down might help.

At the moment soldering the first BOB for the 5A-75E, so I can connect a proper stepper driver and some outputs to test it.

Edit:
Assembled the stepgen differential board. Turned out that the BOM was incorrect (74HC85 should be 74HC86) and the decoupling capacitors were missing. Updated this in the repository. Also changed the layout a bit, so the silkscreen can be read when IDC headers are used. 

For the differential output the GND of the optocoupler was missing. Updated the design. For the prototype solved by scraping off the solder mask and connect it. 

Assembled only the status Leds so far. They do work at various voltages very well thanks to a current mirror. Tonight checking whether the whole output works... 
​​​
Edit 2:
Mixed up drain and source of the P-channel. New batch ordered. Problem is not the cost (2 Euro), but the delivery time (12~18 days). Gives more time for fixing the reported issue. 

Servo-thread has period 1 msec

That does not sound outrageous. My computer is doing now 2 ms from the top of my head, because it is an old machine.

Did you run any GCode while doing this (to exclude motion as one of the causes)?

There is code in de driver to wait and / or remove packages if there is a UDP queue, but it is not used now. The freezing of cards was solved, removing the necessity of these routines. I can turn them on again.

Also identified some solutions to speed up transmission (some arrays are copied over and over again). This gives some slack to put the routines back in with too much impact on timings.

Even jogging fails to run, no g-code was processed. Even throug halrun I couldn't make it work.

Hello, another inch forward for my implemetation:

•   Lcnc master
• the driver now can handle up to 4 boards, you'll need a gigabit ethernet switch. In theory many more boards could be handled, but honestly I'm not sure how useful is to increase this number, if someone wants to try just set
  Code:

  #define MAX_CHAN 4 in Lcnc.c to the number you want
• the ip address and port now are parameters at hal invocation, so no need to rebuild the driver to change ip and port, added also a "debug" parameter. Example:
  Code:

  loadrt Lcnc ipaddr="192.168.2.50","192.168.2.51" ipport="1234","1235" debug=1
  "debug=1" will add some verbose output and a series of pins that report the time in ns that each part of the code is taking, of these T1 and T6 correspond to two calls to eb_send function, and are the most time consuming.
• A raspberry pi 4 seem capable to handle two colorlight boards at 1ms Thread with sufficient stability.
• stepgen step and direction timings are now expressed in ns instead of us.
• In the attachment the timing I'm seeing with 2 colorlight 5a-75b boards, on the left the one with 14 outputs 11 inputs 6 stepgens 6 encoders 6 pwm, on the right the one with 26 outputs 23 inputs 6 pwm. Seem that also the fpga configuration is having an impact on timing. Some sporadic task overrun are still there.

Ciao!
Fabio

@TOLP2 How to use the driver with right-in-place installation, i. e. linuxcnc built from source?

 

muvideo wrote:

Hello, another inch forward for my implementation
 
Fabio, I tried your configuration. In purpose of reducing time for testing, I flashed pre-built firmware from Lcnc/prebuilt_firmwares/75e_v6_v8_30o29i9s9e8p/. The board responds to ping at desired ip 192.168.2.50
In order to run machine configuration with my r-i-p installation of Lcnc, I've built the driver without any issues. Then, an error in configuration has been found: loadrt Lcnc ipaddr="192.168.2.50" udpport (not ipport as mentioned in documentation)="1234". Well, after making some changes to match .ngc files location, i got a final error. When I jog the axis towards (say, X+ or Y+) results in decreasing of proper coordinate, therefore I get a joint following error. Looks like somewhere commanded speed is been inverted.
Upd. the reason was that acceleration limit was not set in the configuration. After adding of these llines "setp Lcnc.00.stepgen.02.acc_lim     [JOINT_0]STEPGEN_MAXACCEL" for all of corresponding axes, the configuration has run successfully.
 

   
My v7.1 board is not enabled