A Robot Protective Stop: What to Record Before Service

A protective stop is a reason to investigate a robot application, not a reason to keep pressing reset until production resumes. A useful service record captures what the controller displayed, what the cell was doing and what changed before the event. Those observations help trained personnel examine possible causes without assuming that one warning proves a particular component has failed.

Preserve the warning and its context

Record the exact message and code, the time, the robot and controller identifiers, and the active program or job if known. Note the operating mode and the step at which the stop occurred. A photograph of the display and a copy of the relevant log can be useful when collected through the site's approved procedures. Keep the original timestamp and identify any uncertainty about the controller clock.

Universal Robots' protective stop guidance asks trained personnel to investigate warning messages and determine the cause. The guidance lists several possible contributing conditions; it does not mean that every stop has the same cause. Use the manual for the actual model and software version and involve the responsible service provider where needed.

Describe what the application was doing

Capture the workpiece, gripper or tool, fixture and external equipment involved at the time. Was the robot carrying a part, approaching a fixture, or waiting for another machine? Record what the operator observed, such as an unexpected contact, unusual sound or a part positioned differently from normal. Clearly distinguish an observed fact from a suspicion.

If a collision is suspected, do not make the area safe by guessing or by reaching into a hazardous space. Follow the site's established isolation and inspection procedures. Record any visible damage or displacement for qualified personnel. A service report should describe what was inspected and by whom, not assert that the robot is safe merely because the warning can be cleared.

Build a change timeline

Ask what changed since the last known normal run: tooling, part mass, fixtures, mounting, program version, payload settings, cabling or surrounding equipment. A change is a lead for investigation rather than proof of causation. Record the date and source of each observation and preserve the pre-change information where the organization has it.

Pay attention to whether the event occurs at a particular point or under a particular combination of conditions. Compare the actual equipment and program version with the documented setup. A trained technician can then decide which manufacturer guidance and diagnostic procedures apply. The investigation should not rely on an improvised alteration to safety settings.

Do not hide repeated stops

The manufacturer's stop recovery documentation says repeated protective-stop warnings require investigation and that program changes or service may be needed. The separate service guidance warns against automatic acknowledgement and reset as a way to continue operation without addressing the cause. Preserve a record of each occurrence, including any action taken and whether the event recurred.

An operator may feel pressure to restore output quickly, but clearing the message does not demonstrate that the underlying condition is resolved. A service handover should name the person authorized to decide next steps and identify the open questions. If the cause is not known, state that explicitly rather than recording the event as fixed.

Where several shifts operate the same cell, maintain a shared incident record so an event cleared on one shift is visible to the next. Record each shift's observations separately and retain the original wording of the warning. Similar symptoms on different shifts are useful evidence, but they do not establish that the underlying causes are identical. Escalate recurring events through the site's maintenance process.

Give technicians a focused evidence package

Provide the exact warning, a timeline, the program and configuration identifiers, relevant logs, photographs where appropriate, and a description of recent changes. Check that any support files are collected and transferred under the owner's access policy. These files may contain production information and should be shared only with authorized recipients.

It is also useful to note what did not happen: for example, whether the operator observed a collision or whether a downstream machine was waiting. Absence of an observation is not proof that an event did not occur, so label it accurately. If a log covers only part of the incident, indicate its time window and retain the original rather than editing it to fit a diagnosis.

Document the decision before resuming

After investigation, record the identified cause or unresolved uncertainty, corrective action, program or hardware changes, and the checks performed under the site's procedure. The responsible qualified personnel must decide whether the complete cell is ready to return to use. The requirements depend on the application, the manufacturer's instructions and the site's safety arrangements.

For related repair documentation, read our controller backup guide and browse the service archive. A traceable warning record helps the next person understand both the evidence and the limits of the repair decision.