Re: EMC

Fred,

Thanks for looking after us stepper guys!!

I haven't had a chance to play with the 08-jun-99 build much tonight, but it
installed with no problems and trying to find the correct setting for the
new CYCLE_TIME is quite a time consuming task as you load up EMC, try some
rapid moves, close EMC, edit the .ini file and repeat. Any way to put the
settings in the configuration menu that is in Xemc so you can just try
different settings without restarting EMC?

I found that if you have the MAX_VELOCITY set high and the CYCLE_TIME set
low I would get repeatedly get an axis follow error. The odd thing was if I
was at Z0.00 and did a G0 Z-3.00 I never got the error. From that position I
did a Z0 and I would always get the error message at the exact same point if
I started from the same position. Change the start position and the error
would occur at a different point, but always the same for each start
position and always when traveling from a negative Z value to Zero. I did
thing to try a negative to a smaller value negative so I don't know what
happens then.

Is there any way to calculate what a particular CYCLE_TIME entry will allow
as a maximum steps per second? It is looking like my machine is happiest
around .00052 - .00055 for a CYCLE_TIME, but I am not sure where to set the
MAX_VELOCITY to match the rates.



Tim
[Denver, CO]

> -----Original Message-----
> From: Fred Proctor [mailto:proctor@...]
> Sent: Wednesday, June 09, 1999 2:44 PM
> To: CAD_CAM_EDM_DRO@onelist.com; emc@...
> Subject: [CAD_CAM_EDM_DRO] EMC
>
>
> From: Fred Proctor <proctor@...>
>
> 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
>
> ------------------------------------------------------------------------
> Having difficulty getting "in synch" with list members?
> http://www.onelist.com
> Try ONElist's Shared Calendar to organize events, meetings and more!
> ------------------------------------------------------------------------
> welcome to CAD_CAM_EDM_DRO@..., an unmodulated list for
> the discussion of shop built systems in the above catagories.
>