What the C160 alarm means

The robot was powered off last time without a clean stop (e.g. E-stop or power cut), so the measured joint positions may not match the stored ones; the controller refuses to trust the position until verified. This is a high-frequency ticket for our Universal Robots repair team, and on CB3 / e-Series (UR5/UR10/UR16/UR20) systems one inspection usually identifies the fault.

Most common causes

  • Power cut or emergency stop while the robot was moving
  • Encoder count lost during abrupt stop
  • Battery-backed encoder data corrupted
  • Brake released while unpowered and arm moved
Field note: The top-listed cause has the highest hit rate, so checking it first narrows things down fast.

Step-by-step field fix

  1. Verify in the 3D view that the displayed position matches the real robot
  2. Stand clear, then run the first program cycle slowly to observe behavior
  3. If positions clearly disagree, move joints to calibration marks and re-calibrate
  4. Check the encoder battery and connectors
  5. Avoid powering off mid-motion; use proper stop routines
Safety first: For Universal Robots c160, the risk on this family is not injury but data: lose the program, parameters and calibration data and weeks of teaching work start over. What you can check yourself first is Verify in the 3D view that the displayed position matches the real robot; program and calibration data handling is not a DIY job.

How we diagnose system alarms on site

Universal Robots c160 belongs to the system & program family. On Universal Robots c160 the failing stage is PolyScope (UR control box (CB3 / e-Series)) on the UR control box (CB3 / e-Series) - the software layer: corrupted program or parameter files, boot failures, version mismatch, memory and storage media. We start reading Universal Robots c160 at the PolyScope event and alarm pages; codes carry a C prefix (C15x, C5x, C7x).

The chain involved in Universal Robots c160 runs: storage media (CF / flash / disk) -> system software and firmware -> parameters and calibration data -> user programs -> runtime.

Universal Robots c160 is a system-family alarm, and our iron rule is: On system alarms we have an iron rule: however urgent the customer is, we take a complete backup first - programs, parameters, calibration data, tool and work-object frames, all of it. The reason is arithmetic: losing the live state here usually means weeks of teaching done again, which costs far more than a few hours of downtime. Only after the backup do we decide restart, restore or reinstall. If the storage media is already throwing errors we pull the data read-only first.

Field notes on this page cover Universal Robots c160 (Joint Position Disagreement After Power-Off); written by the Henghuan repair team, updated 2026-10-01.

If you can't fix it, reach our engineers directly

Share the alarm code, machine model and the operating condition at the moment of the alarm. Our engineers are highly experienced with Universal Robots c160, and remote diagnosis (phone/video) is completely free.

Get a Free Remote Diagnosis See Repair Services

Hotline: +86-20-39029800 · WhatsApp: +86-188-1886-2860

Related System & Program alarms

C71A1 — Joint Firmware Mismatch (Size 1 Joint)
Same family: this code belongs to the System & program alarms family - the page collects all System & program-family codes we have handled, with the common inspection order and spares.
Other brands: we also keep field-fix libraries for Kawasaki · Staubli · Epson and more — see the complete alarm code hub.

Frequently asked questions

QWhat does the Universal Robots c160 alarm mean?

The robot was powered off last time without a clean stop (e.g. E-stop or power cut), so the measured joint positions may not match the stored ones; the controller refuses to trust the position until verified. This is a high-frequency ticket for our Universal Robots repair team, and on CB3 / e-Series (UR5/UR10/UR16/UR20) systems one inspection usually identifies the fault. Universal Robots c160 sits in the system & program family; on our work orders the highest-frequency trigger for this code is "Power cut or emergency stop while the robot was moving".

QCan I clear a Universal Robots c160 alarm myself?

Whether Universal Robots c160 clears on its own depends on the outcome of "Verify in the 3D view that the displayed position matches the real robot". Finish the flow with "Avoid powering off mid-motion; use proper stop routines" to confirm Universal Robots c160 - do not skip it. If that step is clean, the second most frequent cause on Universal Robots c160 is "Encoder count lost during abrupt stop". Two attempts and still there means stop: Universal Robots c160 involves program and calibration data, and running Universal Robots c160 on can turn a repairable fault into a replacement.

QWhen you handle Universal Robots c160, will my programs and frames get lost?

The commonest causes we see on Universal Robots c160 are "Power cut or emergency stop while the robot was moving, Encoder count lost during abrupt stop, Battery-backed encoder data corrupted", so we stock the van against those. For Universal Robots c160 specifically, we carry recovery media and common storage media, but on this family the backup matters more than the spare. For Universal Robots c160, on system alarms the first move is backup; we can walk the customer through preserving data remotely before anything else. Before we roll, tell us what Universal Robots c160 shows on the PolyScope event and alarm pages; codes carry a C prefix (C15x, C5x, C7x) and what the machine was doing - phone or video triage is free.

The notes on Universal Robots c160 were summarized by the Henghuan Robotics repair team from on-site service. The alarm interpretation is our empirical summary for troubleshooting reference and may vary by controller and software version — please check Universal Robots documentation or contact us with questions. Henghuan is an independent service provider, not affiliated with or endorsed by Universal Robots.