Absolute vs Pulse type encoders

I'm curious as to what the experts think the advantages/disadvantages of absolute vs pulse type encoders?

I admit I have never used an absolute encoder but from what I have read it seems like an absolute encoder would be best suited for positioning and a pulse encoder would be used for rate/speed.

Any comments?

Been here done that

Take a look at this please: http://www.patchn.com/basicencoder.htm
AND
http://www.patchn.com/absolutencoder.html

Encoders

Absolute and Incremental encoders do the same thing but in a different way. The main advantage of the absolute encoder vs. an incremental encoder is you don't need to home the machine to calibrate the position. Each position correspond to a unique binary representation unlike the incremental where you only get a so many pulses per revolution. They are both good but I would say that it depends of the type of application you have and how much you want to spend.

Personally, I prefer using Absolute or a resolver.

An absolute encoder is very well suited to either situation.

A pulse encoder is also suited for either situation... if the pulses don't come too fast. If you use a high-speed counter with a pulse encoder then you are nearly doing the same thing as an absolute encoder except you do not get an "absolute" position indication... at least, not directly. In that case, you only get a more absolute count (That is not to say that the pulse encoder with a high-speed counter is more absolute than an absolute encoder).

Pulse encoders definitely need a "homing routine" or a "reset position" to synchronize positioning control. There really is such-a-thing as "fractional-pulses". They cause errors in calculations.

The degree of error caused by "fractional-pulses" depends on the mechanical ratio relationships in the process.

Even absolute encoders need a "reset position" if the motion exceeds the "turn-count" on the encoder. An absolute encoder can not properly indicate position accurately if the motion is always continuous in one direction. There is a "creeping error" effect because the inches-per-rev relationship is simply not precise enough.

An absolute encoder is more expensive than a pulse encoder.

If the need is simple, pulse encoders usually work well. If the need is more critical, in terms of time and position, then an absolute encoder becomes more desireable.

Originally posted by Terry Woods
There really is such-a-thing as "fractional-pulses". They cause errors in calculations.

Click to expand...

There could be a thread on this since it hasn't been discussed before.

Originally posted by Terry Woods
The degree of error caused by "fractional-pulses" depends on the mechanical ratio relationships in the process.

Click to expand...

Another good topic. A long at the number of counts to engineering units can be represented by a ration of two integers then there should be no lost fractions.

Originally posted by Terry Woods
Even absolute encoders need a "reset position" if the motion exceeds the "turn-count" on the encoder.

Click to expand...

An initial encoder offset is required during setup. Adjusting an encoder offset is much easier to do than to physically lining up the absolute encoder. We burn the encoder in to flash so the absolute encoder orientation is correct on startup.

Originally posted by Terry Woods
An absolute encoder can not properly indicate position accurately if the motion is always continuous in one direction. There is a "creeping error" effect because the inches-per-rev relationship is simply not precise enough.

Click to expand...

I have many SSI absolute encoder systems running in saw mill that synchronize grading tables and timer table. They run all day without problems. The trick is that you must have one lug per revolution or per two revolutions etc.

Originally posted by Terry Woods
An absolute encoder is more expensive than a pulse encoder.

Click to expand...

A 13 bit, 0 to 8191, SSI absolute encoder cost less than $400

Originally posted by Terry Woods
If the need is simple, pulse encoders usually work well.

Click to expand...

I think one should be more specific about pulse encoders and quadrature encoders. They are not the same thing.

Originally posted by Terry Woods
If the need is more critical, in terms of time and position, then an absolute encoder becomes more desireable.

Click to expand...

Quadrature encoders are a must in high bandwidth ( much faster than PLC ) applications. The phase delay of the absolute encoders can be very detrimental. For application where the load is big and the bandwidth is low I like SSI. I also like the fact that one can mix and match linear SSI MDTs with rotary SSI absolute encoders.

Posted by Peter...
I have many SSI absolute encoder systems running in saw mill that synchronize grading tables and timer table. They run all day without problems. The trick is that you must have one lug per revolution or per two revolutions etc.

Click to expand...

Peter,
You said... "The trick is that you must have one lug per revolution or per two revolutions etc."

I assume that... no... I'll ask...
Do you mean one lug cycle per X-number of encoder revolutions (where X is an integer)?

If so, then I assume that... no... again, I'll ask...
Are you saying that your encoder is mounted at the "Driven-end" and not on the motor?

Again, if so, then I'll agree with your statement.

However, in the general industrial world, much of the local machinery is designed on-site and maintained on-site. Whether or not the "mechanical designer" was savy enough to recognize the control issues in the design... well, who knows? Then there is the "electrical designer"... maybe. The electrical design might also have been done by the mechanical designer. Whether or not the control portion was designed by a person that is aware of these issues is also a case of... who knows? (The same concerns might also be raised with respect to some of the so-called "Pro's".)

There are many motor systems with built-in encoders. That places the encoder at the "Drive-end". Between the Drive-end and the Driven-end there is usually some sort of gearing mechanisms. There is a wide variety of mechanisms (pulleys, gears, etc) available to produce the desired effect. Depending on the particular combination, the Drive-to-Driven ratio will be either a rational number or an irrational number.

Entropy (some might know this as "Murphy") forces all "rational-systems" towards "irrationality".

It is one thing to declare that Drive-to-Driven ratios consisting of irrational numbers is simply not allowed in the world of automated controls. However, that declaration is virtually impossible to enforce. Things break, parts wear out of tolerance, and occasionally, someone has an "idea".

Since there are infinitely more irrational numbers than there are rational numbers, the odds are that the system will end up having an irrational "Drive-to-Driven" ratio.

If the mechanical gearing between a motor and a driven device produces a ratio consisting of an irrational number (7/3 = 2.333...333...), then there is a built-in error. In that situation, if relative calculations are performed with Integer Math, then the error will certainly grow very quickly.

Of course, it is much better if relative calculations are performed with real numbers. However, the "3's" in "2.333..." go to infinity. Real Math operations in a computer can not produce that kind of precision. The error might be very small, and it might be a relatively long time before it becomes noticable, but it is there and it is growing. It is this kind of situation that demands that there be some sort of synchronization before the error becomes a problem. In some cases, a system can run many, many, cycles before the error becomes a problem. In other cases, the error becomes a problem on the second cycle.

It is this very issue that lead to the awareness of "CHAOS".

No... Not the "C.H.A.O.S." that Maxwell Smart was chasing... but rather, the "CHAOS" that develops in weather pattern models simply because a butterfly in Burma sneezed. So small an effect... maybe something like, 1/google^google... and yet, such far reaching consequences.

Damn! I feel a tangent comin' on.

Fractions/Ratios Rule!!!!!

Originally posted by Terry Woods
Peter,
You said... "The trick is that you must have one lug per revolution or per two revolutions etc."

I assume that... no... I'll ask...
Do you mean one lug cycle per X-number of encoder revolutions (where X is an integer)?

If so, then I assume that... no... again, I'll ask...
Are you saying that your encoder is mounted at the "Driven-end" and not on the motor?

Again, if so, then I'll agree with your statement.

Yes, however now that I have had time to think about it there was this one application where there were 3 stations on a rotating table. Each station was 120 degrees so each index move was 120 degress. Our module was calibrated to go from 0-3599 degrees for 0-8191 counts of the encoder. The station was indexed by 1200 engineeinrg units. Even though this does not equate to an even number of counts we handle this situation. We never loose registration.

Originally posted by Terry Woods
However, in the general industrial world, much of the local machinery is designed on-site and maintained on-site. Whether or not the "mechanical designer" was savy enough to recognize the control issues in the design... well, who knows? Then there is the "electrical designer"... maybe. The electrical design might also have been done by the mechanical designer. Whether or not the control portion was designed by a person that is aware of these issues is also a case of... who knows? (The same concerns might also be raised with respect to some of the so-called "Pro's".)

I have seen this too and they wonder why the counts and the position units don't match at the end of the day, or shift, or hour etc. I must explain why the ratio they have chosen can't be ever work and they must use the abosulte encoder like an incremental encoder.

Fractions are neat! I never have to make an excuse when I use fractions. Floating point is flawed and doesn't handle the ratio of two integer numbers correctly. What is worse is that I must beat this into my guys too. TOO MANY PEOPLE THINK FLOATING POINT IS THE ANSWER TO THESE PROBLEMS AND ITS NOT!

Originally posted by Terry Woods
There are many motor systems with built-in encoders. That places the encoder at the "Drive-end". Between the Drive-end and the Driven-end there is usually some sort of gearing mechanisms. There is a wide variety of mechanisms (pulleys, gears, etc) available to produce the desired effect. Depending on the particular combination, the Drive-to-Driven ratio will be either a rational number or an irrational number.

Click to expand...

One should be able to handle the rational numbers. If the system has irrational number like ones that involve PI then one is out of luck. One should just use incremental encoders and homing input that homes on every rotation.

Originally posted by Terry Woods
Entropy (some might know this as "Murphy") forces all "rational-systems" towards "irrationality".

It is one thing to declare that Drive-to-Driven ratios consisting of irrational numbers is simply not allowed in the world of automated controls. However, that declaration is virtually impossible to enforce. Things break, parts wear out of tolerance, and occasionally, someone has an "idea".

Since there are infinitely more irrational numbers than there are rational numbers, the odds are that the system will end up having an irrational "Drive-to-Driven" ratio.

If the mechanical gearing between a motor and a driven device produces a ratio consisting of an irrational number (7/3 = 2.333...333...), then there is a built-in error. In that situation, if relative calculations are performed with Integer Math, then the error will certainly grow very quickly.

Of course, it is much better if relative calculations are performed with real numbers. However, the "3's" in "2.333..." go to infinity. Real Math operations in a computer can not produce that kind of precision. The error might be very small, and it might be a relatively long time before it becomes noticable, but it is there and it is growing. It is this kind of situation that demands that there be some sort of synchronization before the error becomes a problem. In some cases, a system can run many, many, cycles before the error becomes a problem. In other cases, the error becomes a problem on the second cycle.

Click to expand...

Most of these situations can be handled if one uses ratios or fractions. We have just released a new motion controller with a 32 bit DSP. That sounds neat but the GEARING MUST BE DONE USING RATIOS OR FRACTIONS, NOT WITH FLOATING POINT! It requires that I put in some extra effort, but like I said before, I will not have to make any excuses at the end of the day because the counts WILL line up with the position units. The mechanical guys will appreciate that because they look good. The mechanical guy needs to do is make sure his machinery uses ratios of integer numbers where the integer numbers are between 1 and 2^24. The 2^24 is highest integer number that can be respresent in a 32 bit floating point number. That isn't too much for the control guy to ask.

Terry becomes irrational and chaotic at this point. My fractions can't handle that. I don't know how to respond

Scott, you were asking about pulse encoders. These are just simple encoders that generate pulses so many times per revolution. Quadrature encoders allow one to determine direction. Both are incremental.

Click to expand...

Click to expand...

Click to expand...

Click to expand...