Remora - ethernet NVEM cnc board

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.

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

 

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
 

Thanks Scott. It was set to 0, but I changed it to 0.0001 and it seems to work fine now. I have now issue with motor accuracy. The scale is set to 160 and I have set jumpers on JMC ihsv57 motor to 800 steps per rotation so 5mm jog should be exactly one full circle. However its a little less than that. After few 5mm jogs its obvious. So do I have problem with step pulse lenghts?

You can try to move very, very slow and check the distance if its better.

If you have a rt1052 based board:
and if it's not too much trouble, you could try my version: github.com/multigcs/Remora-RT1052/tree/l...jitter_test/firmware

its compiled for the EC300 V5

I would be interested to know if it makes a difference