Trajectory Planner using Ruckig Lib

re the 0.254mm, that just happened to be the standard plasmac G64 setting. I think to find the tipping point we will need to dial that back to a change in behaviour is seen.

I will try and find time for that today.

What I found interesting was that the fillet triggered the behaviour not the chamfer,   I think some more iterations on both is needed to find where the transition points are.

Edit:   Some quick checks before getting sucked into meetings for the rest of the day.
1.  Chamfer at 0.5mm is still pasuing.
2. Fillet at 0.1mm pauses.   At 0.15mm it does not pause.  The cutoff must be somewhere in that gap.

edit 2:  Some further observations on the impacts of max_jerk a and feed rate.
Max Jerk seems to impact how quickly the velocity ramps up to asked for velocity.  Set max jerk to 1 and se what I mean when compared to say 1000 versus 10,000.  These impacts are more noticeable when the feed rate asked for his quite high.  The test squares with a feed rate of say 700 or 1200 are pretty smooth no matter which one you look stat.  However when you raise the feedrate to 7000 the first square has a noticeable pause on the corners and the length of time of that "pause" is based on how long it takes to decelerate and re accelerate up to speed.  At least that is what it looks like.

Cheers - James.

by definition, max jerk is how quickly *acceleration* ramps up or down. which, in turn, impacts how quickly velocity will ramp up/down.

and if you expect jerk of individual axes to be limited - motion has to come to a complete stop at each segment/line transition. unless segments are coliner (i.e. all motion is following a single straight line in 3d. or a single circle)

chamfers or arc fillets won't help. if they do - it's a bug

As dm17ry pointed out, isn't a pause expected at hard corners in the current implementation?

G64 / blended moves is not yet implemented?

G61 / exact stop requires coming to a complete stop. Doesn't matter how gracefully the accel / decel are done, coming to stop at the corner is still required.

(I could be completely wrong about what is currently implemented in this tp)

Could see what behaviour is of "pauses" using the standard tp with G61 and compare to S-curve to.

i once again want to point out: arc blending used in the current tp is not suitable for jerk-limited motion. it appears to me that not everybody gets that...

imagine a constant velocity movement along a straight line blended to an arc. without any hard corner. but!
while moving straight - velocity is constant on each axis -> acceleration vector is 0, jerk is 0
at the moment of passing the transition point to the arc acceleration instantly changes to velocity squared divided by arc radius (centripetal acceleration). that means infinite jerk.

i'm wondering if arcs can be replaced with some other curves with controllable curvature at the ends. bezier won't do...

edit: found an introductory video about continuity 
there're also tons of research on blending, e.g.  www.jamstjournal.com/article/exportPdf?i...9279c255&language=en

forum.linuxcnc.org/38-general-linuxcnc-q...g-lib?start=0#282422

The stock linuxcnc TP goes to great pains to keep the feedrate constant-ish while ensuring that machine can always be brought to a safe stop within available path segments and obeying acceleration limits. I didn't look too closely at this code for a while, but things like "following error" caused by this code is maybe related to ignoring (or miscalculating with) individual joint acceleration limits.

Currently the TP is running in the realtime-part of linuxcnc in the main 1kHz (usually) thread, so you are quite limited with how much you can calculate / optimize. The approach with ruckig lib also isn't suitable for RTAI systems where the TP is running as a kernel module.

@dm17ry

For information, on OpenCN we are using Spline to interpolate GCode and be able to calculate jerk-limited path. This can be a solution for 3 axis motion.

Regarding potential 4+ axis motion, I can't tell since we still have trouble with it on "all axis interpolated motion".