Reading the Robot Teach Pendant: What It Tells You About Safety, Servo Drives, and Mechanical Wear
A field guide for developers and automation engineers who need to treat the teach pendant as a diagnostic instrument, not just a programming tool.
This article was written with the assistance of an AI writing tool and reviewed by the author.
The Problem
When you integrate a used or legacy industrial robot into a new production line, the teach pendant is the first device you power on. It is also the device most often misunderstood. Developers and younger automation engineers tend to treat the pendant as a simple "remote control for the arm." In practice, the teach pendant is the primary window into three tightly coupled subsystems: the safety circuit, the servo drive chain, and the mechanical transmission (including the reduction gearbox).
A common scenario: a system integrator buys a pre-owned six-axis arm, connects it to a controller, and sees an alarm on the pendant. The alarm text is cryptic. The integrator has no idea whether the problem is in the safety relay, the servo amplifier, the encoder battery, or the gearbox itself. The result is downtime, wrong part replacement, and costly trial-and-error.
This article gives you a practical framework for interpreting what the teach pendant actually tells you—and how to use that information to isolate faults across the electrical and mechanical boundary of the robot.
Why It Matters
Robots are not like PLCs. A PLC has clearly separated I/O modules, and its diagnostic messages generally point you to a specific input or output. An industrial robot is a mechatronic system where electrical, electronic, and mechanical components share the same fault codes.
Consider the role of the reduction gearbox. On many six-axis robots, especially larger units such as ABB's IRB 4400 or IRB 6400, the servo motor spins at high speed and low torque; the gearbox converts that into high torque at the joint. If the gearbox develops backlash, excessive friction, or lubrication failure, the servo drive must compensate with higher current. That higher current eventually triggers an overcurrent alarm on the pendant. If you read that alarm as a purely electrical fault and replace the servo motor, you still have a failing mechanical part, and the new motor may also draw excessive current. Knowing how to read the pendant's diagnostics correctly lets you ask the right question: is this a motor problem, a drive problem, or a mechanical problem on the output side of the gearbox?
For developers, understanding this chain matters because modern robotic cells expose status through OPC UA, MQTT, or vendor-specific APIs. But every one of those status values originates in the same controller data that the pendant displays. If you do not understand what the pendant data means, you cannot reliably build a predictive maintenance dashboard.
A Practical Approach
Use this three-layer diagnostic workflow when an alarm appears on a teach pendant.
Layer 1 — The Safety Domain
Safety-related alarms are the most overlooked because they seem trivial. A classic example is an emergency stop status: the pendant reports that the emergency stop circuit is open, which disconnects the motor enable (ON) circuit. The mechanical brakes engage, and all program execution halts immediately. This is not a mechanical fault, and it is not a servo fault. It is a circuit state.
Check, in this order:
- The physical emergency stop button on the pendant itself.
- External emergency stop buttons wired into the safety chain.
- Safety relay or safety PLC status.
- Door interlock switches and light curtains.
If the safety chain is complete and the alarm persists, then investigate the controller's safety I/O board. For older ABB systems, a board like the DSQC 611 power distribution board plays a role in routing power and safety signals. A faulty safety board can produce an emergency stop alarm even when all physical buttons are released.
Layer 2 — The Servo Drive Domain
The pendant reports motion-related alarms such as overcurrent, overvoltage, or encoder communication errors. Before touching the motor or gearbox, isolate the axis.
- Move the robot manually at low speed using the pendant's joystick, one axis at a time.
- If the fault follows a specific axis, find the motor connector for that axis at the controller.
- Swap the motor cable with another axis (if the arm is small enough to allow this safely) and repeat the motion test. If the fault moves with the cable, the cable is the problem. If the fault stays on the same axis, it is likely in the drive module or the motor.
Layer 3 — The Mechanical Domain
If the electrical components check out, redirect your attention to the transmission. A robot axis is a spatial mechanism: typically six rotary joints forming an open kinematic chain. Each joint has a servo motor, an encoder, and a reduction gearbox. If you can rotate the joint manually (with the robot powered off and brakes manually released by a qualified technician), feel for roughness, catching, or free play. These are gearbox symptoms.
The teach pendant can help here too. The arm may move but with a noticeable vibration or audible noise. The controller may report a "following error" because the actual position lags the commanded position. That lag is often a gearbox wear issue: the gear teeth have backlash, or the internal bearings are failing.
Implementation Details
Let us translate this into a concrete workflow, including code, for a robotics engineer building an API-based monitoring layer.
1. Read the alarm list from the controller
Every vendor controller exposes a list of active alarms. The pendant interface presents this data; behind the scenes, it is available via the controller's API. In a hypothetical monitoring service (your real endpoint may differ), you might query it like this:
import requests
BASE_URL = "http://your-robot-controller.local"
HEADERS = {"Authorization": "Bearer YOUR_API_TOKEN"}
def get_active_alarms():
response = requests.get(f"{BASE_URL}/api/v1/alarms/active", headers=HEADERS)
response.raise_for_status()
return response.json()
alarms = get_active_alarms()
for alarm in alarms:
print(alarm["code"], alarm["description"], alarm.get("axis", "global"))
Label the placeholders: your-robot-controller.local should be replaced by the controller's actual hostname or IP address, and YOUR_API_TOKEN by the token issued by the robot's API service. The endpoint in this example is illustrative, not a vendor specification; confirm the actual path for your controller model.
2. Store alarm history for trend analysis
A single alarm is a snapshot. A trend is a diagnosis. Store each alarm event with a timestamp, then analyze whether a given axis produces recurring overcurrent alarms. Recurring overcurrent on the same axis, at the same robot posture, strongly suggests increasing friction in the gearbox, not a random electrical failure.
3. Correlate alarms with axis load
If your robot has a current feedback register, read the RMS current per axis during a standard cycle. Compare the value at commissioning with the value after six months of operation. An increasing baseline current, even without alarms, is an early mechanical wear indicator.
4. Calibration as a maintenance trigger
If you have replaced a motor or gearbox, a calibration event is required. One practical method is aligning the mechanical zero marks on the robot axes manually, then updating the revolution counter data on the pendant. On many ABB models (such as the IRB 120 and similar arms), each axis has a zero mark; aligning these marks under power-off conditions and then updating the controller under power-on conditions is the standard manual calibration workflow. Skipping the revolution-counter update after a gearbox replacement will cause position drift and unpredictable motion behavior.
Common Failure Modes
Below is a list of realistic problems you will encounter, with how to read them correctly.
1. Emergency stop alarm that will not clear after all buttons are released
Failure cause: faulty safety board (e.g., internal relay welding or broken input) rather than a physical button stuck down.
Diagnosis: measure continuity across the safety chain input terminals at the controller. If voltage is present at the terminal but the pendant still reports emergency stop, the safety board or its firmware is suspect.
2. Overcurrent alarm on axis 3, but only when the arm is at full extension
Failure cause: gearbox wear in the vertical axis. At full extension, the gravity torque is highest, and the drive must supply more current through the motor.
Diagnosis: compare the current draw to historical data. If the current spikes proportionally with the arm's extension and grows worse over weeks, stop replacing drives and inspect the gearbox.
3. SMB memory mismatch alarms
On newer ABB controllers, the SMB measurement circuit board stores serial number data and motor revolution counters. If you replace the SMB board, or restore the controller system, the data on the SMB may not match the controller. The pendant shows serial-number or memory-difference alarms.
Fix: clear the controller and SMB memory via the pendant menu path (typically Main Menu → Calibration → select the robot → Mechanical Unit Memory → Advanced). Then re-enter the robot's serial number or perform calibration.
4. Axis drifts after a gearbox replacement
Cause: you replaced the mechanical unit but did not update the revolution counter or perform a full calibration.
Fix: run the full calibration procedure as defined by your robot vendor. For robots with zero marks, align the marks manually, then set the revolution counter data on the pendant.
Verification Checklist
Use this checklist before declaring the robot ready for production.
- [ ] Emergency stop circuits are tested on the pendant and on external hardware buttons. The alarm clears immediately on reset.
- [ ] Safety relay or safety board signals are verified with a multimeter at each channel.
- [ ] All axis motors run at low speed via the pendant without abnormal vibration or noise.
- [ ] Axis current values per joint are recorded and stored. Baseline exists for future comparison.
- [ ] No SMB memory or serial number mismatch alarms remain after replacement work.
- [ ] Manual calibration was performed after any motor, encoder, gearbox, or SMB board replacement, with the revolution counter data confirmed.
- [ ] The arm holds position under gravity with the brakes on. There is no visible joint droop.
- [ ] Full program cycle test completes without following-error alarms.
- [ ] Historical alarm log is actively recording and available via the controller API or export function.
Conclusion
The teach pendant is much more than a user interface for jogging the arm. It is a diagnostic front end for the entire mechatronic system, including the safety circuit, the servo amplifier, and the mechanical transmission on the output side of the motor where the reduction gearbox lives.
The transferable lesson for software engineers and automation professionals is simple: never classify a fault as purely electrical or purely mechanical based only on the alarm code. Work through the three domains in order (safety → drive → mechanics), use positional and current trend data to confirm the diagnosis, and allow no component to be replaced without also verifying the calibration state of the machine.
If you are sourcing replacement components for robot maintenance, keep in mind that suppliers of industrial automation parts and robot components can offer useful guidance if you already know what to ask for. You can explore available robot components at Zhonghengbiao's product catalog, but the diagnostic framework above will serve you regardless of where you buy your parts.
Sources
- Zhonghengbiao structured technical knowledge base (ABB robot systems, S4C and IRC5 controller families, teach pendant descriptions, and DSQC board references)
Tags: robotics, automation, engineering, hardware
Top comments (0)