Robot Maintenance & Troubleshooting: The Ultimate Guide

A robot that runs a production line does not fail all at once. It fails in stages, and most of those stages leave a trace: a bearing that runs a few degrees hotter, a following error that grows a count each week, a cable that throws an intermittent CAN fault only when the arm is at full reach. The whole discipline of maintenance is the practice of reading those traces before the machine reads them for you by stopping in the middle of a cycle with a red beacon and a line of parts backing up behind it.

This guide is for the people who keep robots running: maintenance techs, controls engineers, reliability engineers, and the integrators who have to write the service plan before the cell is even bought off. It covers the two philosophies (preventive and predictive) and where each actually pays, the failure modes that dominate the field data and their early signs, the diagnostics you already own in the controller and the ones you have to add, condition monitoring and the honest cost of moving to predictive, a troubleshooting method that works when you have no idea what is wrong, spare-parts and MTBF/MTTR strategy, calibration drift, and the downtime economics that decide how much of all this is worth doing.

The numbers here are ranges, because a SCARA doing 60 cycles a minute in a clean electronics plant and a foundry arm tending a die-cast machine wear on completely different clocks. Treat the ranges as starting points and let your own logs correct them.

The take: Most robot downtime comes from the peripherals (cables, connectors, grippers, sensors, the dress pack) and from maintenance that was skipped, deferred, or done wrong. The robot itself is rarely the cause. Preventive maintenance on a calendar buys you a known floor of reliability cheaply. Predictive maintenance buys you the last chunk of avoidable downtime expensively, and only pays when a stoppage costs more than the sensors and analysis. Know which regime you are in before you spend, log everything from day one, and treat the fault code as a starting hypothesis you still have to confirm.

Companion reading: robot safety & functional safety, robot calibration, bearings for robotics, robot wiring, cables & connectors, and industrial robot arms.

Table of contents

1. Key takeaways
2. Preventive vs predictive: two philosophies
3. The failure modes that actually dominate
4. Early signs: a symptom-to-cause table
5. Diagnostics you already own: logs and fault codes
6. Motor current signatures
7. Vibration and thermal monitoring
8. Condition monitoring and the move to predictive
9. A troubleshooting methodology
10. Spare parts, MTBF and MTTR
11. Calibration drift
12. The economics of downtime
13. Frequently asked questions

Preventive vs predictive: two philosophies

There are, in practice, four maintenance strategies, and every real program is a mix of them.

Reactive (run-to-failure). Fix it when it breaks. Rational for cheap, non-critical, redundant components where the failure is benign and the part is a five-minute swap: a proximity sensor on a non-safety input, an indicator lamp, a suction cup. Irrational for anything that stops the line or fails destructively.

Preventive (time or cycle based). Service on a schedule regardless of condition: grease the gearboxes every N hours, replace the encoder backup batteries before they die, swap the dress pack cables at a set cycle count, check backlash quarterly. This is the backbone of every OEM maintenance manual. FANUC, ABB, KUKA, Yaskawa, and Universal Robots all publish interval-based schedules keyed to operating hours (FANUC's periodic tables, for example, use tiers around 3,840 h / 7,680 h / 11,520 h for the big arms, roughly 1, 2 and 3 years at nominal duty, or annual for lighter duty). It is cheap, predictable, and it addresses the failure modes that are actually correlated with time or cycles: lubricant degradation, seal wear, battery depletion, cable fatigue.

Predictive (condition based). Measure the actual condition (vibration, temperature, current, oil particle count, backlash) and act when the trend crosses a threshold. You replace the bearing on its actual condition, when it starts to signal. This captures the failures preventive misses and avoids replacing parts that still have life, but it costs sensors, data infrastructure, and someone who can interpret the signals.

Prescriptive / model-based. The newer layer: feed the condition data to a model (physics-based, statistical, or learned) that estimates remaining useful life and recommends the specific action. Real in high-value fleets, oversold everywhere else.

Rule of thumb: use the P-F interval to decide. From the point a failure becomes detectable (P) to the point of functional failure (F) is the P-F interval. If it is long (weeks to months, as with lubricant breakdown or slow bearing spalling), condition monitoring at a sensible inspection interval catches it. If it is short (a connector that goes from intermittent to open in a day), predictive monitoring has to be near-continuous to help, and often preventive replacement is cheaper.

The honest framing: preventive and predictive do different jobs and both stay in the program. Preventive handles the time-correlated wear-out failures cheaply. Predictive handles the condition-driven ones that would otherwise be random surprises. The classic reliability result behind this is that most components do not follow the "bathtub curve" assumption that everything wears out on a schedule. A large fraction of failure modes are effectively random over the useful life (the United Airlines / Nowlan and Heap study famously found the majority of failure patterns had no strong age-reliability relationship), which is exactly why blindly replacing good parts on a calendar can introduce infant-mortality failures. Match the strategy to the failure mode, component by component.

The failure modes that actually dominate

Walk the fault log of any robot fleet and the distribution is lopsided. The heavy, expensive, precision components (harmonic drives, RV gearboxes, servo motors) are engineered for tens of thousands of hours and rarely fail first. The things that flex, mate, wear, or get crashed fail first. Here is where the time actually goes, roughly in order of downtime contribution on a typical industrial arm.

Cables and connectors (the dress pack). The single biggest source of intermittent, maddening faults. Internal harness and external dress-pack cables flex millions of times. Conductors work-harden and break, shields fray, and connector pins fret and oxidize. The signature is intermittent: a CAN or EtherCAT error that only appears at a specific pose, a signal that drops when the arm twists axis 6. See robot wiring, cables & connectors for construction and routing that extends life. Continuous-flex cable in a properly sized energy chain lasts; a stock cable zip-tied to move with the arm does not.

End-effectors and grippers. Suction cups perish and leak, gripper fingers wear and lose grip, pneumatic seals blow, force sensors drift. High cycle counts, direct contact with the workpiece, and often the least-robust part of the whole system. Usually cheap to fix but a frequent stopper. See end-effectors & grippers.

Bearings. Every joint rides on them, and they are a classic wear-out item with a well-understood life model. When they go, you get noise, vibration, heat, and rising friction (which the motor sees as rising current). Rarely sudden if you are watching; see bearings for robotics.

Belts and secondary drives. On robots that use them (some SCARAs, gantries, and lighter arms), timing belts stretch, lose tooth profile, and eventually shed teeth or slip, which shows up as lost position and following error. Tension drifts over the first hundred hours and then again as they age.

Gearboxes (harmonic and cycloidal/RV). The precision reducers. Long-lived, but not immortal. Wear shows up as increasing backlash and lost motion, elevated running torque, metallic particles in the grease, and vibration at gear-mesh and wave-generator frequencies. When a strain-wave gear finally fails it can go from "slightly notchy" to catastrophic quickly, so trending backlash and grease condition matters. See gearboxes: harmonic & cycloidal.

Servo motors. Robust. The common failure modes are winding insulation breakdown (heat and age), bearing failure (see above, the motor bearing is often the first to go), and brake wear on braked axes. Overheating from blocked cooling, over-cycling, or a sticking brake is the usual accelerant.

Encoders and feedback. Optical encoders foul or lose signal; the battery-backed absolute encoders that most arms use lose their position reference when the backup battery dies, forcing a re-master. A dead encoder battery discovered on a Monday morning after a power-off weekend is a classic avoidable outage. See encoders.

Drives and controller electronics. Power stages, capacitors (which dry out with heat and age), cooling fans, and contactors. Fans and electrolytic caps are the wear items; the fan usually warns you first (noise, then a thermal fault).

Early signs: a symptom-to-cause table

The value of experience is pattern-matching a symptom to a short list of causes. This table encodes some of that. None of these is diagnostic on its own; each is a hypothesis to confirm.

Symptom / observation	Likely causes	First checks
Intermittent bus fault (CAN/EtherCAT) tied to a specific pose	Cable/conductor break, connector fretting, shield damage in dress pack	Wiggle test at pose, inspect flex points, check connector seating, trend error counters
Rising average motor torque/current at same payload and speed	Increasing friction: bearing wear, dry gearbox, brake dragging, mechanical bind	Compare per-axis torque to baseline, back-drive by hand (power off), check grease
New vibration or audible noise from a joint	Bearing spalling, gear-mesh defect, loose fastener, imbalance	Vibration spectrum, touch/listen at running temp, torque-check mounting bolts
Joint runs hotter than its neighbors	Bearing friction, brake drag, overload, blocked cooling, lubricant breakdown	Thermal camera baseline vs now, check duty cycle, verify payload config
Growing position/following error, occasional	Belt stretch/slip, backlash growth, encoder coupling slip, loose reducer	Read following error trend, backlash test, inspect coupling and belt tension
Robot places parts progressively off-target	Calibration/mastering drift, TCP change, worn tooling, thermal growth	Re-check TCP, verify mastering, inspect end-effector, warm-up drift test
Encoder / position-lost fault after power-down	Dead encoder backup battery, encoder fault, brake released while off	Check battery voltage/age, re-master, verify battery replacement interval
Grip failures, dropped parts	Worn/leaking suction cups, gripper seal wear, low air pressure, force-sensor drift	Vacuum/pressure check, inspect cups/fingers, recalibrate force sensing
Overload / collision fault with no visible crash	Wrong payload/inertia config, mechanical bind, failing bearing, drive fault	Verify payload parameters, back-drive check, read drive fault detail
Drive thermal fault or fan alarm	Failed/clogged cooling fan, high ambient, dried-out caps, over-duty	Check fan, clean filters, log cabinet temp, inspect drive age
Slow drift of accuracy over a shift	Thermal expansion (cold-start vs warm), a normal warm-up effect	Warm-up routine, re-baseline accuracy warm, compensate if supported

War story: A palletizing cell threw a random axis-6 communication fault maybe twice a week, always cleared on restart, never on a schedule anyone could see. Two encoder swaps and a drive swap later it was still happening. The actual cause was a single conductor in the dress pack, cracked but not fully broken, that opened only when axis 6 rotated past 170 degrees during one specific SKU's approach. It was invisible on a static continuity check and only found by flexing the harness at that pose with a meter on the line. The lesson: intermittent-and-pose-dependent means cable until proven otherwise, and no amount of swapping black boxes finds a broken wire.

Diagnostics you already own: logs and fault codes

Before you buy a single condition-monitoring sensor, mine the data the robot already produces. Every modern controller (FANUC R-30iB, ABB OmniCore/IRC5, KUKA KR C4/C5, Yaskawa YRC1000, UR's PolyScope) logs far more than the alarm banner shows.

The fault/alarm log. Timestamps, codes, and often the axis and the machine state at fault. The first move on any recurring problem is to export this log and look at the distribution: which code, which axis, what time of day, what program step, what was running. A fault that clusters on one SKU, one axis, and the third hour of a shift is telling you something a single alarm never could. Correlate the code against the vendor's fault reference; robot fault codes are documented and usually point at a subsystem (servo, encoder, communication, overload, brake) even when they cannot name the root cause.

Servo and drive telemetry. This is the underused gold. Most controllers expose, per axis, at least: commanded vs actual position (the following/position error), torque or current command, motor and sometimes drive temperature, and disturbance/collision estimates. You can log these:

• Following error trending upward on one axis at constant conditions means the mechanical path is getting harder to move or the feedback is degrading.
• Torque at reference points (the same pose, same payload, same speed) is a repeatable friction probe. Log the torque to hold or move through a fixed reference pose weekly; a rising trend is wear.
• Collision/disturbance torque thresholds that start tripping at loads that used to be fine indicate that internal friction is growing; nothing actually collided.

Cycle time and axis counters. The controller knows total operating hours, per-axis motion counts, and often per-axis operating time. These drive the preventive schedule (grease intervals are in hours or cycles, not calendar days) and flag axes that are working harder than expected.

Rule of thumb: baseline everything when the robot is new and healthy. The single most valuable maintenance artifact is a "golden" record: torque, following error, temperature, vibration, and a TCP accuracy check taken when the machine was commissioned. Every later reading is meaningful only against that baseline. A vibration spectrum with no healthy reference is nearly useless; the same spectrum next to the day-one spectrum is a diagnosis.

Motor current signatures

Motor current is the cheapest and most information-dense condition signal on a robot, because the motor is a load cell you already installed. Any change in the mechanical load (friction, imbalance, a defect that adds a periodic drag) shows up in the current the drive has to supply. This is the basis of motor current signature analysis (MCSA), long used on large induction motors and increasingly on servo axes.

The practical readings:

Average torque/current at fixed conditions. Hold payload, speed, and pose constant and the steady-state current is a direct proxy for friction. A slow rise over weeks is the clearest early sign of bearing wear, lubricant breakdown, a dragging brake, or a developing bind. This is trivial to trend and needs no extra hardware.

Torque ripple. A healthy joint moving at constant velocity draws a fairly smooth current. Growing ripple, especially periodic ripple synchronized to shaft or gear rotation, points at a mechanical defect: a spalled bearing raceway hits once per revolution, a chipped gear tooth once per mesh. The frequency of the ripple locates the fault.

Spectral analysis. Take the current (or the torque command) over a constant-speed move and run an FFT. Defects appear as peaks at characteristic frequencies:

• A bearing defect shows peaks at its characteristic frequencies (ball-pass frequency of the outer/inner race, ball-spin, cage), which are functions of geometry and shaft speed. On a rotating shaft at speed f, the outer-race defect frequency is BPFO = (n/2)·f·(1 - (d/D)·cos φ) for n balls, ball diameter d, pitch diameter D, contact angle φ; a rough rule is BPFO ≈ 0.4·n·f. A rising peak there is a bearing starting to spall.
• A gear defect shows a peak at the gear-mesh frequency (teeth × shaft speed) and its sidebands.
• A belt defect shows peaks at the belt frequency.

You do not always need dedicated hardware for this. Many drives can stream current at a useful rate, and the pattern (baseline vs now) matters more than absolute calibration. Where you need finer resolution, a clamp-style current probe on the motor lead into a data logger gets you there cheaply. The motor-drive side of this is covered in motor controllers & FOC and power electronics & motor drives.

The limitation: current signature is best on constant-speed, constant-load segments. Robot motion is highly variable, so the trick is to insert a fixed diagnostic move into the maintenance routine: a slow, constant-velocity sweep of each axis, unloaded, run identically every time, so the current traces are comparable. That standardized probe move is worth more than continuous logging of production motion, because it removes the variability that swamps the signal.

Vibration and thermal monitoring

These are the two classic condition-monitoring channels, borrowed from rotating-machinery reliability and adapted to robots.

Vibration. A tri-axial accelerometer (MEMS units are cheap now, IEPE/piezo for higher fidelity) on a joint housing captures the mechanical health of the bearings and gears directly. The analysis mirrors current signature analysis: overall RMS/velocity level as a coarse health number, and spectral peaks at bearing and gear-mesh frequencies for diagnosis. The standard framing (ISO 20816 for machine vibration evaluation, ISO 13373 for condition-monitoring vibration methods) sets zones from "good" to "unacceptable" against a baseline. On robots the challenge is again the variable duty cycle, so the standardized diagnostic move applies here too: sweep the axis the same way every time and compare spectra.

Two useful refinements from bearing diagnostics:

• Envelope (demodulation) analysis pulls out the low-energy, high-frequency impacts of an early bearing defect that a raw spectrum buries under gear and structural energy. It is the standard technique for catching bearing spalling early.
• Crest factor (peak / RMS) rises early in bearing failure as sharp impacts appear, then can fall again as the defect spreads and the signal becomes broadband. A rising crest factor is an early warning.

Thermal. Temperature is a lagging but reliable indicator. A joint bearing running hotter than it did, or hotter than its symmetric neighbor, means friction, and friction means wear or lubrication failure. A drive or motor thermal trend catches cooling problems (clogged filters, failing fans, dried-out capacitors) before the thermal fault trips. Tools range from the controller's built-in motor/drive temperature telemetry (free, use it first) to a periodic thermal-camera sweep of the cell (catches hot cables, connectors, contactors, and bearings in one pass) to fixed thermistors/RTDs on critical points for continuous logging. Thermal management context is in thermal management & cooling.

Rule of thumb: temperature confirms, vibration and current predict. By the time a bearing is measurably hot it is well into failure; the vibration and current signatures moved weeks earlier. Use thermal as the cheap continuous backstop and vibration/current as the early-warning channels on your critical axes.

Grease and oil analysis. For the gearboxes, the lubricant itself is a diagnostic. Metallic particle count and composition (ferrous wear vs bronze from a cage), viscosity, and contamination tell you what is wearing inside a sealed reducer you cannot open. A periodic grease sample from harmonic and RV drives on high-value robots is a mature predictive technique; a magnetic plug that catches ferrous debris is the poor-man's version.

Condition monitoring and the move to predictive

Putting the pieces together into a program, and being honest about the cost.

A condition-monitoring program has four layers, and you should climb them only as far as the economics justify:

1. Controller telemetry (free). Trend following error, torque at reference poses, temperatures, fault-code distributions, and operating hours from data you already have. Every robot fleet should do this. It costs software and discipline, not hardware.
2. Periodic manual checks (cheap). A route: backlash test each axis quarterly, thermal-camera sweep monthly, listen/feel at temperature, grease sample on the reducers annually, cable flex inspection. Structured, logged, compared to baseline.
3. Added sensors on critical axes (moderate). Accelerometers and current loggers on the axes whose failure hurts most, streaming to a historian. Justified when an axis failure means a long, expensive outage.
4. Continuous predictive with analytics (expensive). Real-time streaming, automated feature extraction (RMS, crest factor, spectral peaks, current trends), thresholds and models estimating remaining useful life, dashboards and alerts. This is where the vendor platforms live (ABB Ability, FANUC ZDT / Zero Down Time, KUKA's connectivity tooling, and third-party platforms) and where the ROI question is sharpest.

FANUC ZDT is the useful reference point for what layer 4 buys: it monitors thousands of robots, and its headline result is catching things like a failing reducer or a low encoder battery before they cause an unplanned stop. That works at fleet scale, where the fixed cost of the platform is amortized over hundreds of machines and any single prevented outage on a critical line pays for a lot of monitoring. On a single non-critical robot, layer 1 plus layer 2 captures most of the value at a fraction of the cost.

The move to predictive fails most often for a boring reason: nobody looks at the data, or there is no baseline to compare against, or the alerts are so noisy they get ignored. Predictive maintenance is a data-discipline problem more than a sensor problem. Before spending on layer 3 or 4, prove you are actually acting on layer 1.

Rule of thumb: instrument the axis, not the fleet, first. Find the one or two axes (usually the base axes carrying the most load, or the wrist on a heavy-payload arm) whose failure causes the longest outages, and monitor those hard. Uniform light monitoring of every axis is usually worse than heavy monitoring of the few that matter.

The safety dimension matters here too. Condition monitoring that touches safety-rated functions (a brake, a safety-rated encoder, a force-limiting cobot) is constrained by functional-safety requirements; you cannot bolt a monitoring hack onto a safety channel. See robot safety & functional safety for what you can and cannot instrument on a safety-rated path.

A troubleshooting methodology

When a robot is down and you do not know why, a method beats intuition, especially under production pressure when the temptation is to start swapping parts.

Step 0: make it safe. Before anything, follow lockout/tagout and the cell's safe-state procedure. A stored-energy axis (gravity-loaded, spring, pneumatic, or a charged DC bus) can move when you least expect it. This is non-negotiable and it is where the robot safety guide starts.

Step 1: capture the state before you clear it. Read and record the exact fault code, the axis, the program line, the timestamp, and the machine state. Resist the reflex to hit reset. Photograph the teach-pendant screen, export the log. Half of intermittent faults are lost forever the moment someone clears the alarm and restarts "to see if it happens again."

Step 2: characterize the failure. The most important question: is it repeatable or intermittent? A repeatable fault (happens every cycle, or every time the arm reaches a pose) is tractable, you can bisect it. An intermittent one (random, or tied to temperature, humidity, a specific SKU, or time since power-on) is where discipline pays, because you cannot brute-force it. Ask: what changed? New program, new part, new operator, recent maintenance, a collision, a power event, seasonal temperature. The most common root cause of a "sudden" failure is a recent change.

Step 3: form a hypothesis from the fault class, then isolate. The fault code names a subsystem; use the symptom table to list candidate causes; then divide and conquer. The discipline is to isolate which layer is at fault before replacing anything:

• Is it the robot or the process? Run the robot's built-in test/jog motion away from the cell. If it faults on its own diagnostic move, it is the robot. If it only faults running the application, suspect the program, the payload config, the peripherals, or the environment.
• Is it mechanical or electrical? With power safely off and brakes released per procedure, back-drive the axis by hand. Roughness, notchiness, excess play, or a hard spot is mechanical (bearing, gear, bind). Smooth motion with an electrical fault points at drive, encoder, cable, or config.
• Is it the component or its wiring? The classic wiggle test: reproduce the fault, then flex the cable at each flex point and at each connector while watching the error counter or signal. Swap a suspect cable/connector before condemning the expensive box it connects to.

Step 4: change one thing at a time. The cardinal rule. Swap one component or change one parameter, then test. Changing three things and having it work tells you nothing about which one mattered, and you will chase the same ghost next month.

Step 5: confirm the fix and find the root cause. A robot that runs again is only half the job. Ask why the part failed. A bearing that failed at 4,000 hours when it should last 30,000 has a root cause (contamination, overload, misalignment, lost lubrication) that will kill the replacement too. The 5-whys / root-cause discipline separates "restored production" from "fixed the problem."

Step 6: log it. Fault, diagnosis, action, root cause, parts used, downtime. This log is what turns your fleet's history into the baseline that makes the next diagnosis fast and feeds the MTBF numbers below.

Spare parts, MTBF and MTTR

Maintenance strategy is ultimately an inventory and availability problem, and two numbers frame it.

MTBF (mean time between failures) measures reliability: on average, how long the machine runs between failures. MTTR (mean time to repair/recovery) measures maintainability: how long each stop lasts, from the moment it fails to the moment it is producing again (which includes detection, diagnosis, getting the part, the actual repair, and re-verification). Availability, the number the plant actually cares about, is:

Availability = MTBF / (MTBF + MTTR)

The lever this exposes: you can raise availability by increasing MTBF (fewer failures) or by decreasing MTTR (faster recovery), and MTTR is frequently the cheaper lever. A robot with a 20,000-hour MTBF and an 8-hour MTTR (because the spare gearbox is three days out and nobody on shift can swap it) has worse availability than one with a 10,000-hour MTBF and a 1-hour MTTR. Spares on the shelf, trained techs, good mechanical access, and documented procedures attack MTTR directly and often cost less than chasing marginal reliability.

Worked availability example. Take MTBF = 4,000 h and MTTR = 6 h: availability = 4000 / 4006 ≈ 99.85%, about 13 hours of downtime per 8,760-hour year. Cut MTTR to 1.5 h (spare on the shelf, trained tech): availability = 4000 / 4001.5 ≈ 99.96%, roughly 3.3 hours per year. A 4x reduction in downtime hours from attacking MTTR alone, with no reliability improvement.

Spare-parts strategy follows from criticality and lead time. Stock a part when the cost of holding it is less than the expected cost of not having it when you need it. That expected cost is probability of needing it in the lead-time window × downtime cost during the wait. Practically:

Part class	Example	Stocking logic
Critical + long lead + hard to predict	Servo motor, drive, reducer for a single-point-of-failure cell	Hold a spare on site; the downtime cost during a multi-week lead time dwarfs the carrying cost
Wear items, predictable	Encoder batteries, grease, suction cups, belts, filters, fans	Stock to the preventive schedule plus a buffer; consumed on a known cadence
Common, short lead, cheap	Standard connectors, sensors, pneumatic fittings	Small shelf stock; reorder normally
Expensive, redundant, long life	Full controller	Often shared across a fleet or a vendor service contract rather than one-per-robot

Two structural moves reduce spares cost: standardize the fleet (same robot model and payload class across a plant means one set of spares covers many machines, and the pooled probability of needing a spare rises so a shared spare is well-utilized), and negotiate service/response contracts for the expensive low-probability items where holding your own spare is uneconomic but a multi-week wait is unacceptable.

A caution on MTBF numbers: OEM MTBF figures are often derived under favorable conditions and dominated by the core mechanics, which (as the failure-mode section showed) are not what actually stops your robot. Your own logged failure history, including the cables and grippers the OEM number ignores, is the MTBF that matters for planning.

Calibration drift

A robot can be mechanically healthy, throw no faults, pass every self-test, and still be wrong. Accuracy degrades silently, and it is a maintenance item that pure fault-monitoring misses entirely.

Mastering / homing drift. Every arm has a mastering (zeroing) reference that ties the encoder counts to the known kinematic zero. That reference can shift: after a collision that slips a coupling, after an encoder-battery replacement or a lost-position event that forces a re-master, or from long-term mechanical settling. A robot mastered slightly off is repeatable (it returns to the same wrong place every time) but inaccurate (that place is not where the program says). Because repeatability is unaffected, quality can drift for a long time before anyone connects it to the robot.

TCP (tool center point) drift. The tool frame is defined relative to the flange. A gripper that gets crashed, a welding torch that bends, a tool that is remounted slightly differently, and the TCP the program assumes no longer matches the physical tool. The robot moves the flange perfectly and the tool tip lands off-target.

Wear-driven drift. As gearbox backlash grows and belts stretch, the mapping between commanded and actual position degrades, particularly under load reversal. This is slow and cumulative.

Thermal drift. Distinct from wear: a robot expands as it warms from cold-start to running temperature, and its accuracy at hour zero differs from hour two. It is ordinary thermal physics. The fix is a warm-up routine before precision work and, on capable controllers, thermal compensation. Confusing thermal drift for a fault sends people chasing problems that a 15-minute warm-up would erase.

The maintenance response:

• Track accuracy as a scheduled check that recurs, rather than a one-time commissioning step. A simple fixture or a reference part measured periodically catches drift before it makes scrap. On high-precision cells, periodic re-calibration against an external measurement system (laser tracker, or a fixed metrology artifact) restores accuracy.
• Re-master after any event that could shift the reference: collision, encoder-battery change, mechanical work on an axis.
• Re-teach or re-verify the TCP whenever the tool is changed, crashed, or remounted.

The full treatment of methods, artifacts, and kinematic-model calibration is in robot calibration. The maintenance point is narrower: accuracy is a consumable that degrades, and if you only monitor for faults you will ship out-of-tolerance parts from a robot that reports itself perfectly healthy.

The economics of downtime

Every maintenance decision reduces to one comparison: the cost of the maintenance versus the cost of the failure it prevents. Get the downtime number right and the rest follows.

The true cost of a stop is more than the repair. It is the lost production during the outage (throughput × margin × downtime hours), plus scrap and rework from the failure and the restart, plus any downstream effects (a starved line, a missed shipment, a penalty clause), plus the labor. For a bottleneck cell running a high-margin product, the lost-production term dominates everything else by an order of magnitude, which is exactly why an automotive body shop treats a robot stop as an emergency and a low-volume job shop shrugs at the same stop. The same failure has wildly different economic weight depending on where the robot sits in the value stream.

This is the whole justification for tiering your strategy. Rank your robots by downtime cost per hour, and spend maintenance effort in proportion:

Robot's role	Downtime cost/hour	Rational strategy
Bottleneck on a high-margin line, no redundancy	Very high (thousands+)	Full predictive + on-site critical spares + service contract; pay for the last 9 of availability
Standard production cell, some slack or buffer	Moderate	Solid preventive schedule + controller-telemetry trending + stocked wear parts
Redundant or non-bottleneck, work can be rerouted	Low	Preventive basics + reactive on cheap parts; predictive rarely pays
Non-critical / occasional-use	Very low	Run-to-failure on benign parts, minimal preventive

Where predictive pays. The break-even is roughly: predictive maintenance is worth it when (unplanned-failure rate × downtime cost per unplanned event) − (planned-intervention cost with predictive) > cost of the monitoring program. Rearranged, high downtime cost and a failure mode with a usefully long P-F interval (so the warning is actionable) both push toward predictive. Low downtime cost, or a failure mode that gives no warning, pushes toward preventive or reactive. Do this arithmetic per robot; a plant with 40 robots will land different robots in different tiers, and uniform "predictive everywhere" is usually overspend.

Rule of thumb: the cheapest maintenance dollar is almost always spent on the peripherals. Because cables, connectors, grippers, and consumables cause a disproportionate share of downtime and cost little to inspect and replace, a disciplined preventive routine on those items buys more availability per dollar than any amount of exotic monitoring on the core mechanics that were going to last 30,000 hours anyway. Fix the boring things first.

The last point is organizational. Maintenance quality is dominated by whether the program is actually followed: whether the log is kept, the baseline exists, the spares are on the shelf, the schedule is honored, and the tech is trained. The most sophisticated predictive platform loses to a plant that simply does its preventive maintenance on time and reads its own fault logs. Reliability is a discipline before it is a technology.

Frequently asked questions

What fails first on an industrial robot? Almost always the peripherals, not the core robot. Cables and connectors in the dress pack (flexing millions of cycles), grippers and end-of-arm tooling (worn cups, seals, fingers), and consumables lead the downtime charts. The precision components (harmonic/RV gearboxes, servo motors) are engineered for tens of thousands of hours and rarely fail first. If you are budgeting maintenance attention, weight it toward the things that flex, mate, and contact the product.

How often should I service an industrial robot? Follow the OEM schedule, which is keyed to operating hours or cycles rather than calendar time. Large arms typically have tiered intervals (grease and inspection at points like ~3,840 / 7,680 / 11,520 hours on FANUC's schedule, varying by vendor and model), lighter arms and cobots often on an annual or biennial cadence. Encoder backup batteries, cable inspection, and backlash checks are the recurring items. Adjust the interval to your actual duty cycle and environment; a foundry robot needs it more often than a clean-room one.

Is predictive maintenance worth it for robots? It depends entirely on downtime cost. For a bottleneck robot on a high-margin line where an unplanned stop costs thousands per hour, predictive monitoring (vibration, current, thermal, plus analytics or a platform like FANUC ZDT) pays for itself by converting surprise outages into planned interventions. For a non-critical or redundant robot where a spare and a 20-minute swap fixes the problem, the sensors and analytics cost more than they save. Do the break-even per robot rather than adopting predictive everywhere.

Why does my robot keep throwing intermittent communication faults? Overwhelmingly the cause is a cable or connector, especially one in the dress pack that flexes with the arm. Internal conductors work-harden and crack, and connector pins fret and oxidize, producing a fault that appears only at a specific pose or motion and clears on restart. Reproduce the fault, then flex the harness at each flex point and connector while watching the error counter. Suspect the cable long before you condemn the drive or encoder it connects to.

How do I tell if a robot bearing is going bad? Watch three signals against a baseline: rising motor current/torque at constant load (increasing friction), new vibration (a spectral peak at the bearing's characteristic defect frequency, best caught with envelope analysis), and elevated temperature at that joint. Audible noise and a rough feel when back-driving by hand confirm it. Temperature is the last to move, so if the bearing is measurably hot it is well into failure; the current and vibration signatures shift weeks earlier.

What is the difference between MTBF and MTTR, and which matters more? MTBF (mean time between failures) measures reliability, how often the robot stops. MTTR (mean time to repair) measures maintainability, how long each stop lasts. Availability = MTBF / (MTBF + MTTR). Neither is universally more important, but MTTR is frequently the cheaper lever: stocking the critical spare, training the tech, and ensuring good access can cut hours off every repair for far less than it costs to marginally improve reliability.

Can a robot be broken but show no fault code? Yes, and calibration drift is the classic case. A robot can be mechanically sound, throw zero faults, pass its self-tests, and still place parts out of tolerance because its mastering reference shifted or its TCP no longer matches the physical tool. Because the motion is still repeatable (it goes to the same wrong place every time), the problem shows up as slowly rising scrap rather than an alarm. Track accuracy as a scheduled maintenance check that recurs, rather than a single commissioning measurement.

Should I clear a fault and restart, or investigate first? Investigate first, at least enough to capture the state. Record the exact fault code, axis, program line, timestamp, and machine state (photograph the pendant, export the log) before you reset. Intermittent faults are frequently lost the moment someone clears the alarm and restarts, and that lost information is what would have located the root cause. Restart to resume production only after you have captured what you need to diagnose it.

How do I set up condition monitoring without buying expensive sensors? Start with the controller telemetry you already own: trend the per-axis following error, torque at fixed reference poses, motor and drive temperatures, and the distribution of fault codes over time. Add a standardized diagnostic move (a slow, constant-velocity, unloaded sweep of each axis run identically every service) so the readings are comparable. Layer in periodic manual checks (thermal-camera sweep, backlash test, grease sampling, cable inspection). Only add dedicated accelerometers and current loggers on the specific axes whose failure hurts most.

Why is my robot less accurate first thing in the morning? Thermal drift, which is ordinary physics. A robot expands as it warms from cold-start to running temperature, so its accuracy at hour zero differs from hour two. The fix is a warm-up routine before precision work, and on capable controllers, thermal compensation. Do not chase this as a defect; a short warm-up cycle erases it.