Quote:
Originally Posted by tseres
also, do i have to use kevin's code with all of the initialization? or could i make my own based upon the phase a and b on the digital inputs?
*EDIT*
is there also a way i could have the encoder counting in the background of my code? or does it do that already....if not, how (if possible).
from looking at the code, do i also have to reset the encoder count? do i also have to manually make the ENCODER_x_COUNT increment every time the encoder ticks?
|
You really want to use the interrupt capability (Digio 1, 2) for the Phase A.
I suppose you could do it without interrupts, but you would have a lot of overhead and I don't think you would be able to get the accurate counting that you need.
If you are not familiar with interrupt service processing, I would say use Kevin's code with as few modifications as possible. As you understand more about how it works, then experiment with changes.
Kevins code has the encoder tick counting handled at interrupt level, so it is done effectively "in the back ground". Note that the encoder count is incremented (of decremented) in the ISR. (Interrupt Service Routine)
The question about resetting the encoder count depends on what you want to do, and how many ticks you are expecting. I generally find that using a "long" to store the count will let me count for way more than the amount of ticks I could get during a match time. This does mean that you need to store copies in routines that are measuring an elapsed distance.
Note also that I use "long" and not "unsigned long" since the code counts backwards when (negative) when the drive is reversed. If you have a system with encoders where you can not detect rotation direction, you may want to zero the count whenever you stop.
To compute velocity, one of the timers can be used to provide accurate interval info. Based on the timer, you can run a routine periodically that computes the velocity over the time interval.