New EMC build available

Just got a message from Fred Proctor and he has put a new build of EMC on
the ftp site.

From reading his message it looks like the newest version has some hop ups
for up stepper motor people.

Tim
[Denver, CO]

----- Original Message -----
From: Fred Proctor <proctor@...>
To: <timg@...>
Sent: Wednesday, June 09, 1999 12:28 PM
Subject: EMC stuff


> Tim,
>
> I just got the part you mailed me. Thanks a lot! I saw pictures of this
> on your web site and my boss was pretty enthused seeing the actual part.
>
> I've been talking with Matt Shaver about configuring the EMC, and still
> have boatloads of CAD_CAM_EDM_DRO email to go through. I wanted to reply
> to you directly since you pointed out some problems with the EMC that I
> fixed (hopefully). I put a new release on the FTP site:
>
> 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)
>
> The fixes 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
>