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

More
15 Aug 2022 13:10 - 15 Aug 2022 13:14 #249782 by svb
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"
Last edit: 15 Aug 2022 13:14 by svb.
The following user(s) said Thank You: TOLP2

Please Log in or Create an account to join the conversation.

More
15 Aug 2022 19:29 #249810 by TOLP2
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.  

Please Log in or Create an account to join the conversation.

More
15 Aug 2022 20:05 - 15 Aug 2022 20:06 #249817 by svb
Hello Peter
As I wrote earlier, I just have the motor connected. And jerks on the screen coincide with jerks on the engine.
I've tried different GUIs: gmoccapy, axis, qtvcp axis. Everywhere the behavior is the same.
Moreover, if I use the Fabio driver and firmware, everything moves smoothly, without jerks, with any GUI, qtdragon also tested.

Also with the Fabio driver, the CPU usage is much less.
On a 32-bit system, this is noticeably even stronger.

Update: After 11 runs of the 3D_Chips program on a 32 bit system, the driver went into the same uncontrolled movement as in the 64-bit version.
Last edit: 15 Aug 2022 20:06 by svb.
The following user(s) said Thank You: TOLP2

Please Log in or Create an account to join the conversation.

More
16 Aug 2022 07:25 #249859 by muvideo
Hi, about packet loss behavior, you can try to raise the value of Lcnc.00.tx-max-retries, this Is the Number of missing packets that Will trigger the board self disabling. Default value Is 5, you could set it to some value higher than timeout, for example 100.

Please Log in or Create an account to join the conversation.

More
16 Aug 2022 12:38 #249887 by TOLP2
Update: Due to complaints on speed and stability, I've made some changes in the stepgen algorithm (aims at solving both uncommanded / wrong movement and jerky motion). Also added now timing on all components to find out which function causes a high CPU usage. Tomorrow I'll be able to test it on my FPGA whether it works and will share the timing results. Feel free to test it earlier.
The following user(s) said Thank You: tommylight, besriworld, svb, vit74vit

Please Log in or Create an account to join the conversation.

More
16 Aug 2022 21:04 - 16 Aug 2022 21:07 #249920 by svb

Hi, about packet loss behavior, you can try to raise the value of Lcnc.00.tx-max-retries, this Is the Number of missing packets that Will trigger the board self disabling. Default value Is 5, you could set it to some value higher than timeout, for example 100.



Ok, i change it to 100000.
Result the same :(
I try to remove cable from board for 0.1-0.2 sec
100000 retries for 10 sec, i'm right?

Attachments:
Last edit: 16 Aug 2022 21:07 by svb.

Please Log in or Create an account to join the conversation.

More
16 Aug 2022 21:30 #249921 by muvideo
100000 should last about 100s before reset, but I've never timed this, I was more interested in the number of consecutive Lost packets. In this scenario the watchdog will bite for sure way before the 100s, depending in how it is configured.
I've noticed that if I disconnect briefly the cable, the connection Is fully restored only after several seconds, and I dont know why.
Maybe in the next iteration I should introduce better error messages so that the reset reason will be more clear.
My machine Is now fully cabled, I'll soon be able to test the sw on actual hardware.
The following user(s) said Thank You: svb

Please Log in or Create an account to join the conversation.

More
16 Aug 2022 23:49 #249924 by svb

Please Log in or Create an account to join the conversation.

More
17 Aug 2022 19:36 - 17 Aug 2022 20:25 #249970 by TOLP2
Just did some timings on the LitexCNC-driver. It was not the stepgen causing the problems, it is the communication with the board which consumes most of the time:
litexcnc: Read statistics (1000 cycles)
 - read device: 239635008 ns
 - watchdog: 2623096 ns
 - wallclock: 2466168 ns
 - gpio: 3543462 ns
 - pwm: 2417196 ns
 - stepgen: 5377152 ns
 - encoder: 5572973 ns
litexcnc: Write statistics (1000 cycles)  - watchdog: 3030761 ns
 - wallclock: 2180309 ns
 - gpio: 3135263 ns
 - pwm: 3986964 ns
 - stepgen: 4923544 ns
 - encoder: 3569105 ns
 - write device: 70789865 ns

It is the communication with the board which takes up most of the time (reading takes up to 25% of the cycle time). Lets focus on bringing these numbers down (without incurring package loss).

Edit:
Some additional timings from the etherbone protocol:
litexcnc: Etherbone read statistics (1000 cycles)
 - create packet: 8109911 ns
 - send adresses: 82686984 ns
 - receive_data: 154498294 ns
 - unpack data: 2598924 ns

OK: I can optimize the creation of the packet (this very slow given the little complexity it has), but the real pain is in the sending and receiving the data from the FPGA. 
 
Last edit: 17 Aug 2022 20:25 by TOLP2.
The following user(s) said Thank You: tuzki

Please Log in or Create an account to join the conversation.

More
18 Aug 2022 08:37 #250002 by romanetz
Well, if I understand you correctly, given numbers must be divided by 1000 to calculate time per cycle.
There are some unpredicted delays: time that is needed for travelling of packet across the Linux network stack - between "send" call and actual reception of packet in FPGA and in the opposite direction

Please Log in or Create an account to join the conversation.

Moderators: PCWjmelson
Time to create page: 0.133 seconds
Powered by Kunena Forum