Robot arm faulting, unknown cause

Robots
1

I was helping some students use the robot arm and attach a claw-shaped gripper they had designed, and the robot started having issues. It started faulting even when the light curtains were not being triggered. We were just trying to jog the joints, mainly joints 1, 2, and 3. I looked at the debug log to see if I could figure out what was triggering the fault and got these errors. If anyone knows what this error is or how to prevent it, please let me know!

20260415_163204
20260415_1632041920×1440 698 KB

2

This was the quick response from Claude.
Short answer: the drives didn’t fail. Something commanded the whole arm into a fault state, and the drives were shut down in response.

What the log shows (bottom to top):

  1. A move was aborted and its execution was preempted, so something cancelled the motion.
  2. About 0.2 s later, /hal_io shows state_cmd change from 2 to 4, and hal_402_mgr logs “Received fault command: state-cmd pin changed”. This is the trigger.
  3. hal_402_mgr then logs “Entering fault state”, the only Error line.
  4. All six drives go from operation enabled to quick stop active and then to switch on disabled. That is the normal shutdown sequence, not a drive fault. The status words (0x1637) have no fault bit set.
  5. The HUB warning at the top is just a failed cloud log upload. It’s unrelated.

Likely causes, since the fault was commanded rather than drive-originated:

  • E-stop or safety chain: the e-stop was pressed, a safety circuit opened, or an enable/deadman input dropped. This is the most common cause.
  • Software-initiated stop: the UI or a node (e.g. a limit, collision, or following-error check) requested a fault.
  • Intermittent wiring or input: a loose e-stop or enable connection can trip it briefly.

The abort came slightly before the state_cmd change. That could mean someone or something cancelled the move first (e.g. the stop button), or that the stop request was already in progress and the log order is just slightly offset.

What to check:

  • Whether anyone hit the e-stop, or whether it happens on its own.
  • The e-stop and enable wiring and connectors for loose contacts.
  • Whether the same state change appears at the same point in every fault, such as during a particular jog or move.