Remora - ethernet NVEM / EC300 / EC500 cnc board

Now my machine runs smooth and i can run much faster:

www.youtube.com/shorts/vY6oTowxAnw

meister wrote:

I think,
there is absolutely no reason to run the normal IO's in an interrupt,
but there are many reasons to reduce the code inside interrupt's.

My Changes:
github.com/multigcs/Remora-RT1052/tree/l...jitter_test/firmware

i removed also the __disable_irq part and add some kind of double buffer


 

Remora has been running "threads" in interrupt context since its inception by design. The RT1052 version of the firmware exposes the underlying design as it's a C version of the code vs the C++ version which treats the threads (ISR) as an object which modules can be added to.

You've added a rxDataCopy as a double buffer but it's never used in this way in your code.

The disabling of the irq during data copying was to Cakeslob's point, a fix for a more serious issue when data was corrupted during the infrequent but possible scenario where data was being copied and the thread was triggered. 

Did you inform LinuxCNC of your base thread frequency change?

the rxDataCopy is used in the baseThread and will be updated on a save place right after receiving is complete done, triggerd by rxDataFlag.

Ok, will not waste your time anymore, my changes works for me, i am happy, thanks for your work !

greetings, Olli

Sorry, please don't take my questions the wrong way, I'm just trying to understand your changes. Where is rxDataCopy being filled with the incoming packet? in the UDP callback the data is being put straight into rxData..?

github.com/multigcs/Remora-RT1052/blob/5...urce/ethernet.c#L133

zmrdko wrote:

Thanks! I set Pgain to 10, 100 and even 200. It helped, but I am still getting 0.02 mm error now and then. Like 10 jogs are accurate and 1 jog is 0.02 off.

Do the same thing, but with deadband

source/baseThread.c:
but i think its better to move this part to the end of the makeSteps() function