Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors!

Hi again,

Remember me, the guy with the old rusty Gorton on an island? I'm back
home now and the mill's still on that island, to stay as far as I know.
But that's beside the point.

I feel much more in my element with this topic, though it's a lot like
coming in late to someone else's design review meeting. I'll make a few
quick points and get out of the way:

1. I must agree that trying to use a PC printer port to generate a nice
even pulse train while running a GUI at the same time is a silly idea.

2. Trying to do it with a PIC class micro is sort of like trying to use
a wrench for a hammer. It's a waste of a good wrench and it makes a
really bad hammer.

3. I think Jon is on the right track here with the CPLD approach.

Jon, are you doing this as a product design to sell, or is it an "open
source" type project? Also, I read about you doing battle with the EPP
fast transfer protocol. How many different parallel port chips have you
tested with. Some don't play nice at all. And, in your spare time, try
one of those USB to printer thingies. Big fun.

Jeff

On Tue, 29 Aug 2000 18:05:31 -0500, Jon Elson wrote:

>
>And, I'm going to jump right in and BUST your drum, again!
>
>A microprocessor can just about do the job, but it is too slow, unless
>you
>REALLY want to spend some money on a bunch of DSP machines, like
>the AD 29060 super-SHARC.
>
>I can EASILY do this for 4 channels in a single $18 FPGA, and have pulse
>
>timing resolution down to 100 nS by running the chip's counters at 10
>MHz.
>Your micro can't execute more than one instruction in that time.
>
>If I clock it at 40 MHz, it can get resolution down to 25 nS! The chip
>should
>handle this with no sweat at all, now it is clearly out of the range of
>any
>micro! The CPU just outputs how fast the pulses should come out, and
>the
>timing chip counts them out with extremely fine resolution, so at a
>constant
>commanded velocity, the pulses will come out with +/- 1 clock cycle
>of timing resolution. As long as the pulse rate is very low compared
>to the clock rate, this appears pretty close to being an inverse linear
>relationship, and everybody should be happy. Depending on how many
>bits of resolution the timer has, it gets a little jumpy at the bottom
>end,
>but that's all relative, since the stepper is TOTALLY jumpy (ie.
>discrete)
>at these speeds, anyway. A 24-bit counter running at 10 MHz can count
>out steps up to one every 1.6 seconds. When moving slower than this,
>the counter needs to be turned off. If you don't turn it off, a step
>comes out
>~ every 1.6 seconds, and the CPU would notice the count change in the
>position counter, and then order a very slow move in the other
>direction.
>This would cause a 1 step hunting behavior at 1/3.2 Hz, which actually
>doesn't sound like much of a problem.
>
>I just don't think you can come even CLOSE to this with a micro,
>especially
>a PIC-class one. The only parts I need are a 10 MHz crystal oscillator
>and a Xilinx Spartan XCS10-series chip! That's IT! So, $20 in parts,
>plus the circuit board. (This assumes another unit has the position
>counters, also on one of these Spartan chips. That allows you to
>have the position counters counting simulated encoder phase signals
>coming from the timing chip, or getting real encoder signals from a
>shaft encoder on the motor. Note that the shaft encoder does not need
>to match the resolution of the motor. But, if the motor has LOWER
>resolution that the encoder (a common practice) then a deadband
>will have to be set on the CNC or it will hunt, possibly an annoyance.)
>
>Jon
>
>
>