The Robot That Stopped at a Weird Point: Program Logic, Not Hardware
A pick-and-place robot. It picked the part, moved toward the place position, and stopped 200 mm short. No alarm, no error — just stopped. The operator hit cycle start, the robot moved the rest of the way and placed. Then the next cycle: same stop. It wasn’t a fault. It was a program logic issue. Here’s what we found.
The symptom
The robot moved along the path to the place position. At a specific point (200 mm before the target), it stopped. The teach pendant showed “WAIT” — the program was waiting for an input. The input wasn’t coming. The operator pressed cycle start, the input was forced, and the robot continued. But why was it waiting?
The program logic
The program had a “WAIT FOR SIGNAL” command at that point. The signal was supposed to come from the downstream conveyor — “conveyor is ready to receive.” The conveyor’s “ready” sensor was a photoelectric that detected a pallet in the right position. The sensor was blocked (a chip on the lens) and wasn’t sending the signal. The robot waited forever.
The program was designed to wait for the conveyor to be ready before placing the part. That’s correct logic. But the sensor failure meant the wait never ended. The operator had learned to press cycle start to force it through. That bypassed the interlock.
What we changed
Fix the sensor. We cleaned the photoelectric sensor. The lens had a chip on it. The signal came back. The robot didn’t stop.
Add a timeout. The WAIT command should have a timeout. If the signal doesn’t come within 5 seconds, the robot alarms and stops — not waits forever. We added a timer: wait 5 seconds for “conveyor ready,” then alarm. The operator gets a clear message, not a silent stop.
Don’t bypass the interlock. The operator’s habit of pressing cycle start was masking the problem. We re-trained: if the robot stops at a wait point, check the sensor, don’t just force it through. The interlock exists for a reason.
Common “weird stop” causes
| Symptom | Likely cause | Check |
|---|---|---|
| Stops at same point every cycle | WAIT for input that’s not coming | Pendant: which input? |
| Stops randomly | Collision sensor, overload | Fault log |
| Stops after first cycle | Safety circuit opened | E-stop, gate switch |
| Stops in motion, alarms | Path deviation, servo fault | Servo fault code |
| Stops at home position | Zero position lost, encoder error | Re-home the robot |
The pendant diagnostic
When the robot stops unexpectedly, the teach pendant shows the program line it’s on. Read the line. If it’s a WAIT command, check which input it’s waiting for. The pendant shows the input state (ON/OFF). If the input is OFF, trace the sensor that feeds it. Don’t guess — the pendant tells you exactly where it’s stuck.
The program structure that prevents this
Every WAIT should have a timeout. Every sensor input should have a test (the operator can force the input during setup, but not during production). Every stop should have a clear message on the HMI: “Waiting for conveyor ready — check sensor S05.” Not “Robot stopped.” The operator shouldn’t have to guess.
The diagnostic rule: A robot that stops at the same point every cycle isn’t broken — it’s waiting for a signal. Read the program line on the pendant. Find the input. Trace the sensor. Clean or fix the sensor. Add a timeout so it doesn’t wait forever.
