Re: S-Curve Velocity Profile

[Fred Proctor <frederick.proctor-at-nist.gov>]

Pwcag-at-aol.com wrote:

>   Does anyone know how to
> create a S-Curve Velocity Profile?
> 
> Tom.

which looks like Tom's trying to make headway on his previous posting:

> I know EMC has trapezoidal Velocity Profiling
> but does it have S-Curve?

The EMC doesn't do S-curve velocity profiling, one of its many
deficiencies. It just does trapezoidal profiling. The code for this is
in emc/src/emcmot/tc.c, and Will's working on adding support for 6-axis
motion (orientation control). If you need to limit acceleration spikes,
there's no real satisfactory way at this point. I think the best that
can be done as a workaround is to reduce the acceleration value, but
this will increase corner rounding.

The way the motion controller works is by looking at each motion segment
(straight line or circular/helical arc), computing its total length in
Cartesian XYZ space, and planning a constant accel to the specified
speed, cruising, and then decelerating to the end point. The accel/decel
parameter is in the .ini file, as [TRAJ] DEFAULT_ACCELERATION, in units
per second per second (inches/sec/sec normally). [TRAJ] MAX_ACCELERATION
currently doesn't do anything, but I always set it equal to
DEFAULT_ACCELERATION.

The speed is settable via the F code in the NC program or by the jog
speed slider in the GUI. The speed will be limited to [TRAJ]
MAX_VELOCITY (the rapid G0 rate) and also by [AXIS_#] MAX_VELOCITY, the
latter being a way to prevent a slow axis (like the Z) from being
overtaxed while allowing the faster axes to go faster if the slow axis
is not taking part in a move.

Adjacent motions are blended together, the second being started when the
first begins to decelerate. This causes rounding, which can be made
crisper by increasing [TRAJ] DEFAULT_ACCELERATION. The blending is also
broken, in cases where three or more segments need to be blended
together.

Lookahead is not done, in that speed is not slowed in corners
automatically.

The motion controller obviously needs to be improved, in at least these
areas:

1. Blending. It should be possible to blend any number of adjacent
segments. A guest researcher got this to work, but it wasn't quite
finished and it's not compiled in the distribution (it's the
"segmentqueue" code in emc/src/emcmot if you're interested).

2. S-curve profiling. There are at least two ways to specify this that
I'm aware of. Some motion control boards use accel/decel time, say 10
milliseconds, during which the acceleration increases to a constant
phase, then decreases to zero during the cruising phase. A plot of this
would show a period at the beginning and end of the accel/decel slopes
when this was happening. The second way is by specifying the max
allowable rate of change of acceleration, in units/sec/sec/sec. This is
"jerk". This is the way I prefer to do it, if I were ever to get around
to it.

3. World- v. Joint motion. I really tangled the two together in the
motion system early on, since we were dealing with slideway machines for
which the XYZ motors actually aligned with XYZ coordinates. In robots
and hexapods this isn't true. Separating out these modes of motion is
tricky. For example, the F code applies to the tangential speed of the
tool, in World (Cartesian, normally) coordinates. For a hexapod, even
constant linear tool motion will result in non-constant strut motion,
even strut reversals in the middle of a linear move. There should be a
per-joint limit on speed, but it's not simply related to the F code
speed in general. Lookahead complicates things also. The speed reduction
during cornering depends in general on the joint configuration of the
machine, and with robots even linear World moves can result in extremely
fast joint motion near singularities.

--Fred