Quote:
Originally Posted by Ether
For US Digital E4P encoders, the limit is 60,000 rpm or 3,600,000/CPR, whichever is less.
|
Due to an inventory issue, we were forced to use a 360 CPR encoder to attempt to measure our shooting wheel. We exceeded the CPR limit. Frustrating to watch the RPM graph drop to zero as the wheel accelerates. Other solutions were found.
Quote:
|
The FPGA handles encoders. Vxworks is not involved.
|
According the the documentation, the FPGA is only used when the counter type is set to k4x, not for k2x and/or k1x. From what I can see from perusing the code, this is correct.
Quote:
|
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.
|
getRate() is a derivative of getPeriod(). getPeriod suffers from the same problem, i.e. the period of time between two "clicks" is approaching the resolution of the clock by which those clicks are measured.
The reason we had quad-encoding on this encoder was that at one point we were going to reload discs back through the barrel of the gun, causing us to run the motors backwards and wanting to be sure we knew they were running backwards.
Also, I seem to recall that the PID classes wanted an Encoder and would not accept a Counter. I may be wrong about that.
Quote:
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).
1X decoding of an encoder still requires detecting the rising edges of both channels, which limits your speed.
|
I never found that the handling the second channel caused an appreciable issue for the cRIO. However, the point is well taken that it is extra interrupts and unneeded effort.