Quote:
Originally Posted by JefferMC
On encoders for shooting wheels, you may wish to watch out for the maximum RPM the encoder can handle. There are both electrical and physical issues there.
|
For US Digital E4P encoders, the limit is 60,000 rpm or 3,600,000/CPR, whichever is less.
Quote:
|
You can also approach the granularity of the VxWorks timer, which I believe has a resolution of 6 us.
|
The FPGA handles encoders. Vxworks is not involved.
Quote:
|
Since GetRate() gives you the inverse of the time between the last two ticks, with a resolution of about 6 us, this caused us some issues with oscillation between two substantially different returned values for RPS.
|
For a high-speed one-direction application like a shooter wheel, do not use getRate(). Use getPeriod() from the Counter class. Make sure you physically connect only Channel A. Leave Channel B disconnected. Create an up/down counter counting rising edges only.
See the attached example calculation of a 250 CPR encoder set up this way and spinning at 5000 rpm, showing the effect of the 6us polling period of the FPGA when the ring buffer is set to 125 samples (1/2 of a revolution).
Quote:
|
Using the FPGA with the ring buffer may help with this, but we opted for the x1 resolution.
|
1X decoding of an encoder still requires detecting the rising edges of both channels, which limits your speed.