Re: PICs as replacements for L297s

Alan, Larry,

That's quite advanced. For just a "jog" box, we wouldn't need all
that! When MMI just started doing PAL's, I played around with one of
their stepper state machine designs. 16L8?

The CY-545's have a nice set of features. Connect up a L298, and do a
little driven'. I'd be happy to take keyboard input for jog and inc/dec
commands, ramp a stepper motor, and display it's position on a 2 or 4
line LCD. High step rates, uStepping? Don't need that right away.
Quadrature feedback? Probably a luxury for my intended task of driving
a rotary table IMO.

Now a PIC to read encoders and display them, that would be interesting!
Gotta get around to that one of these days.

Alan, you've described quite an impressive PIC project!

Where are you on this Larry, as complex as Alan B's, or some simple
stuff like I've had in mind?

Alan KM6VV


beer@... wrote:

>
> On 20 Apr, CAD_CAM_EDM_DRO@yahoogroups.com wrote:
>
> > --- In CAD_CAM_EDM_DRO@y..., "Larry Edington" <ledington@c...> wrote:
> Since the PIC microcontroller can replace the L297 easily, and add new
> features to the controller, it seems to be very logical to me. The L297 is
> the 'logic' device in the circuit.
>
> Larry;
>
> Just a few thoughts ...
>
> I have no wish to argue nor to dispute the advantages of replacing
> dedicated logic with a microcontroller - I wholeheartedly agree.
>
> But actually having done it, actually having programmed a PIC as a
> replacement for a 297 to drive an L298 ( and others ), I can state with
> some high level of assurance that it is a non-trivial task should high
> step rates be required.
>
> Further, one must be VERY clever if one wishes to add microstepping, as
> step rate now becomes an even bigger issue. There is the additional
> program logic eating into the time slices available while at the same
> time, you want even more speed out of the PIC, as microstepping
> inherently lowers speed. ( More pulses required to go the same
> distance ) Been there, done this too.
>
> ( Hint: Conventional DACs aren't the answer )
>
> And adding quadrature feedback to a PIC stepper driver is damned near
> impossible at any reasonable level of performance. At high step rates,
> the interrupt overhead on even a 20MHz device consumes enough cycles
> that there is a strong possibility of missing either a step pulse or a
> quad pulse. The consequences of missing pulses - especially
> quadrature pulses - are not easily dealt with and further erode the
> maximum speed capabilites of the system. Been there, done a LOT of work
> on this too.
>
> ( Certainly works well enough at low speeds, though )
>
> The best solution I came up with for the feedback problem was an 8 pin
> C508 PIC offloading some of decoding work for a C63. The C508 took
> quadrature in and output three signals,
>
> Step - which generates an interrupt on the C63,
> Direction - read by the interrupt routine and
> ERROR - also read by the interrupt routine.
>
> The error signal was generated if a state change was "missed", either as
> a result of the speed being too high for the PIC to follow OR for some
> defect in the quadrature encoder. I found that from time to time, specs
> of dust would get inside the encoder, masking the light beam and causing
> missed states. ( At least, I think that's what's caused it ) In these
> cases, an ERROR signal stops processing and sends an E-Stop to the
> controlling program.
>
> I used a PIC for this quadrature offloading as none of the commercially
> available quad decoders ( like the USDigital LS7084 ) offered error
> outputs. The hard logic devices are, of course, capable of MUCH higher
> rates but upon seeing these error conditions in early testing, error
> detection became important to me. ( And oh yeah, PICs are cheaper <G> )
>
> Alan