Re: [CAD_CAM_EDM_DRO] Re: UCMI Interface

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