How fast can KOP encoders count?

[Mr. Rogers]

We wanted to track the live rpm of our ball shooter shaft, turns about 5500 rpm max, could a 250 or 360 count encoder count that fast? (198000 counts per minute) (33000 counts a second) (using a 360 count.) Anybody know where we could find a single count encoder wheel (1 count per rev.), or could the software keep up at 33000 counts a second?

[AdamHeard]

Originally Posted by Mr. Rogers

We wanted to track the live rpm of our ball shooter shaft, turns about 5500 rpm max, could a 250 or 360 count encoder count that fast? (198000 counts per minute) (33000 counts a second) (using a 360 count.) Anybody know where we could find a single count encoder wheel (1 count per rev.), or could the software keep up at 33000 counts a second?

The encoder itself should have an rpm rating, but that's usually more of a mechanical issue then electrical.

The true limit on encoder counts is the cRIO.

I don't know the official upper limit, but Austin Schuh on 254/971 has quoted me that a 64 count encoder on a CIM 1:1 (5300 rpm) works. This is ~5600 counts/second.

For velocity control at such speeds, you really don't need that many ticks per second.

A single "tick" encoder could be made with various forms of light sensors, hall effect sensors, etc...

[Mr. Rogers]

Sweet! Anybody know where I could find a 64 count or less encoder?

[AdamHeard]

In this case I think a hall effect or light sensor packaged right is a much cheaper option with plenty of accuracy.

A light sensor can be made into such a sensor by merely making the surface of your wheel an encoder disk of sorts. For example, if your shooter wheel is white/light colored, put 1-2 lines of black electrical tape on it. If it's black, do the opposite.

Far, far cheaper. You'd wire it as a single phase (not quadrature) encoder and just set the ticks per rotation to 1-2 (whatever you install on it).

[Joe Ross]

On the NI FIRST community, Joe Hershberger said the limit is 39,987 counts per second. https://decibel.ni.com/content/message/12523 All of this is handled by the FPGA, so there is no additional processor load as you increase the count rate.

Joe made one important caveat, that there is a perfect 90 degree phase relationship between the signals from the encoder. This isn't true with a real world encoder. I would leave 50-100% margin and only use a range of 30-20k counts per second.

[Mark McLeod]

We used a motor as an analog tachometer, instead of an encoder, the last time we did this.

[EricVanWyk]

Originally Posted by Mark McLeod

We used a motor as an analog tachometer, instead of an encoder, the last time we did this.

Mark -

Could you (have one of your students) submit a CD whitepaper on this?

I'd be very interested to hear their thoughts on it and see the exact setup.

[Mark McLeod]

Originally Posted by EricVanWyk

Mark -

Could you (have one of your students) submit a CD whitepaper on this?

I'd be very interested to hear their thoughts on it and see the exact setup.

Here's the whitepaper that was done at the time:
http://www.team358.org/files/electri...Tachometer.pdf

It never made it to CD whitepaper posting for some reason...

It's still working. We were using it the other night.

[EricVanWyk]

Originally Posted by Mark McLeod

Here's the whitepaper that was done at the time:
http://www.team358.org/files/electri...Tachometer.pdf

It never made it to CD whitepaper posting for some reason...

It's still working. We were using it the other night.

Thanks! One of my favorite lessons for electrical teams is the relationship between current and torque, voltage and speed.

As a side note the analog inputs can handle +/- 10V, so you could loosen the resistor divider, ditch D1 and replace D2 with something bi-directional.

[Ether]

Originally Posted by Joe Ross

On the NI FIRST community, Joe Hershberger said the limit is 39,987 counts per second. https://decibel.ni.com/content/message/12523 All of this is handled by the FPGA, so there is no additional processor load as you increase the count rate.

Joe made one important caveat, that there is a perfect 90 degree phase relationship between the signals from the encoder. This isn't true with a real world encoder. I would leave 50-100% margin and only use a range of 30-20k counts per second.

Since you don't need direction for this application, if you used just one channel from the encoder (physically disabled the other channel in the cable), would the FPGA processing still work? And would that help make the allowable speed higher?

[gpetilli]

Originally Posted by AdamHeard

The encoder itself should have an rpm rating, but that's usually more of a mechanical issue then electrical.

The true limit on encoder counts is the cRIO.

I don't know the official upper limit, but Austin Schuh on 254/971 has quoted me that a 64 count encoder on a CIM 1:1 (5300 rpm) works. This is ~5600 counts/second.

For velocity control at such speeds, you really don't need that many ticks per second.

A single "tick" encoder could be made with various forms of light sensors, hall effect sensors, etc...

The E4P-360 encoder is good for 10,000 RPM. I agree you dont need that many pulses for speed control, but mechanically it is the simplest to use since we are using the CIMple gearbox. We intend to hook the encoder to a Jaguar for speed control (dont know the limit but we will find out if it works).

You could use a simple LED/Photodiode pair with the spokes of the wheel to break the beam. Should be very reliable and assuming 6 spokes, gives you 6 pulses/rev.