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

Hello Fabio.
I'm so sorry but with your config's maximum working time before error only 25 minutes. With my config's this time more than 4hours

svb wrote:

Hello Fabio.
I'm so sorry but with your config's maximum working time before error only 25 minutes. With my config's this time more than 4hours
 

Hi,
I found a mistake in my handling of incoming data: in case I had a receive timeout I keep reading data, also if they are garbled.
This results in joint following errors in case of packet loss.
I've updated the git repository with a fix, I also made some small changes in error messaging.
Can you try last version of driver github.com/faeboli/Lcnc   ?
If it behaves better, you can change the tx_retry parameter back to some sensible number, depending on your link robustness.
I'm working with 5, but you have to monitor number of "normal" packets loss you see in your setup and use a value reasonably higher, in order to not have an error in normal use, but be sure that in case of a big link disconnection you are notified.
Please let me know what changes you will notice in behavior.
Fabio

 

Hello Fabio.
Try new version.
After first error machine go to OFF state.
All errors after first is a in IDLE mode (Machine OFF)

For Litex-CNC I've found that the uncommanded movement is not due to the driver. Somehow when a joint follow error occurs, LinuxCNC goes into EStop. However the motion planner (motmod) is still commanding new positions to the driver, thus it keeps moving. This is a really weird error. The only way how I see I can solve this, is by preventing a joint follow error. But if an error occurs, I don't know what will happen.

I think the source of the joint follow error is due to the acceleration speed of the driver is the same as the acceleration of the motion planner. Due to rounding errors, the commanded speed cannot be reached within one cycle and thus the driver is trying its best to compensate. There are two possible problems to this problem:

1. Add a contingency in the driver (let's say 10%) on the acceleration.
2. Follow the hostmot2 (Mesa cards) approach and allow for an acceleration of 0, which means that the acceleration is completely handled by the motion planner.  

I'll try option 1 first to see whether this solves the joint follow error and then modify the code to the second option if it does.

Backup plan
I still like the flexibility of my version of the driver, in such away that you can make it tailormade to the machine based on a config-file. If above is not working, my plan is:

• to base a template on LCNC or ColorCNC;
• create a Python-script which makes the source code of a driver based on the template and the settings in the JSON-file;
• compile the dedicated driver.

Wondering what your opinion is on the backup plan.

 

Quick update: found that the previous stepgen had an error in the algorithm, which prevented the errors to be smoothed out. Hence, a moving machine.

At this moment I've developed a new algorithm, which will try to smooth out any error in two cycles. Imagine a machine which is at standstill and has an error of 1 mm. In the first step the machine is accelerated to compensate half of the error. At the start of the second cycle the machine has thus speed. In the second cycle we decelerate to stand-still and correcting the second half.

In theory above works, in practice I ran in to some troubles:
- the stepgen sometimes reports erronous values for the speed and position back (much higher then commanded);
- while not running a program, the motion planner of LinuxCNC suddenly starts to send out oscillating motion commands (which are followed by the stepgen). Why these oscillations occur is unknown to me, maybe it has something to do with the feedback from the stepgen. Any help or suggestions on this subject are more than welcome/

FINALLY

I have resolved the bugs in the stepgen of Litex-CNC. It was a bit harder then I initially thought it would be. The things which I have changed:

• There is now a config phase which is executed during the first loop. During this phase the timings for the stepgen are sent to the FPGA and all related parameters are calculated. Positive effect is that the speed of especially the write function is improved. Con is that the timings (like step length, dir hold time, etc) cannot be changed during runtime, but who does that anyways?
• During the config phase it is checked whether the read and write functions are in the recommended order (first read, do something with the data, then write the commands back). A warning will be generated when the write function is executed before the read function.
• The stepgen component is essentially completely rewritten:
  • The contributions to the required acceleration is split between the commanded movement and movement required to compensate for errors (if any).
  • Errors are compensated in two equal steps (theoretically). First cycle is ramping up speed, second one is ramping down to the desired speed as demanded from the position command. The speed of the second step is seamless to the desired speed.
  • To calculate the feedback correctly the resolution of the counters are being taken into account. The calculated speed and speed are converted to binary (as required for the FPGA) and then converted back to float for the feedback values. Especially at low speeds and situations with a small number of steps per unit this improved the accuracy of the feedback loop tremendously.

After these changes (and maybe a few more) I finally managed to run some of the axamples without latency problems or joint follow errors. I attached a simple NEMA17 stepper motor with a DRV8825 drive. Judging by the sound it does run very smoothly.

If you want to try it out, the code is available on Github ..For now the working stepgen is located in the branch stepgen_improvement, but I will merge it after some more testing.