← Robotics & Automation Studio
Concept Explainer · Robotics & Automation

Absolute vs. Incremental Encoders

Why some robots have to run a homing routine after a power loss — and others just power up already knowing exactly where every joint is.

Both devices bolt onto the same spot on a motor shaft and both report shaft position back to a controller — but they answer a fundamentally different question. An incremental encoder reports how much the shaft just moved, as a stream of pulses the controller has to count. An absolute encoder reports exactly where the shaft is right now, as a unique code, no counting or history required. That single difference is the entire reason some machines need to "go find home" every time they power up, and others don't.

The Setup

Two ways to read a rotating shaft

An incremental encoder disk carries one track of alternating slots. As the shaft turns, light (or a magnetic field, on non-optical designs) passing through those slots produces a stream of pulses on two channels — A and B — offset from each other so the controller can also tell direction. Some disks add a single extra slot, the index or Z pulse, that fires exactly once per revolution. An absolute encoder disk instead carries several concentric code tracks (or, increasingly, a purpose-built position-sensing IC), arranged so that every angular position produces its own distinct combination of bits — a code that's different for every position on the disk and is valid the instant you read it, with no rotation required first.

Incremental encoder — counts pulses, remembers nothing

Requires homing
NORMAL OPERATIONshaft rotates12,406 counts ▲controller counts A/B pulses;index (Z) fires once per revPOWER LOST??? countspulse history is gone —no reference remainsHOMING ROUTINEsweeps to referencelimit switchre-zeroes the count at a knownposition before resuming normal use
What it outputs
A/B pulse stream
Plus, on many designs, a single index (Z) pulse once per revolution.
Position after power loss
Unknown
The count lived in the controller's memory, not the encoder — a homing move is required before resuming.

Absolute encoder — the code already is the position

No homing needed
NORMAL OPERATIONCODE: 1011unique code = exact shaft angle,valid the instant it's readPOWER LOST(shaft doesn't movewhile power is off)POWER RESTOREDCODE: 1011same exact code, read instantly —no motion, no homing move
What it outputs
A unique position code
Via multiple code tracks, or a purpose-built position-sensing IC — readable at power-up, no motion required.
Position after power loss
Known immediately
The encoder itself knows its position — no counting, no history, no homing move.
Why this works

One encoder measures change. The other measures state.

An incremental encoder's pulses don't mean anything about position by themselves — a single A/B pulse just says "the shaft moved one more increment," not which increment. The actual position number only exists because the controller has been keeping a running tally in volatile memory since some earlier starting point. Cut power, reset the controller, or lose the connection mid-count, and that tally is simply gone — there was never anything more permanent than a number in RAM to begin with. That's why a homing routine exists: drive the joint to a known mechanical reference (a limit switch, a hard stop, or the index pulse combined with one), and re-zero the count there before trusting it again.

An absolute encoder never relies on a running tally at all. Its code tracks (or internal position-sensing IC) are arranged so that every angular position produces one specific, unique output — the measurement is a direct readout of where the shaft is, not an accumulation of where it's been. Power the encoder up cold, with the shaft sitting anywhere, and it reports the correct position on the very first read. There's nothing to recover, because nothing was ever lost.

Common misconception
"An encoder is an encoder — incremental and absolute just differ in resolution, not in what kind of information they provide."

It's an easy assumption, since both types are commonly sold with resolution specs (counts or bits per revolution) front and center in the datasheet — but resolution is not what distinguishes them. The real difference is what kind of information the device fundamentally provides: an incremental encoder provides relative motion counting, which requires a homing routine after any power loss or controller reset to re-establish a reference point. An absolute encoder provides true absolute position, readable immediately at power-up, with no homing move needed at all. A 20-bit incremental encoder with enormous resolution still has zero memory of absolute position and still needs to be homed after a reset — resolution never fixes that. Meanwhile even a coarse, modest-resolution absolute encoder retains true position knowledge straight through a power cycle. Resolution tells you how finely a position is measured. Absolute vs. incremental tells you whether that position survives a power cycle at all — and that second question, not the first, is what actually determines whether a system needs a homing routine.

Related Concept Explainers
Redundancy vs. Fault Tolerance
Read it →
Servo vs Stepper Motors: Encoder Feedback for Robotics
Read it →

Absolute vs. Incremental Encoders — Concept Explainer

Explains why incremental encoders — which report position by having a controller count A/B pulses — lose all position knowledge on a power loss or controller reset and require a homing routine to recover, while absolute encoders output a unique digital code representing the shaft's exact position at every instant, readable immediately at power-up with no homing move needed.

Why This Is Commonly Misunderstood

It's tempting to treat "incremental" and "absolute" as just marketing terms for "cheaper" and "more precise," especially since higher-end encoders of both types often do carry higher resolution specs. But resolution (counts or bits per revolution) and type (incremental vs. absolute) are independent properties. A high-resolution incremental encoder is still a relative-motion counter with zero memory of absolute position, and it still needs homing after any power loss. A modest-resolution absolute encoder still retains exact position knowledge through a power cycle. The distinction that actually matters is whether the device measures change over time (incremental) or state at an instant (absolute).

How Each Type Actually Works

An incremental encoder disk carries a track of alternating opaque and transparent (or magnetically alternating) slots. As the shaft rotates, this produces a stream of pulses on two channels offset from each other by 90 electrical degrees — quadrature A/B — which lets the controller determine both how far the shaft moved and which direction. Many incremental encoders add a single index or Z pulse that fires exactly once per revolution, useful as a coarse reference during homing. Critically, none of this pulse stream carries position information by itself; the controller has to integrate (count) the pulses over time, starting from some known reference, to derive a position value that exists only in its own memory.

An absolute encoder instead directly encodes position into its output. Classic designs use several concentric code tracks (commonly Gray code, which changes only one bit between adjacent positions to avoid ambiguous transitional readings), so that the specific combination of bits read across all tracks is unique for every angular position on the disk. Newer designs increasingly replace multiple mechanical tracks with a single sensing element — a magnetic or capacitive sensor paired with an ASIC that computes the absolute angle directly. Either way, the output is a direct measurement of where the shaft is right now, not an accumulated count of where it has been.

Where This Matters in Practice

Incremental encoders are simpler and less expensive, and that's a perfectly good tradeoff whenever a homing move at startup is acceptable, or when only relative motion matters in the first place — tracking conveyor belt speed, spindle RPM, or general velocity feedback, for example, doesn't require remembering an absolute reference through a power cycle. Absolute encoders cost more, owing to their more complex internal construction, but they earn that cost back anywhere a homing routine on every power-up is unacceptable: a multi-joint robot arm that must know its exact position immediately after a momentary power interruption, without sweeping blindly through unknown space to re-home (which can itself be hazardous, or simply too slow for the application's duty cycle); collaborative robots that must resume safely without an unpredictable homing motion near people; or any machine where "go find home first" is operationally unacceptable. It's also worth noting that multi-turn absolute encoders (which must track full revolutions beyond 0–360°, not just angle within one turn) typically need either a battery-backed counter or additional internal gearing/tracks to preserve the turn count itself through a power loss — the single-turn angular reading survives a power cycle inherently, but multi-turn count retention is an added design feature, not automatic.

Frequently asked questions

What is the fundamental difference between absolute and incremental encoders?

An incremental encoder outputs a stream of pulses that a controller counts to track relative motion — it has no memory of absolute position. An absolute encoder outputs a unique code representing the shaft's exact position at every instant, independent of any counting history.

Why do incremental encoders need a homing routine?

Because the position "value" only ever existed as a running count in the controller's memory, built up by tallying pulses since some earlier reference point. A power loss or controller reset erases that count entirely, so the system has to move to a known mechanical reference — a limit switch, hard stop, or the index/Z pulse combined with one — and re-zero the count there before it can trust its position again.

Do absolute encoders ever need a homing move?

A single-turn absolute encoder reads the exact shaft angle correctly on the very first power-up, with no homing move required. Multi-turn absolute encoders, which also track how many full revolutions have occurred, need a battery-backed counter or additional internal gearing/tracks to preserve that turn count through a power loss — without one of those, the multi-turn count (not the single-turn angle) could still be lost.

Is the index (Z) pulse on an incremental encoder the same as absolute position?

No. The index pulse only fires once per revolution as a mechanical reference point — by itself it doesn't identify which revolution the shaft is in or what the current position is. It's used during a homing routine, typically combined with a limit switch or hard stop, to precisely re-zero the counter, not as a substitute for absolute position measurement.

Why would anyone still choose an incremental encoder if absolute encoders are better?

Cost and simplicity. Incremental encoders are cheaper and mechanically/electrically simpler, and that's a perfectly good tradeoff for applications where a homing move at startup is tolerable, or where only continuous relative motion matters — conveyor speed or spindle RPM feedback, for instance, where there's no need to retain an absolute reference through a power cycle.

Does higher resolution make an incremental encoder behave like an absolute encoder?

No — this is the core misconception. Resolution (counts or bits per revolution) is completely independent of type. A very high-resolution incremental encoder still has zero absolute-position memory and still requires homing after any power loss or reset. A low-resolution absolute encoder still retains true position knowledge through a power cycle. What determines whether homing is needed is whether the encoder provides relative counting or true absolute position — not how fine its resolution is.

🎓

Try our Robotics & Automation Studio

More calculators, simulators, and guides for this discipline.

Related tools & guides

Redundancy vs. Fault Tolerance — Concept ExplainerServo vs Stepper Motors: Precision Motion Control and Encoder FeedbackAutomation Sensor Selection ReferenceMotor Torque Sizing Calculator