LinuxCNC S-Curve Accelerations

but passing thru a joint of a linear segment to a tangent arc with *any* non-zero velocity gives an infinite jerk because of a step change in the acceleration? as the acceleration vector rotate towards the arc center...
edit: can the blender use some higher order curves instead of arcs maybe? will that help?

g64 sets the path deviance tolerance. It deviates to keep speed up.

linuxcnc has no jerk limiting so there is infinite jerk every time acceleration changes from constant - even a straight move will have infinite jerk at the transitions.

Since the planner must calculate all coordinated axes together - I don't see it being easier to only jerk limit X and Y.

but doing jogging would be interesting to try on my big lathe.

cmorley wrote:

g64 sets the path deviance tolerance. It deviates to keep speed up.

linuxcnc has no jerk limiting so there is infinite jerk every time acceleration changes from constant - even a straight move will have infinite jerk at the transitions.

Since the planner must calculate all coordinated axes together - I don't see it being easier to only jerk limit X and Y.

but doing jogging would be interesting to try on my big lathe.

Not quite, without G64, the arc on a corner is negotiated at the feedrate in the gcode and an arc is formed. This can be quite huge (eg a 1 m square at 20 m/min is interesting). When you set a G64 tolerance you are setting a limit about how far from the programmed path it can deviate. This sets a smaller allowable arc. The physics of centripetal acceleration sets the maximum speed that we can run at to negotiate that corner. So machine acceleration is a key parameter as it determines the arc radius. eg faster acceleration can negotiate a tighter arc.

With a plasma machine there is no spindle and no z axis while cutting (it is commanded by external offsets, not by gcode). One of the issues I have mentioned re jerk limiting is the complexity of managing motion coordinated with the spindle (eg threading and constant velocity etc). So while the motion controller may look at X,Y & Z, on a plasma machine, the Z motion is always NIL. (Remember external offsets is external to the motion planner). Plus the absence of a spindle takes away a lot of complexity. But the high velocities and Tesla Ludicrous mode acceleration parameters mean plasma will benefit enormously from Jerk limited motion. So to my mind, its a good spot to start.

cmorley wrote:

Since the planner must calculate all coordinated axes together - I don't see it being easier to only jerk limit X and Y.

why? the Ruckig works for arbitrary number of DoFs?

as i understand, currently the blender fits the largest arcs it can into corners while keeping within g64 tolerance away from the path. and then the TP(?) follows that modified path trying to keep the programmed speed but slowing down if needed to stay withing acceleration limits. the Ruckig can also do the later plus also can keep jerks limited. but with arc blends it won't be able to do much better than slow down... wouldn't it?

g64 sets the path deviance tolerance. It deviates to keep speed up. - as compared to exact stop mode. A plain g64 sets maximuim deviance.

Rod was advocating only jerk limiting X and Y as a starting point- I am saying I think that would be more work
I do see that the library does multi axes already - so that's great.

Start your frame of reference from exact path mode.
Path blending rounds corners to speed up cutting time by deviating from the exact path. It makes the road easier to go fast on - just like race cars modify the road path to be faster.

Jerk limiting allows greater acceleration settings which can lead to longer time at cruise speeds. Also programs with a lot of small moves, the machine will spend most of its time in the acceleration phases - so a higher acceleration setting can really help. - similar to good shocks and springs on our race car keeps the machine stable so one it can accelerate harder without the tires slipping. Slipping tires makers the driver have to accelerate less and so limits top speed too.

So both techniques help with overall performance.

dm17ry wrote:

so now there's a fast algorithm available which can construct an optimal trajectory between two states (pos,vel,acc) keeping the velocity, the acceleration and the jerk limited. which is kinda a big deal, as i understand.

It's a big deal for jogging, but not for path planning.

Ruckig will happily plan a jerk-limited move between two (pos,vel,acc) states if and only if that move is physically possible. If not, it'll just say "sorry, can't do that". It won't modify an already existing, infinite jerk path. (And it won't even be able to handle all kind of jog moves out-of-the-box, which I hinted at here .)

What's needed for jerk limited trajectory planning is not an "online trajectory generator" but a planner that uses sigmoid-like moves instead of arcs when it modifies the path described by the G-code.

Jerk limiting allows greater acceleration settings which can lead to longer time at cruise speeds. Also programs with a lot of small moves, the machine will spend most of its time in the acceleration phases - so a higher acceleration setting can really help. - similar to good shocks and springs on our race car keeps the machine stable so one it can accelerate harder without the tires slipping. Slipping tires makers the driver have to accelerate less and so limits top speed too.

Well if you must bring cars into it, you should watch this   video  which is an interesting take on some of the maths involved as we negotiate corners.

But to say jerk limiting allows greater acceleration is wrong. A trapezoidal acceleration profile is  planned at  maximum acceleration. A jerk limited or S bend profile must violate the acceleration limits to achieve the target velocity in the same timeframe as trapezoidal.

Likewise, short segments are better understood  with a trapezoidal profile. If the distance to be traversed is too short to allow room for the tool to accelerate to the desired feedrate and then deccelerate to the end point, the maximum velocity is limited  so that can be achieved. This results in a triangular profile.

If a jerk limited profile is used in either case, it makes no difference whether its a short segment or a long segment, the acceleration limit must be violated.

But if you have set your maximum acceleration to a lower limit than what  can be physically achieved because your machine construction cannot handle the jerk associated with trapezoidal profile (eg its has crappy suspension), then yes, you may be able to increase the maximum acceleration if jerk limited motion can be achieved. But you must ensure there is sufficient headroom to accommodate the planned acceleration which will be higher than if trapzoidal profiles were used.. 

If a jerk limited profile is used in either case, it makes no difference whether its a short segment or a long segment, the acceleration limit must be violated.
 

But if you have set your maximum acceleration to a lower limit than what  can be physically achieved because your machine construction cannot handle the jerk associated with trapezoidal profile (eg its has crappy suspension), then yes, you may be able to increase the maximum acceleration if jerk limited motion can be achieved. But you must ensure there is sufficient headroom to accommodate the planned acceleration which will be higher than if trapzoidal profiles were used..  This is exactly what i meant - one must use suboptimal acceleration if jerk limiting is not utilized.
You don't violate acceleration limits with a jerk limited planner you extend the time it takes to accelerate.
(just as you extend the time for speed changes with acceleration on a trapzoidal profile.)
but that can be offset by the fact you can set the acceleration limits higher.

I wonder if we could break out jogging planning into a HAl component just as Grotius hinted at.
I made simple_tp.comp directly from the jogging code in linuxcnc - so it would seem one could do the opposite.
that would make it easier to test back to back changes.

Hi,

It's in general a good idea to test the s-curve implementation from within a component. It will keep it simple. But then
you also need a component style gcode reader, including function's like "start from line" etc.

My current strategy after more coding today :
- Read the gcode file into a vector of paths. A path is a motion from M3 to M5. Or a rapid G0.
A path has a total motion lenght.

- The Ruckig lib will perform the motion of each path. Today i did this succesfully in a 1ms live mode.
Then during execution of the motion, parameters like acc_max, vel_max, jerk_max can be modified during the motion!
This is realy great! Also moving backwards, motion reverse is no problem.

- In the above stage's no real x,y,z interpolation is done so far. Just one DoFs is used for a lineair path planning.
Imagine arc lenght's and line lenght's combined as a total path lenght.

As a result of the above implemenation :

The tcp x,y,z and tcp euler x,y,z interpolation can be done from the position of the one DoFs.
With this result the kinematic model can be driven.
The kinematic model, for example a 6 axis robot can then use a 6 DoFs system that control's the kinematic model motion.





 

Right, with a given error budget, limited jerk profiles allow higher
acceleration because actual hardware cannot follow infinite jerk
profiles (because it requires instant application of force which is not
possible because of mechanical spring, motor inductance etc etc)

This is quite obvious when you tune LinuxCNC servo systems.
The largest following error typically  is at the beginning and end
of acceleration so the machine acceleration often needs to be
lowered below what the drives are capable of delivering to keep
the following error within bounds.