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.

Hello,
I tested on an Orange Pi5 Plus and noticed that the jerk was not always maintained.

the ini and the nc code in the appendix.
In addition, an NC code generated by a CAM where the jerk is also not maintained.. 

@ruediger123
I believe the jerk is not matained, because it is not possible to maintain it with your cycle time and your tolerance, you are purposely settings the machine up to spike, and it will because there is no choice if it follows your thread cycle, if it follows your tolerance, and it follows your set feed, how do you propose this should be fixed? One of these limits should be relaxed, which one?

I don't think I should hard code limits, it should be up to the integrator to setup the machine with proper cycle time and limits according to processing requirements 

@endian @rodw
TP2 in a separate thread should be the medicine that fix our ailments, filtering, NURBS, all will be taken into consideration, it is an active development and testing on our end, not ready to share yet.

grandixximo wrote:

I don't think I should hard code limits, it should be up to the integrator to setup the machine with proper cycle time and limits according to processing requirements 

@endian @rodw
TP2 in a separate thread should be the medicine that fix our ailments, filtering, NURBS, all will be taken into consideration, it is an active development and testing on our end, not ready to share yet.
 

Do you think that TP1 + TP2 should be in the separate thread ?

thanks

Short answer: no.
Longer answer:
Kinda, TP1 and TP2 are different ideas/models/architectures, TP2 is what can be moved in a separate thread, because it was made to plan out of RT, TP1 idea was to run in RT, both are valid ways to solve the jerk-limit, so me and YY agree both can live, they are different approaches, with their own pros and cons, moving TP1 to a separate thread would basically mean TP2.
 

@grandixximo
The machine is congigured with a 1ms servo cycle, the speed with 15 m/min, the acceleration with 5 m/s² and the jerk with 50 m/s³ so nothing unusual for servo axes.
P64 P0.01 Q0.0 is also not unusual.
In my opinion, the limits for jerk, acceleration and speed should not be exceeded so that the behavior of the machine is predictable.
The unusual thing from my point of view is that MAX_LINEAR_JERK and MAX_JERK are different.
If there are restrictions on certain parameters, please let me know so that I can take them into account in my tests.

@ruediger123

The restriction is the corner itself. A sharp corner is a mathematical direction discontinuity. The velocity vector must change by ~191 mm/s across a 45° turn. With a 1ms cycle time, respecting 50 m/s³ jerk would require spreading that change over ~3800 cycles, during which the machine travels nearly a meter. No feed rate fixes this, the problem is geometric.

The only mathematically correct solution within your parameters is for the planner to detect that no valid cornering speed exists that satisfies the jerk limit given the available segment geometry, and fall back to a full stop at the corner. That is exactly G61.1 behavior.

This is actually a valid point and potentially a missing feature: the junction velocity calculation should be jerk-aware, and when the jerk-constrained cornering speed rounds down to zero, the planner should stop rather than arrive too fast and spike. Currently it may only be acceleration-aware at the junction, which allows a non-zero entry speed that looks acceptable to the acceleration limit but still violates jerk because the ramp does not fit in the available geometry.

The practical workaround in the meantime is either G61.1 explicitly, or a P tolerance of several mm to give the planner room for a proper S-curve through the corner. P0.01 is geometrically equivalent to sharp.