Encoder PPR selection

What is the process for selecting how many ppr you need on a given drive application? What are the things to consider?

How do i determine what resolution i need?

The more pulses per rev the better but you can't exceed the count rate of your counter card or motion controller. The more counts per revolution the more accurate your position and speed estimates can be.

I agree with Peter. More is better until you can't see the pulses anymore. In drive applications, I start with the highest motor speed I will see then select a PPR that keeps the frequency below the lowest of the drive input frequency, the encoder output frequency and the encoder length/frequency envelope. With this method you will sometimes find that the PPR you can use is above the highest standard available pulse count from the manufacturer you selected. Unless the application is very critical stay withthe standard stuff; it is quicker to get.

Keith

Sorry keith can you break that down a little more? I am very lost on this one.

then select a PPR that keeps the frequency below the lowest of the drive input frequency

Frequency of the encoder?

We will try an example.

Motor max speed: 3000 RPM
Drive encoder card max input frequency: 150 kHz
Encoder max output frequency: 250 kHz

The max frequency values can be found in the device specs of whatever make you use.

The cable legth thing is a bit encoder specific. You probably want to talk to the encodser supplier but this is usually not the limiting factor unless the run is very long or the cable is really poor. See here for some additional information

So we start with the lowest frequency we know, which is the 150 kHz for the drive input. This translates to a PPR of:
150000 / (3000 / 60)
or 3000 pulses/rev.

Many manufacturers will not make a 3000 PPR encoder as standard. So you would go with the next lower available PPR that the manufacturer makes. For example, I use this encoder quite a bit for general purpose applications. 2500 PPR is the next lower available pulse count.

I hope this helps.

Keith

He means if using a 1024 ppr encoder and your motor max speed is 1750 then

1024 x 1750 = 1792000 pulses per minute at 1750 rpm

1792000/60 seconds = 29866 or 28.8 khz

Well then a counter card or some kind of controller with a maximum frequency of 30 khz will work

Man, you Georgia Tech boys.


Go Clemson

you beat me to it Keith

C'mon JRW gimme a break 1st quarter, 1st year and they are not teaching me this stuff yet just getting the basics out of the way.

Literatue,interpersonal realtions,Safety

The Plc Kid said:

C'mon JRW gimme a break 1st quarter, 1st year and they are not teaching me this stuff yet just getting the basics out of the way.

Literatue,interpersonal realtions,Safety

Click to expand...

I was just joking around!

I know. Me too.

I have customers using encoder that provide 524288 counts per revolution or 131072 ppr. Our controller counts each phase so it multiples the PPR by 4. This provides better velocity and acceleration estimation before using mathemagic to calculate even better velocity and acceleration estimates.
This limits the rotational rate of the encoder to about 20 encoder revs per second.

For instance it the roll is 50 inches or less in circumference then the distance per counts is less that 0.0001 inches. If the controller scan time is 0.001 second the raw velocity estimation is 0.1 inches per second. The raw acceleration is 0.0001/(0.001)^2 = 100 in/sec^2 or over a quarter g. Clearly this needs further processing even with the higher resolution.

People that use 1000 ppr encoders for application are limiting what the controller can do. The velocity estimation is so rough that it is no wonder people don't like to use the derivative gain.

Peter

give me one or two machine examples where you would need this level of precision please.

Dan Bentler

Peter what would be a good ppr for powerflex 700 vc drives running motors in rolls with matched speed requirements and ratios of before or after rolls?

No overspeed we stay within base speed ranges.Most oare 1750 rpm motors.

Encoders are not linear devices!!!!!!!

leitmotif said:

Peter

give me one or two machine examples where you would need this level of precision please.

Dan Bentler

Click to expand...

Any encoder that is going to be used as a master or reference should have the highest resolution possible. In my example above I showed that even with over 500,000 counts per revolution that the velocity resolution is only 0.1 inches per second. How does one gear to that?
Positioning systems should use the derivate gain which is a gain that is multiplied by the error between the target velocity and actual velocity. If you can't compute a decent actual velocity then the control output will be very 'noisy' looking. This really isn't noise. It is the effects of feedback quantizing or simply put, ENCODERS ARE NOT LINEAR DEVICES ARE THEY?
Ideally resolution would approach infinitely small. Then the non-linear encoders will appear to be linear. The goal of a good digital design it to approach that of an ideal analog design.

See the difference between a 4000 counts per revolution and 524288 counts per revolution

ftp://www.deltamotion.com/peter/PDF/Mathcad - t1p1 pid mrplc.pdf

The 'noise' does not excite any un-modeled poles because my software simulator doesn't have any but a real system has higher frequency poles that can get excited by the 'noise'. The drive will not like the 'noisy' control signal either.

This 'noise' affects how high you can crank up the gains, especially the derivative gain.

Most derivative 'noise' is actually feedback non-linearity or sample jitter

So what do you want on your motor?

Speed control systems like moving conveyors don't need to use a derivative gain. A PI controller will do. In this case you can get by with a lower PPR encoder but when gearing the master should always have a high PPR encoder. This way the slave can compute accurate feed forwards from the master's encoder.

PLC Kid, if you are gearing to a master the master should have a high PPR encoder but if the drives themselves are just doing speed control then buy the higher PPR where you don't need to spend extra money.
I would need more data to give a more exact answer.

Encoder selection

Peter,
Your last reply was very interresting.
Please find another thread of me I already posted concerning the same topic.
Some more questions :
-> You talk about 'sample jitter'. In my flying saw application with Siemens Simotion I experience this at the speed signal of the master encoder. From the outside the encoder wheel seems to run smooth but if I trace the speed I have high frequent fluctuations of the speed, and excesisve master accelerations.
In my system I have for master and slave a final resolution of 10 encoder pulses per mm (encoders are square wave incremental 5000 ppr). This master jitter results in a very aggressive slave gearing. How is this 'sample jitter' caused?
-> For a new comparable system I am considering higher resolutions. Final precision will be again 0.1 mm. Material speed is 100 mm/second. What encoder resolution should you advise? Can I choose the final precision of the master preciser then the slave (f.i. 0.05mm) or do I need an 1 to 1 ratio?
For higher resolutions should you advise sinuscosinus encoders or other types in spyte of square wave incremental encoders?
Thanks.