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

Sorry for not responding a while, but I had serious trouble to get my testing system up and running. Docker on Windows doesn't allow correct routing of UDP packets from containers to the outside, spent too much time discovering that.

Second attempt was to use an old Raspberry Pi. After installing Raspbian, LinuxCNC, etc I found out that it only has 100 BASE ethernet (Fast Ethernet) and that this is incompatible with Gigabit ethernet. Thus the 5a-75e cannot be used on old Raspberry Pis directly, only model 4 will do the trick.

Anyway, just installed a gigabit switch and we can go forward again. The old Pi can communicate over the network with the card now using this switch. Not ideal for real-time behavior I think, but I can start testing now too...

First project with hot air reflow soldering replacement buffers was a success! I was able to replace 6 of the buffers on the 5A-75E board mapping to the first few connectors which will be designated for inputs in my setup. I am going to give the board a thorough inspection before powering it up to make sure I have no shorts or weak joints. Also as noted before will be needing to feed the board with slightly less than 5V (somewhere around 4.2V) using a buck converter so that the voltages exposed to the FPGA directly are within spec.

Progress Report:

I got my Colorlight 5A-75B V 8.0 working with a (modified) romanetz version ( added a magic and version info as well as a watchdog to stop the machine in case of a loss of communication).

I don't think that the buffer size is the problem. It works with sizes of 200 as well as 1100.

Initially I had stability issues with the romanetz version. The Colorlight card did suddenly not respond anymore.

The main reason for stability issues seem to be unsolicited incoming network packets. I did a lot of testing with wireshark to monitor the packets on the wire and noticed quite often ARP or mDNS packets just before the crash. These packets do not crash the Liteeth core always. But it seems that they can come in a monent which screws up the core.

I got mine working for hours now after
- using a direct ethernet cable between my Rapsi PI4 and the Colorlight
- turning off the linux ahavi daemon (which sends mDNS packets to the Colorlight)
- setting a fixed ARP entry for the Colorlight on the linux side.

Disable ahavi:
sudo systemctl stop avahi-daemon.socket avahi-daemon.service
sudo systemctl disable avahi-daemon.service

Use static ARP ( once after restart):
sudo arp -s 192.168.1.50 10:e2:d5:00:00:00


One more remark: The stepgen.v ( the 3,5 KB version from the romanetz verison) does works nicely, when the lines referencing the debug field are unkommented in the python file. As is, the stepper will only move in one direction. ( Don't as me why...,)
 

Regarding SMD desoldering: I have changed 3 buffer ics to CBT3245 using that "magic" alloy described here:


The chipquik "SMD1 NL" alloy + flux is available from amazon, at least in my country. 

Thanks for sharing! Good finding about the board locking up, it was on my home network during my test so was certainly subject to other packets/probes hitting it. I will do more tests with it directly connected next time.

Do you have your modified files available to share with the group?

@Inga Thank you very much for the finding about the stability problem. Just today I was trying to understand this strange behavior.
This could also be notified to enjoy-digital of litex
for troubleshooting from their side.
I've enabled the support for encoder inputs,
as soon as I'll complete some testing I'll share my edited files.

I'm still plagued by periodic disconnection, anyway I'm uploading my files for who
is interested in playing with encoder inputs.
- Board is 5A75B V8.0
- U9 U12 U15 ic's are replaced (or I-O pads shorted, your preference) for the inputs connection
- I've attached the input/output map in an odf file
- I've attached a PyVCP panel for quick testing the connections
- I've replaced encoder design in original file, my encoders are only quadrature AB, no index input
- Didnt test well stepgens, didnt change their implemetation, but there is something fishy about their behavior
- inputs outputs and PWM seem to work ok
- 12 inputs
- 12 outputs
- 3 PWM
- 6 AB encoder inputs
- 6 step generators
- c and h files for the drivers have some edits for encoder interface
The code is probably broken in several ways, not trustable yet.


 

Next steps would be
- have a similar set of files for 5A75E V8.0 board
- solve disconnections from ethernet (this is a show stopper for any real world use)
- validate stepgens
- test on actual machine
- clean the code once it is working

Hi cncwhacko,

as requested: please find the modified files attached.

I'm still testing, so do not use with real equipment.

Make sure, to connect directly to the host and turn off any ARP or mDNS messages from the host to the colorlight card.


** UPDATE: Colorcnc.c itself does send two packets close to each other. It first sends the data from linuxcnc to the card and then immediately requests input data with another packet. Linux usually sends them immediatly ( so there is a small time gap between these packets on the wire) but sometimes linux delays the first packet and sends them close to each other. This seems to be a problem too.

There is already a (commented)  "DELAY 50" in the colorcnc.c from earlier tests.  Change it to
#define DELAY 400
This will cause a delay of 400 usec between the two packets. As the update function is called once a millisecond, this will distribute the packet sends as evenly as possible. This will not reduce the update speed of the card.

( No longtime tests by now as they take many hours. But I have seen one crash that happend right after linux sending these two packets together without the usual minimal time gap.)

Cheers,
Inga