One encoder can only tell a controller how far the shaft has moved since some reference — and knows nothing about true position until it has been homed. The other tells the controller exactly where the shaft is, in a single instantaneous reading, the moment power comes on.
An incremental encoder and an absolute encoder can look identical from the outside — same shaft, same housing, same electrical connector — but they answer fundamentally different questions. An incremental encoder outputs a stream of pulses as the shaft turns, and a controller keeps a running count of those pulses; that count is a measure of change, relative to wherever counting happened to start, not a measure of true position. An absolute encoder outputs a distinct, unique code for every physical position the shaft can occupy, so reading that code — even before the shaft has moved at all — tells the controller exactly where it is. That difference decides what has to happen every single time the system powers up.
An incremental encoder has one main track (often two, 90° apart, for direction sensing) that produces a pulse each time the shaft advances by a fixed small angle. A controller's counter increments or decrements on every pulse edge, and position is computed as count × angle-per-count, measured relative to whatever value the counter happened to hold when counting began. The counter has no built-in relationship to the machine's real, physical coordinate frame — it only knows change. An absolute encoderinstead has multiple tracks — one per bit — arranged so that every distinct shaft position produces its own unique multi-bit code (commonly Gray code, so only one bit ever changes between adjacent positions). The controller doesn't count anything: it reads the code once, looks up what position that code represents, and immediately knows exactly where the shaft is — with no motion and no history required.
Every time an incremental-encoder system powers up, its counter starts from some default value — usually zero — but that value has no built-in relationship to the machine's real physical coordinate frame. The controller has to drive the axis to a known physical reference (a limit switch, a hard stop, or the encoder's once-per-revolution index/Z pulse) to reestablish what "count = 0" actually corresponds to in the real world. Only after that homing move is the running position trustworthy. An absolute encoder never has this gap: because every physical shaft position produces its own unique code, reading that code — even in the very first instant after power comes on, even if the shaft was rotated by hand while unpowered — immediately tells the controller exactly where it is, with no reference move required at all.
False, and it conflates two genuinely independent properties. Resolution — pulses (or counts, after quadrature decoding) per revolution — only describes how finely a changein position can be measured; going from 1,000 to 1,000,000 counts per revolution really does make each count represent a smaller angular step. But it does nothing about the referencing problem. An incremental encoder with a million counts per revolution still outputs nothing but pulses — the moment power is lost, even mid-motion, the running count is gone, and the controller has zero information about where the shaft physically sits when power returns. It still needs a full homing routine, exactly like a coarse, low-resolution incremental encoder would. An absolute encoder, even a comparatively modest one — say, a 12-bit unit resolving only 4,096 positions per revolution, far coarser than many incremental encoders — never faces this problem: because its output directly encodes position rather than counting toward it, reading the code once after power returns yields the exact position immediately, no matter how the shaft moved while unpowered. What eliminates homing isn't counts-per-revolution — it's whether the encoder outputs an absolute position at all.
Explains why an incremental encoder can only track relative position by counting pulses from an unknown starting reference — and must be homed to a known physical reference before its position is valid, every single time power is lost — while an absolute encoder outputs a unique code for every distinct shaft position, so the controller knows the exact position instantly at power-up, with no homing and no risk from motion that happened while the system was unpowered.
Incremental and absolute encoders are often compared purely on resolution — pulses or counts per revolution — because that's the spec most prominently listed on a datasheet and the easiest number to compare across products. That framing hides the more important difference: resolution describes how finely a change in position is measured, while the incremental/absolute distinction describes whether the sensor's output already tells you where you are, or only tells you how far you've moved since some earlier moment. A very high-resolution incremental encoder and a comparatively coarse absolute encoder can both be sold as "precision" position sensors, yet only one of them knows the shaft's true position the instant power comes on.
An incremental encoder disc carries one main track (often a second, 90° out of phase, so the controller can also determine direction of rotation) that produces a pulse each fixed angular increment of shaft rotation. Many also add a single once-per-revolution index (or "Z") pulse. A controller's counter increments or decrements on each pulse edge, and the running position is simply count × angle-per-count, relative to whatever value the counter held when counting began. That starting value has no inherent connection to the machine's real, physical coordinate frame — it's just wherever the counter happened to be reset to. Because of that, an incremental-encoder axis has to be driven to a known physical reference — a hard stop, limit switch, or the index pulse — every time the system powers up, before its reported position can be trusted. Losing power at any point, even briefly and even mid-motion, erases the running count and the (already fragile) relationship between "count value" and "true position," and the axis has to be re-homed before it can move safely again.
An absolute encoder disc carries multiple tracks — one per bit of resolution — arranged so that every distinct shaft position corresponds to its own unique multi-bit code across all the tracks. A bank of sensors, one per track, reads all the bits simultaneously, and the controller looks up the resulting code to know exactly where the shaft is — no counting, no accumulated history, and no motion required to get a valid reading. Real absolute-encoder tracks are typically laid out in Gray code rather than straightforward binary, specifically because Gray code changes only one bit between any two adjacent positions; if a sensor happens to read exactly at a transition boundary, the worst case is reading the adjacent position's code, never a wildly wrong value from several bits flipping at slightly different instants. Single-turn absolute encoders report position within one revolution; multi-turn absolute encoders add a geared or battery-backed turn counter so they also correctly track how many full revolutions have occurred, remaining valid across multiple turns and power cycles.
Resolution (pulses or counts per revolution for an incremental encoder, or bits of code for an absolute encoder) is about how finely position is measured — a purely quantitative property. Whether an encoder is incremental or absolute is about whether the sensor's raw output already identifies a position, or only identifies a change relative to an unknown starting point — a structural, qualitative property. These are independent: increasing an incremental encoder's resolution from 1,000 to 1,000,000 counts per revolution makes each measured step finer, but does nothing to give the controller a memory of true position across a power cycle — it still has to home. Decreasing an absolute encoder's resolution to a modest 12 bits (4,096 positions per revolution) still leaves it knowing the exact position instantly at every power-up, because that property comes from the code being unique per position, not from how many positions there are.
A single-turn absolute encoder generally does not — its code identifies position within one revolution the instant power is applied. A multi-turn absolute encoder needs its turn-count mechanism (geared counter wheels or a battery-backed electronic counter) to remain valid across power loss; if that turn-count is lost or the encoder isn't a true multi-turn unit, the within-revolution position stays correct but the recorded number of full turns can become wrong, which is a narrower problem than losing all position information the way an incremental encoder does.
Only by pairing it with counting electronics that never lose their count — for example, a battery-backed counter that keeps incrementing even with main power removed — which adds cost and a new failure mode (a dead backup battery silently reintroducing the original problem). It's far more common, and far more robust, to simply home the axis to a physical reference every power-up, or to use a true absolute encoder instead.
A single pulse channel only tells the controller that the shaft moved by one increment — it can't tell whether the shaft moved forward or backward. A second channel, offset 90° in phase from the first, lets the controller determine direction from which channel's edge leads the other, so the running count can correctly increment for one direction and decrement for the reverse.
In ordinary binary counting, moving between some adjacent positions flips multiple bits at once (for example 011 to 100), and if the sensors read those bits at very slightly different instants during a transition, the momentarily-read code can be a completely unrelated value, not just off by one position. Gray code is arranged so exactly one bit changes between any two adjacent positions, so a read caught mid-transition can only ever return the current or the adjacent position's code — never an arbitrarily wrong one.
Generally yes for the sensor itself, since it needs more tracks and sensing elements plus code-decoding electronics, or an internal microcontroller. That cost is frequently justified by removing homing time and hardware (limit switches, homing routines, home-search motion) and by eliminating the safety and functional risk of unknown position after any power loss — which matters most on axes like cranes, robot joints, or valves where undetected motion while unpowered is a real hazard.
Try our Mechatronics Studio
More calculators, simulators, and guides for this discipline.