Re: [CAD_CAM_EDM_DRO] Re: UCMI Interface

----- Original Message -----
From: "Jon Elson" <elson@...>
To: <CAD_CAM_EDM_DRO@yahoogroups.com>
Sent: Sunday, August 12, 2001 1:26 PM
Subject: Re: [CAD_CAM_EDM_DRO] Re: UCMI Interface


> Art Fenerty wrote:
>
> > Jon:
> >
> > Actually, I had alot of problems with the gecko hold time for
direction.
> > If you are using a gecko 210, its important to hold the direction line
until
> > the next step pulse. Although the spec's for the 210 call for something
like
> > 50uS, it really does not work under all circumstances. Depending on the
> > pulse stream I have found instances where the dir needs to be held for
up to
> > 500uS and longer.
>
> Good info to know!
>
> > That having been said, the Gecko 210 is an amazing
> > controller, and customers tell me they wouldn't use anything else since
I
> > changed the code to hold the direction pulse until the next step pulse.
It
> > means they can get up to 80000 steps per second due to its X10 pulsing
mode.
> > The on-board ASIC can time itself using the bus clock and
interrupt
> > the system with a specified interrupt vector on time out. Counting
pulses is
> > no problem under this type of system as you stated, but the real
problem,
> > faced by all software near as I can tell, is the ramping algorithm. I
get
> > numerous letters comparing different software and the real problem with
all
> > software seems to be the ramping. It's easy to pulse a motor and move
around
> > a contour if no ramping is required, but add in the need for ramping and
> > thats where you see the largest difference between software. Some
software,
> > when told to cut a circle, will create 4 different quadrants of speed.
It
> > will see that one of the axis involved will stop at each of the 90
degree
> > points and will therefore ramp both axis to zero at those points. While
this
> > problem is easily countered in the case of a circle, it is damn near
> > impossible to conteract in the case of a "real-life" program where a
contour
> > of 3" in length may be made from as many as 2000 different small arc's,
some
> > of which are as short as 8 stepper motor pulses.
>
> We demonstrated this capability with EMC and my stepper rate generators
> at the NAMES show near Detroit this April. We got VERY smooth contouring,
> and ran a Sherline with MicroKinetics drivers twice as fast as anyone
> had ever seen them go before.
>
> > In my opinion, the shortfall of all the Hardware and software
> > solutions seems to be the lack of a standard algorithm for ramping 3-8
axis
> > in a smooth way to produce a good contour. Since there is no standard
way of
> > doing this, the CAM software producers vary widely in the way programs
are
> > output. A CAM program that puts out 2000 micro arcs to produce a 1"
ellipse
> > is much harder to ramp than one that puts out 30 line segments and 4
small
> > arcs to produce the same ellipse.
>
> EMC does this just fine. You can get up to about 20 blocks/second with a
> 100 MHz Pentium. If you need more G-code processing speed, you just get
> a faster computer.
>
> >
> > I have found that while looking at all the hardware solutions on the
> > boards for pulseing, that no accounting for the ramping time is being
put
> > into the hardware. They often have velocity, min and max, but this only
lets
> > you ramp one movement. It is the concatenation of several movements and
the
> > ramping of these uneven pulse trains that creates the biggest problem. I
> > have customers that have switched to Master5 from Flashcut, CNCPro and
> > others saying that their systems run many times smoother. I don't for a
> > second believe that my software is much different from the others, but I
do
> > think that different ramping algorithms on different machines, combine
to
> > provide a huge swing in performance between software packages which rely
on
> > ramping routines optimised for particular units. This is why one
Flashcut
> > customer will consider his system great, while another will say it's too
> > darn slow and noisy, and Master5 runs his fast and smooth. The
difference is
> > simply the ramping algorithm. The reverse will happen in just as many
> > instances.
>
> Well, I won't even bother looking at anything but EMC (or compare it to
> very expensive commercial controls). But, i know this problem is
completely
> solved with EMC and the rate generator. The way I set it up, EMC thinks
it
> is running a closed-loop servo system. It is reading encoder position
> (simulated if there are no real encoders) comparing that to the desired
> position, and then sending out new velocity commands. It does this 1000
> times a second. The moves are VERY smooth, you can't hear any raggedness
> or frequency steps in the motion. The step pulses are computed with
> 100 nS resolution, literally parts per million at the normal step rates.
>
> > I personnaly believe that too much focus is put on smooth pulse
trains
> > and not enough on statistical variances necessary to create a smooth
ramp up
> > and ramp down on each axis, and that some of the problem is in the way
the
> > CAM packages produce the G-Code.
>
> Sure, but EMC's history as a servo motion system led it to ALWAYS make
> things smooth.
>
> Jon
>
>
> Addresses:
> FAQ: http://www.ktmarketing.com/faq.html
> FILES: http://groups.yahoo.com/group/CAD_CAM_EDM_DRO/files/
>
> Post messages: CAD_CAM_EDM_DRO@yahoogroups.com
> Subscribe: CAD_CAM_EDM_DRO-subscribe@yahoogroups.com
> Unsubscribe: CAD_CAM_EDM_DRO-unsubscribe@yahoogroups.com
> List owner: CAD_CAM_EDM_DRO-owner@yahoogroups.com, wanliker@...
> Moderator: jmelson@... timg@... [Moderator]
> URL to this page: http://groups.yahoo.com/group/CAD_CAM_EDM_DRO
> bill,
> List Manager
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>