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