Encoder getRate question

[JefferMC]

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.

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.

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.

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.

[joelg236]

Originally Posted by JefferMC

Also, I seem to recall that the PID classes wanted an Encoder and would not accept a Counter. I may be wrong about that.

The PIDController class only needs a PIDSource and PIDOutput. Counter does not implement PIDSource, but you could always extend it and implement PIDSource.

[Ether]

Originally Posted by JefferMC

According the the documentation, the FPGA is only used when the counter type is set to k4x, not for k2x and/or k1x.

What documentation are you referring to?

I seem to recall that the PID classes wanted an Encoder and would not accept a Counter. I may be wrong about that.

Many teams are successfully using home-brew one-count-per-rev counters on their one-directional shooter wheels. Also, PID is not the only game in town.

I never found that the handling the second channel caused an appreciable issue for the cRIO.

Perhaps you did but didn't realize it:

Originally Posted by JefferMC

we were forced to use a 360 CPR encoder to attempt to measure our shooting wheel. We exceeded the CPR limit.

However, the point is well taken that it is extra interrupts and unneeded effort.

There are no interrupts involved. The FPGA polls the DIO at ~153KHz

[AsianRookie]

A made a modified Counter class, to be used with PIDController and has 120 samples to average. It works wonderful. Thank you Ether.

[Ether]

Originally Posted by AsianRookie

A made a modified Counter class, to be used with PIDController and has 120 samples to average. It works wonderful. Thank you Ether.

And thank you for the follow-up post.

Would you be willing to post your modified Counter class? It would be a service to the FRC community. There are other teams/individuals who need some help figuring out how to do this.

[otherguy]

In case anyone else was looking for a source code example...

Looks like Joe Ross posted a patch to the Encoder and Counter classes for Java.
http://firstforge.wpi.edu/sf/go/artf...v=1&_pagenum=1