Re: EMC

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

Dick,

You wrote:

>     I understand some of this (fix bugs part). What is motion planning? And I
> understand the six degrees are the three planes of position (X, Y, and Z),
> with three states of (rotational) orientation about those three planes (A, B,
> and C)? Is this correct?

Yes. For machine tools, X, Y, and Z almost always correspond to machine
axes associated with a particular motor. So progamming an X motion
causes only one motor to move. Machine tool builders take pains to make
sure the three moving axes are all perpendicular, and compensation
tables can be used to calibrate these. A, B, and C correspond to rotary
axes whose axis of rotation are aligned with the X, Y, and Z axes,
respectively. Like with X, Y, and Z, programming an A move causes only
one motor to move, rotating a table. Likewise with B and C.

As a result, programming in XYZABC means the numbers correspond to axis
values, which correspond to particular motor values. So, NC code is
really a bunch of values for motors, and you're programming motor
positions.

In robotics the system is very different. Here, X, Y, and Z refer to the
usual Cartesian coordinate system, but for a robot there is no way to
map a particular joint motor to the X axis. To move in a straight line
along the X axis usually means moving all the joints of the robot in
some complicated way. Watch the joints of your arm as you move your
finger along the edge of a desk and you'll see what I mean. In addition
to Cartesian coordinates, there are other translational representations.
Cylindrical coordinates use an angle for azimuth (like degrees from
north), a distance up (like height), and a distance out parallel to the
ground. Spherical coordinates used 2 angles, one for azimuth, one for
elevation, and a distance for range. Depending upon the design of the
robot, one of these may be a better choice. For most robots it's just as
complicated to map coordinates from any of these onto joint angles.
SCARA robots used for pick-and-place operations are built in such a way
that Cylindrical coordinates map directly to joints.

Robots also do not use A, B, and C values to reference particular
rotational joints. These values can be thought of as angles of rotation
of the tool about the X, Y, and Z coordinate axes. If used this way, the
numbers for A, B, and C are called the "direction cosines," and they are
designated as I, J, and K. Some machine tools use IJK format. There are
various other ways to represent orientation, like the three varieties of
translational representations. These include roll-pitch-yaw, Euler
angles, rotation matrices, rotation vectors, and quaternions. You may be
familiar with roll-pitch-yaw, but the definitions of these other ones
are quite tedious.

>     Is the motion planner a feature (like a daemon) of the software that takes
> the next position's endpoint data, compares it to the present position data,
> then computes and outputs appropriate data to the servo motor amps? (By the
> way, if yes, how many times a second does it do this? Or will I define it in
> the software setup?)

What you described is not the motion planner: this is the servo
controller. The period that this is done is customizable in the emc.ini
file, in each axes' section as the CYCLE_TIME value, in seconds. For
example, in emc.ini you could have:

[AXIS_0]
CYCLE_TIME = 0.001

for a one millisecond servo rate (same as 1 kilohertz).

Currently, if the values are different, the fastest one is used for all.

The motion planner is the thing that gives points to the servo
controller. The way the motion planner works is that it has a queue of
motions (line segments or circular arcs) that are given to it by the G
code interpreter. The motion planner decides how to ramp up the speed,
blend betweeen successive motions, and ramp down to a stop, given that
it needs to feed points to each of the servo controllers at 1
millisecond, for example. It may take thousands of milliseconds to move
from the beginning to the end of a single motion, in which case it
computes thousands of intermediate points along the way. The points at
the beginning are closely spaced in distance as it accelerates and
decelerates, and spaced farthest apart in distance as it moves at its
maximum feed rate. The points are all calculated 1 millisecond apart,
however. (We actually can interpolate between motion planner points and
servo points, so their cycle times need not be the same.)

>     Distance-to-go value means distance to the next segment's endpoint?

Distance-to-go is the distance along the current line segment or
circular arc between where the tool is now and where it will end up at
the end of the current segment. It is a single number, in inches, for
example. If moves are blended together, it's the distance to the point
where they blend, not the point at the end of all the motions where the
tool will stop.

>     Segment distance means how long each segment of motion is?

Yes.

>    Does EMC have a simulation mode in which one can see and troubleshoot
> problems easily?

Yes, depending on your definition of "easily." I run in simulation all
the time. What I run is the stepper motor version of the EMC, which
talks to the parallel port. If nothing is attached to the parallel port
it doesn't matter as far as the controller is concerned. This lets me
run the code in real time, and click around on the graphical user
interface, run programs, etc.

One thing I've also done is run on a real controller with the amps
disabled, and set the following error high enough that it won't cause a
shutdown. I set up the display to show the commanded position instead of
the actual position. I did this when my desktop minimill was flaking
out.

There is also a simulation that does not require real-time Linux, and
runs the servos at about 20 milliseconds. There is a version for Linux,
SunOS, and Windows 95/NT. I will put the Windows 95/NT one on the FTP
site and send mail to the emc-at-nist.gov mail list.

If you want to troubleshoot hardware, which I've found is what happens
mostly, then a simulator won't do any good.

> How big [is] the EMC file? How long before bugs and other things are put right? I
> probably should not download before then?

The full EMC distribution is over 4 megabytes. As far as bugs are
concerned, the controller is mostly functional, since it's been run at
various places to cut metal. There will be an endless succession of bug
fixes and new features. Currently I'm working on fixing single step
mode, and adding better motion planning. If you're just running typical
NC programs, you could try it out now.

--Fred