Is there a maximum encoder pulse rate the system can handle?

[David Lame]

We are trying to start getting a bit fancier with our drive system. We put encoders on the drive wheels, and are trying to make use of them as part of camera lineups and autonomous code. Unfortunately, we have a problem. During testing, I drive forward, and then drive back to where I started, and the encoder doesn't read 0. Not even close. It seems to count consistently faster, meaning almost twice as many raw ticks, when moving forward.

Obviously, this isn't good, but what might be the cause?

We are using the CUI 102V encoders. I really like them. However, we just put them on the shaft of the transmissions, verified that we were reading a value that went up when it ought to go up and down when it ought to go down. One thing we didn't do is set the DIP switches inside the housing. Those DIP switches control the pulse rate, with the default value being 4096 pulses per revolution.

Once I realized there was a problem, I wondered if that was just too fast for the rio/wpilib to count. Could it be that we need to reduce our resolution? We don't need that high of a resolution value. We just stuck with what was set on the switches. However, before we go fiddling with things, I figured I would find out if there is some maximum value of pulses/second that ought to be used with our systems.

[The Lucas]

Are you encoding in 1x 2x or 4x mode?
Max counts per rev for 102v is 2048 (I guess you are prob using 2x for 4096).
It is doubtful you are overloading the FPGA of the rRIO with your drive train moving slowly. Calculations I have seen on CD have the rRIO capable of about 5 million counts per sec.
http://www.chiefdelphi.com/forums/sh...5&postcount=12
Check your B channel to see if it is operating correctly (since it gives you direction only, unless you are in 4x mode). You can do this with a moderately advanced multi meter that has a Hz function. Or you can simply swap the A&B channels at the rRIO and see if the same behavior happens in the negative direction. There is an index (X) channel on these encoders, so that might be in the mix(A or B), causing interesting results.

[Ether]

The 2016 roboRIO FPGA samples and timestamps at 40MHz. That's every 25 nanoseconds.

There may be a speed limit on the encoder itself. Check the datasheet.

Or the encoder may not be assembled or mounted correctly.

[David Lame]

Thanks. I doubt we are getting up to 4 million pulses per second, so that shouldn't be the problem.