experiments with EMC smoothness
- Subject: experiments with EMC smoothness
- From: "Les Watts" <leswatts-at-alltel.net>
- Date: Tue, 20 May 2003 09:13:14 -0400
- Content-Transfer-Encoding: 8bit
- Content-Type: text/plain; charset="iso-8859-15"
- References: <200305201325.h4KDPVwk011092-at-btc3.up.net>
As some of you know I have been investigating observed jerky motion
when EMC is used at high speeds and accelerations as some of us typically do
on cnc routers and the like.
I ran some simple little tests where one axis is commanded to move
linearly with a long series of short G1 moves at various speeds.
I found that at virtually all programmed speeds short adjacent moves
run much much slower than the same total motion programmed as a single move.
A machine-gun like jerky behavior is also noted.
I found this surprising since EMC is supposed to have blended trapezoidal
motion planning with a cubic subinterpolator.
Let me briefly describe what these do.
Trapezoidal motion planning refers to the velocity profile in a move.
>From the start point to the destination point the motion is divided into
three areas.
The first is accelerating up to speed. This is done at constant
acceleration,
so velocity increases linearly.
The second area is the cruise region, where the motion is at constant
velocity and therefore zero acceleration.
Finally there is a negative acceleration (deceleration) region where
velocity is linearly reduced with time until motion ideally ceases at
the desired destination point.
Now it’s easy to see that a series of commanded moves would be in
exact stop mode, always decelerating to a stop at each waypoint.
Inertia and PID compensation would prevent complete stops, but it
would still be arbitrarily choppy.
That’s where the blending comes in. Generally if another move is
seen coming by the planner it will skip the deceleration phase
and call the next waypoint. In that way velocity only has to be
changed if it is commanded.
So a series of identical short moves could be as smooth and seamless
as an equivalent long commanded single move because the blending
suppresses those deceleration/acceleration regions between segments.
But I am observing that EMC is not fully doing this in G64 contouring
or any other mode at any speed.
Puzzled, I looked through archives. I found an old letter from Fred
on the subject which I will quote some excerpts.
>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. 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.
I think the last sentence explains the observed jerky motion-
apparently for paths of more than 3 segments THERE IS NO MOTION BLENDING.
The only control is to reduce DEFAULT_ACCELERATION to
a low value. Perhaps it is only cubic interpolated intermediate
points that are blended - I’m not sure.
This was realized by a further quote of Fred’s letter:
>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).
I took a look at segmentqueue.c, segmentqueue.h, and the aparently
currently used blended trapezoidal routine tc.c and it header file.
I wonder what wasn’t quite finished? Was it just some housekeeping stuff?
I would also ask that folks have a look at these files as well.
I am familiar with the math routines for these functions but it is
of course very hard to follow exactly what’s going on in that code.
Perhaps segmentqueue is 99% finished and could be instituted with
only a little work. I of course have no idea what is not working
yet with it.
This would be a powerful performance increase for EMC if I understand
things correctly. As I have studied this I have
concluded that it would be more powerful than things like
quintic interpolators and the like.
For very slow speeds and accelerations like 10ipm and 3 in/sec^2
EMC can be fairly smooth. But those of us using cnc routers or plasma
are forced to go much much slower that many of our servo machines can
handle,
because we get a pulse of current at maximum allowed on EVERY SINGLE
PROGRAMMED WAYPOINT. That is what I am seeing anyway. Intermediate cubic
interpolated
waypoints may be blended, but that in itself would seem to be of little use.
And my tests show that it is not a computer speed issue. Or at least I don't
think so, because it happens at any programmed speed.
Let’s work on this. We could be talking about a tenfold increase in
trajectory
smoothness!
Please excuse the double post if you are on both lists.
Leslie Watts
L M Watts Furniture
Tiger, Georgia USA
http://www.alltel.net/~leswatts/wattsfurniturewp.html
engineering page:
http://www.alltel.net/~leswatts/shop.html
Surplus cnc for sale:
http://www.alltel.net/~leswatts/forsale.html
Date Index |
Thread Index |
Back to archive index |
Back to Mailing List Page
Problems or questions? Contact