EMC

EMC Users/Victims,

Thanks to all of you who have posted replies to the CAD/CAM mail list to
questions that I should have answered. I was suffering email paralysis
and couldn't summon the will to attack my inbox.

For those of you on the emc@... mailing list (see
http://www.isd.cme.nist.gov/projects/emc for subscribing), you should
note that the CAD_CAM_EDM_DRO@onelist.com mail list has become the place
for EMC experience sharing. Apparently nobody on this list sleeps. I'll
post any EMC stuff to both lists in the future.

As Tim Goldstein noted, I put a new release of the EMC code on the FTP
site. It's at:

ftp://ftp.isd.cme.nist.gov/pub/emc/emcsoft/linux_2_0_36

with files:

emc-08-Jun-1999.tgz (tar file of new release)
emc-08-Jun-1999.txt (copy of RELEASE_NOTES)
emc-08-Jun-1999.log (result of install script, for comparison)

If you install this and notice problems, LET ME KNOW ASAP. I've tested
this on my stepper motor test stand on a desktop PC and a laptop, and it
worked, but we'll see.

I've appended a description of the fixes at the end of this message.
Basically they have to do with setting the default and max feed rates,
honoring them when they're set, and setting the stepper pulse rate.

Going through the mail list, I notice a couple of hot items that I'll be
working on in the next few weeks. These are:

1. An EMC User's Guide. Installing Linux and RT-Linux is a pain, and so
is installing and configuring the EMC, so this guide is intended to
cover how to get and set up an EMC PC. I will work with Matt Shaver to
get a draft that I will post to the FTP site, and if anyone feels like
commenting (or contributing) let me know.

2. A part program verifier. There is actually one of these already, in
emc/plat/linux_20_36/bin, called "rs274ngc". Tom Kramer here at NIST who
wrote the interpreter uses this. I'll clean it up and make it easier to
use. I just ran it, and got:

me> cd emc
me> plat/linux_2_0_36/bin/rs274ngc
name of tool file => tool.tbl
name of setup file =>
1 N0 USE_LENGTH_UNITS(CANON_UNITS_INCHES)
2 N0 SET_ORIGIN_OFFSETS(0.0000, 0.0000, 0.0000)
3 N0 SET_FEED_REFERENCE(CANON_XYZ)
4 N0 SET_ORIGIN_OFFSETS(0.0000, 0.0000, 0.0000)
5 N0 SET_FEED_REFERENCE(CANON_XYZ)
6 N0 SET_ORIGIN_OFFSETS(0.0000, 0.0000, 0.0000)
7 N0 SET_FEED_REFERENCE(CANON_XYZ)
8 N0 SELECT_PLANE(CANON_PLANE_XY)
Cannot open tool.tbl

so you see it needs some work. I'll ask Tom how to use it.

Regarding the incredible pickiness of the interpreter with regard to
cutter compensation corner radii, circular move start and end radii,
etc., I'll ask Tom how we can set this up to not die horribly when you
are half an angstrom off.

3. Contouring, so you can run that 2 MB racecar part program that comes
with MasterCAM. I had a grad student from the Netherlands work on this
and we've cut a bunch of wax cars. I don't know if any of you have tried
running dense G code programs but it doesn't work well in the current
release.

The fixes in the new EMC release I mentioned earlier (thanks to Tim
Goldstein, to whom this list was originally directed) include:

1. The INI file parameter [TRAJ] DEFAULT_VELOCITY is used to set the
initial value for the jog speed in the xemc GUI. Note that the units on
this in the INI file are in units per SECOND. We decided to keep all
time units to seconds in the INI file. If you have set your units to
inches (e.g., [TRAJ] LINEAR_UNITS = 0.03937...), then setting [TRAJ]
DEFAULT_VELOCITY to 0.5 will yield an initial value of 30 IPM.

2. The INI file parameter [TRAJ] MAX_VELOCITY is used to set the rapid
(G0) rate, and as an upper limit for the jog speed in xemc. The units
are the same as in (1) above. More importantly, the motion system will
clip all velocities to this max limit, even if the feed rate override is
above 100% (e.g., INI file parameter [DISPLAY] MAX_FEED_OVERRIDE = 1.5,
for 150%). So, if your stepper system can't run faster than 45 IPM, for
example, you can set the INI file value to 0.75 and you should never be
able to run faster than this, even with 150% feed rate override. Note
that this will make feed rate overrides above 100% appear not to
function for rapid moves or programmed moves at close to the rapid rate.

3. The stepper motor pulse rate used to be set via a compile-time
parameter set to 400 microseconds maximum pulse period, which is 2.5
kilohertz. Now, the INI file parameter for [AXIS_0,1,...] CYCLE_TIME is
used. There is a single stepper motor pulse task, so it's run at the
rate for the fastest axis (smallest CYCLE_TIME). I make all the
CYCLE_TIMEs the same. Note that making the CYCLE_TIMEs shorter yields a
faster maximum pulse rate, and a faster achievable maximum velocity.
Making it too fast may cause the steppers to malfunction, or may consume
too much compute time and starve out the other tasks. You should set
this rate to be the maximum your motors can take. Apparently the 2.5
kilohertz default was too fast for you, which was causing motor
malfunction and the need for the MAX_VELOCITY described in (2) above.

Because of the way the stepper motor task works, you can get following
errors with stepper motors. This happens when the commanded motor speeds
exceed the maximum pulse rate. This can be seen easily by setting [TRAJ]
MAX_VELOCITY to something high, and jogging an axis at the max speed.
You will notice when you let up on the jog key that the motor keeps
going. It's because the commanded position has outpaced the stepper's
ability to keep up.

I recommend setting the [AXIS_0,1...] CYCLE_TIME to be less than the max
the stepper can take, and then setting [TRAJ] MAX_VELOCITY to be the
corresponding inches per second. You need to figure out the max pulse
rate by trial and error, unless it's documented.

--Fred