Optimization Ideas for DMA Stepgen and Increasing response time.

[Geramy]

I am looking at the code and wondering how do we remove as much processing as possible without putting the burden somewhere else, except on the main computer actually sending the data for the motion card.

1. Remove the use of abs on frequency command by sending it already sanitized "abs" inside remora linuxcnc kernel.
2. We must not provide a direction bit in the data code, which shouldn't make a huge difference and also removes a second cmp statement further reducing cpu time.

These changes won't reduce the looping a whole lot but thats fine, also if we increased the response time from the card to linuxcnc, instead of being 1000khz or 1ms we could try to drop it to 0.5ms, normally the latency is WAY below that and this should reduce ferror. I came up with a simple calculation to figure out what the maximum ferror could be, right now at 1ms I can get a maximum ferror no matter what I do or how i tune the motors of about 0.03 I believe, if we change the PRU_SERVOFREQ to double the value as i'm reading in your code it will reduce the buffer size also by that much, and technically that will increase the response time of the motion card giving us twice the opportunity to respond back to linuxcnc to reduce follow time and error especially when operating at high velocities, I'm not 100% sure that I'm correct but after reading the code this is what I have come to think. Let me know your thoughts, i'm going to run some tests. Let me know if I'm missing something when changing the PRU_SERVOFREQ.

[Geramy]

Also why is header so big? Do we really need a int32_t? we can reduce the size of the structure and also the amount of time to pack/unpack the networking data if we use tighter types with what we actually need, or does linuxcnc use those as they are, some sort of system type?

[scottalford75]

Hi, I've just pushed my latest improvements for the DMA stepgen branch. It's looking really good now and is showing that loop tuning is becoming more important at high step rates.

This is running with the floats etc and is running ok with the standard LinuxCNC servo period response. Following errors are very acceptable.

The abs is only running once per servo thread so whether it's done in the kernel or in the stepgen it's still needed.

I'd love to keep the compatibility across the Remora versions if possible.

On Wed, Sep 27, 2023 at 3:12 PM Geramy @.***> wrote:

Also why is header so big? Do we really need a int32_t? we can reduce the size of the structure and also the amount of time to pack/unpack the networking data if we use tighter types with what we actually need, or does linuxcnc use those as they are, some sort of system type?

— Reply to this email directly, view it on GitHub https://github.com/scottalford75/Remora-RT1052-cpp/issues/6#issuecomment-1736714737, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGBMVIJMUE2FEXGXNMVYIX3X4OYTXANCNFSM6AAAAAA5IXKUWI . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[Geramy]

Got it and cool look forward to it and by the way how about using Edna to set the memory to 0 instead of the cpu? We could setup a buffer that has all zeros and then copy it to the buffer thats not being used to clear it, this should also provide more optimization right? I can implement this if you think its a good idea.

[Geramy]

I added some optimizations also! :) #7 I think you will be okay with the changes, no major structure changes in the system, just good old optimizations, and got rid of some warnings haha.

[Geramy]

Seems good enough im going to close this out.