Re: UCMI Interface

Art,

How would you go about determining the optimal segment lenght
settings when exporting a toolpath from a CAD/CAM program so that the
machine ramps smoothly ?

Rab

--- In CAD_CAM_EDM_DRO@y..., "Art Fenerty" <fenerty@h...> 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. 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.
> 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.
> 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.
> 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. I have seen Vector CAM output
which will
> match right into a ramping algorithm and run smooth and fast, and
then
> ArtCam code of the same object stutter and run rough just due to the
> resultant pulse train being quite choppy as a result of too
numerous arc's
> of ridiculously small size being produced. I find it hard to
imagine why an
> arc of size .001 mm's would be produced as opposed to a line
segment which
> is more standard to decode as a smooth bresenham function.
> If theres any great mathmeticians out there that can thing
of a way
> to accept a stream of pulse commands and determine the optimal time
betwen
> the pulses in a continous function, let me know, I'd love to hear
from you.
> ( sorry for the confusing verbosity, but if you have any idea's
I'd love to
> hear them)
>
> Art