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

Last test: GIT 22ccd7e4cd96a423b927e0bd33cd00f54fc9fcac
Recompile firmware and driver
Motion fading in video is not a rendering issue, it's a real motion interruption

Video


Screenshot terminal window

 

With Fabio's driver and firmware everything works fine if there is no ethernet packet loss. More than 4 hours of continuous operation without a single failure. I'm run flood ping to board from 3 terminals and all work fine.
I'm connect motors on Y, and test on real hardware.

From time to time packet's lost (i'm don't know why) and all stopped. But NO MOVING after error!
 

Can you point to these versions?
Standard behaviour of of-the-shelf products is to ignore packet loss until timeout has been occured. Loss of packet must only be counted for link quality metering.

Fabio set here github.com/faeboli/Lcnc

Hello Peter.
Get github.com/Peter-van-Tol/LiteX-CNC branch envoders and commit 66133fb94c625df9d0f9fedc6b5239ec517e1d84
Make build test system for i386.
Work ok ! BUT! the movement of the motor is somehow "torn", not smooth.
And the system resource usage is very high, the Fabio driver consumes much less.
Tested on the same computer.
Computer configuration:
RAM DDR3 16Gb,
CPU i3-4130
Video card onboard (Intel)

With Fabio driver motor running very smooth without any "torn"

If I look carefully to your video, I see two problems:
- the motion is not fluent;
- when an error occurs (for example due to joint follow error), the motion is not stopped, but it continues to move.

It looks like the communication is not optimal between the FPGA and the LinuxCNC. This means updates of the position are missed by LinuxCNC and the motion is jerky therefore. Another explanation is the high CPU usage, which may lead to the GUI being 'paused'. The only way to confirm this is too actually attach a motor to the system. I use myself another GUI (gmoccapy) on a way less powerful PC and didn't experience this. My suspicion is that this behavior is due to the calculations required by the stepgen. Can you try whether having only 1 stepgen solves the jerky behavior? If so, I know which part has to be revised.

The lack of communication will also result in joint follow errors, after which the card should be stopped. Will investigate why the card is still commanding movement.

PS: the driver should also work on a 64-bit system now.