Why I Would Not Use Counters
Originally Posted by
ESjaavik
@lerman: Did you consider using one of the built-in counters?
In real life a motor running at a speed approaching the (software) counting abilities of an ATMega16 @ 20MHz will simply not just begin rotating in the opposite direction! So why not change strategy from software counting with direction discriminator to just measure the speed? Then you would be able to follow a motor with 4096 transititions/rev and more up to when it throws it's windings. If you choose the input pins with care, this can all be done in software. It will only count on one flank of one of the phases, thus getting only 1/4 of the resolution but again, at that speed that will be a moot point anyway. Just shift the counter result left twice to make it correct.
If using step/dir control, use same strategy to keep up with this. If the host decides to swap direction while issuing step pulses at high speed, it's a lost case anyway. I know commercial drives that will not allow this either.
I did not try this out, so please shoot me down if I'm wrong.
I wouldn't say that you are wrong, but here are my thoughts.
At "zero" speed, you could sit at a transition. Any little vibration might cause rapid cycling up and down. Remember that every lost count on a servo represents an error in position -- it corresponds to a lost step on a stepper.
Of course, if you put a linear encoder on the table, then you can use the rotary encoder for speed feedback and the linear encoder for position.
One neat way (for me, at least -- I'm a programmer) to handle the problem might be to dedicate a chip to read the encoder and also read the commands from the host (PC). By writing the code in assembly language, I believe I could handle 3600 rpm with a 2000 transition per rev. encoder.
A second processor would read the current error (from the first processor) at the rate of a thousand times a second or so.
Ken
Kenneth Lerman
55 Main Street
Newtown, CT 06470