How much PPR do you use on your encoders?
 

Just wondering what accuracy people look for in incremental encoders.
I'm using the USDigital method of PPR vs. CPR; CPR is Cycles Per Revolution and is 4x smaller than PPR (pulses per revolution).

Option 8 also applies if you use potentiometers or absolute encoders in the place of incremental ones. A post below if you're one of those teams would be appreciated.

Re: How much PPR do you use on your encoders?
 

Depends on what it's for :) Are we talking drivetrain?

Re: How much PPR do you use on your encoders?
 

For drive train we use 250 or 360, whichever have or get that season. They're more precise than we can reasonably use.

We also use absolute encoders (analog, no PPR) for where we need repeatability from powerup to powerup (think elevators).

For shooter wheels, it depends on the size of the wheel. We prefer to use 4 minimum, more if we can get it on the wheel itself (hall effect or similar sensor).

Re: How much PPR do you use on your encoders?
 

I think you have that backwards.

Re: How much PPR do you use on your encoders?
 

It's at least 7. Possibly 25 but definitely at least 7.

Re: How much PPR do you use on your encoders?
 

How people define CPR can depend on whether the decoder can do 4x decoding. In short if a decoder can count on rising/falling edges. So it is possible CPR to be higher than PPR by as much as 4x. Still changing direction requires a quick transistion of phase which makes this less than 4x.

Link:
https://granitedevices.com/wiki/Quadrature

Picture the function of the 4x decoder design like this:

1. Build a high speed asynchronous binary up/down counter.
2. Determine the minimum reliable pulse length to move the counter reliably.
3. Create a circuit that makes pulses of that minimum length on the rising edge and falling edge of the channel A/B encoder inputs (R/C time delay or even better a good crystal based TTL oscillator).
4. Logical OR the Channel A pulses to the Channel B pulses.

The resulting count will be 2X for each pulse of the encoder and 2X higher than expected because of the logical OR.

5. Now build a circuit to detect the leading phase and toggle the up/down count.
Interface to that whole thing how you like (SPI, I2C, parallel bus, RS232...)

Mind you the duty cycle of what you are counting (pulses on channel A/B of the encoder) is not 50% if you change direction of rotation or speed of rotation; and the duty cycle of the pulses you are creating on rising and falling edge are either extreme of duty cycle (depends on perspective).

Note: if you gate a crystal based TTL oscillator with a one-shot circuit you can turn the steady free-run pulses into the pulse for your counter on the input edges. Using RC time constants has all the same issues as a simple 555 timer pulse generator.

Note: I had to do this years ago in CUPL for an Altera CPLD.

Re: How much PPR do you use on your encoders?
 

For drive trains we like the Grayhill 63R. 256 or 128 PPR.

Nice and rugged. Not cheap. Very durable. We have used the same two sets for three consecutive seasons so far, with no complaints.

Re: How much PPR do you use on your encoders?
 

The OP explicitly defined CPR the way US Digital does: Cycles Per Rev, not Counts Per Rev.

In the context of the OP's (US Digital's) definition, the CPR rating of an encoder is never greater than PPR.

Re: How much PPR do you use on your encoders?
 

Yeap then the OP is confused.

Counts per revolution might be 4x higher because of the decoder, but cycles per revolution as you say is the same as PPR.

The only way this might not be the case would be having part of the quadrature decoder in the encoder and this is clearly not the case with most U.S. Digital encoders. At best the U.S. Digital encoders have some buffer functions in general.

This was why I posted in another topic the PPR not the CPR or anything else. Too confusing.

Re: How much PPR do you use on your encoders?
 

I did not say that. Neither does US Digital.

I said CPR (=Cycles Per Rev per US Digital) is never greater than PPR.

See attachment.

Re: How much PPR do you use on your encoders?
 

IOkay then what exactly is 'cycles per revolution' in that context?

I can see a 100 cycles per revolution encoder yielding 400 pulses per revolution.

I can see a 360 cycles per revolution encoder yielding 1440 pulses per revolution.

Those are all multiples of 4.
I have taken a ton of PCB out of these encoders (they fail a lot and not just in FIRST robots but on my MaxNC CNC tools) and there is no decoding in them.

Are they just being cute and declaring the pulses you could get in the decoder circuit with a 4x decode? Effectively exchanging the meaning of PPR and CPS as other companies use it?

Re: How much PPR do you use on your encoders?
 

Yup.
I knew it in my head as I was typing, and it came out all weird. :o I edited the post to reflect the correct notation.
I had it right in the poll though.

Probably just USDigital being weird. I find that I like their method because it essentially shows the maximum possible precision you can get with an encoder.
If your encoders fail a lot, you may want to consider just switching to magnetic encoders. 115 has killed many, many US Digital encoders in its time.

Re: How much PPR do you use on your encoders?
 

A cycle is one repeating pattern. It's a good way to define an encoder because it's independent of how you plan to use (decode) the signal.

The space between the red lines is one cycle.

One cycle can be 1 count (if you are counting only rising edges on one channel); or 2 counts (if you are counting only rising edges on 2 channels); or 4 counts (if you are counting rising and falling edges on 2 channels).

Re: How much PPR do you use on your encoders?
 

At best that is a matter of 2 differring terms for the same thing.

Yes using cycle in that context seemingly eliminates the idea you can get 4 pulses from the decoder circuit, but it ignores that not all decoders are 4x decoders.

What is the difference between a cycle and a pulse in a 1x decoder? Nothing. Even over time, a bunch of pulses and a bunch of cycles, still nothing.

Granted: to the point of the OP, U.S. Digital's use of the term is what matters so I will accept the cycles per revolution in their case is 4x lower than the potential PPR as they use the terms. I prefer to think of them the other way and simply assume the quadrature decoder circuit is 1x unless provided as part of the encoder assembly.

Still a lot of good information in here on the point, minus the ambiguity of the terms. The ambiguity of the term is itself notable.

Also: the failure rate for that style encoder Ether linked has to do with the end play of the shaft with the encoder disc. My MaxNC servos have eventually had encoder failures at the back of the steppers because the axis coupled to the shaft of the stepper exerts at times enough vibration (screw lash) and force to displace the disc and either scratch it or put it out of range of the detector. MaxNC has historically used a similar encoder from other companies and they suffered the same fate. I solved this problem using sealed encoders, a timing belt and a mount for the encoder. With 12 axis between these machines I'd have spent $1,400 on fixing those encoders or more by now without making those changes. Point being - I am noting a limitation of that style encoder not taking a shot at U.S. Digital.

Re: How much PPR do you use on your encoders?
 

I like that US Digital doesn't take the decoder into account. Their encoders don't come with decoders, so why should it be their job to decide things for you? They do provide both CPR and PPR if you want to calculate your counts per revolution given your own decoder. All US Digital encoders (to my knowledge) are 4 pulses per cycle, that is, A high, B high, A low, B low, so for them it makes sense to count it that way.
Your point about the 1x decoder seeing CPR and PPR as the same is valid, but then the designer would have to determine that themselves. Are we defining pulses as the actual counts the decoder spits out, or just the step changes coming in from the encoder?
AFAIK FRC encoder decoders (TalonSRX and RoboRio) count all the step changes/pulses anyway, so for the purposes of this discussion I think using PPR = 4 x CPR is the best way to define it.

EDIT: On topic: The results of the poll are pretty interesting. It looks like most people are using 256 or 512 CPR encoders, with a few people using 64 CPR (or just picked the wrong option in the poll... I should have used CPR instead).