LinuxCNC S-Curve Accelerations

endian wrote:

Yes Rod .. it is solution but it is creating constant delay between control position -> DFIR -> current position of tool ....
 
It will not add any delay as it should be applied as the acceleration is calculated or read per servo cycle. Just not sure how you need to use it. 
the size of the buffer is configurable.
Any other published moving average solution wanted to use loops which are a source of delay so I devised this..
One of the cleverest algorithms I have ever coded...
 
 

I think the best way to apply that... its consulate with Luca or Yang Yang if they are allready not using something like that now...  I'm not that familiar with their code till now ... it toooo way complicated for me

my next observation is - high value of G64 tolerance around 0.1(650us spikes) is spiking more than 0.001(250us spikes)

best setup till now ... most influential spiking thingy is the 

rodw wrote:

Why can't you use more than one thread instead of a FGPA?

 

Thanks, I've been wondering too. I've been dreaming about kinematics using multiple realtime threads. Does anyone know whether/why it would not do?

Go easy on me. I tried to read through this whole thread, but there's a lot to digest. 

How does the current linuxcnc approach compare to how S curve acceleration is being done in GRBLHAL? 

I've tried to read the linuxcnc servo loop code, but it's pretty well impenetrable. 

However, GRBLHAL is very cleanly written and well commented. From what I can see, it has many features discussed here.

It has a backwards (and forwards) buffered trajectory planner with prescribed tangential acceleration. It has buffered segment interpolation. Both run outside the realtime loop, but the segment buffer is fast enough for feed overrides and holds to feel instantaneous. 

I know it's not a "real" control, but it's pretty amazing they could get all that to work (along with g-code interpreter, etc) on an 8 bit AVR microcontroller. 

The current HAL version offers jerk limited acceleration, though I have to say its utility is a bit questionable for industrial machines. I believe the GRBL equivalent of the "servo loop" only runs at 100Hz, so you would need really low jerk values to see an effect. But, the framework seems sound.

ewlsey wrote:

Go easy on me. I tried to read through this whole thread, but there's a lot to digest. 

--snip--

I know it's not a "real" control, but it's pretty amazing they could get all that to work (along with g-code interpreter, etc) on an 8 bit AVR microcontroller. 

 

Just now I discovered:
GRBLHAL = 32 bit
GRBL = 8 bit
Thanks for bringing this up. A long time ago I read all about GRBL 8-bit and sort of gave up on it. Now I notice the main project is 32 bit. Now that seems worthwhile. Cheap 32-bit MCUs today pack some punch.

That said, I'll leave the S-curve talk for the pros.