Re: Re: Stepper program w/Encoders?

Hans

> If you are putting a uP in there loop, why not make it figure out all
> the backlash parms... including dead time!

I'm not sure I know what you mean by dead time .. I DO time the spacings
between the step pulses and issue the additional steps at whatever rate
the previous steps were issued at. Whatever rate the CNC program thought
was appropriate is what I'll be using.

I DON'T want to re-engineer this wheel .. I'm not sure I know enough about it.

The current plan is for quite a simple device, just to see where it
goes.

Please understand that I'm very new to machining and newer still to this
CNC business. I THINK I understand the basics, but that's about it.

> I've had the idea for a while, and was going to expand it with a lookup
> table to generate thread compensation, that way it would
> move the true distance and lead screws become anything you want them to
> be... It all depends on the feedback resolution...

Don't the CNC programs effectively do that for you ? And that being the case,
why would you add it to the uC ? Or am I not understanding things ?

> I'm an electronics kind of person also...
> Which uP are you using ?

The current project uses a PIC12C509 to convert the quad inputs to Step, Dir,
and Error signals and a PIC16C63 to read the switch, CNC, and Step/Dir inputs
and outputs the CNC and LCD signals.

The first rev didn't use a 509, thinking that the 63 had enough interrupts
to do the job, but a CAREFUL read of the fine print of the datasheet showed
that it didn't.

The 16C6x devices have 4 inputs that will generate an "Interrupt On Change".
This sounds perfect to read the quad inputs, as both positive and negative
edges will generate an interrupt.

I dedicated this port to inputs .. 2 of the IOC inputs going to quad ins,
1 going to an EStop switch and 1 going to the Step signal from the CNC.
Limit and a pair of Reset switches went to the other inputs, which were
simply polled.

It didn't work ! Turns out that IOC feature ONLY works if the other inputs
of that port are NOT polled .. perhaps, not even used at all. The "feature"
is designed for "Wakeup On Keystroke" and is not too useful otherwise.

There were a number of solutions, but adding a $2.00 PIC was certainly the
cheapest and easiest. The Clock signal from the 509 generates a conventional
interrupt on 63, and this is the only interrupt used, so I'm SURE that I
don't miss anything. Everything else is polled, and since the ISR is so
short ( about 4uS, IIRC ), polling should be fine.

( For a commercial product, I'd have tried harder to do it all in one uC,
but when it's hours of my time to save 1 $2.00 part, forget it. )

Why a 12C509 ? I have a bunch laying around and have an ICE for one.
Why a 16C63 ? Exactly the same reasons as the above.

In the past, I've done a lot of work with 8051s ( and things like them
from Dallas and Atmel ), and still do. Slowly but surely I'm doing
more and more with PICs, though. They're TOUGH in nasty environments,
they're fast, they're predictable in that there's not THAT much errata
( assuming one actually READs the manual ! ) , there's a big choice of
them, and most important to me, I can program them in an 8051-like version
of assembly language. Because I program so imtermittently, both home and
at work, it's important to keep the number of languages down.

Alan




--

Alan Rothenbush | The Spartans do not ask the number of the
Academic Computing Services | enemy, only where they are.
Simon Fraser University |
Burnaby, B.C., Canada | Agix of Sparta