UR5 safety C200A24 error from a wrist camera power draw

Every restart ends the same way: with the wrist camera connected, the UR5 drops into a safety fault before it finishes booting, and with the camera unplugged it starts clean every time. The code on the teach pendant is C200A24, a safety control board hardware error that reports the 24 V I/O supply took too long to stabilize. That combination points at the camera's power path far more often than at the robot. This guide decodes what the safety board is actually timing, ranks the likely causes from a failing camera board down to a tired USB cable, walks through three tests that isolate them in under an hour, and gives the fix that matches each result: a powered hub, a drag-chain cable, a separate host, or a service call.

What C200A24 actually says

On a CB3 control box the fault appears as a safety-class alarm on the pendant: SafetyA: C200A24, with the text "it took too long to stabilize 24V IO". At power-up, the safety control board runs a start-up self-test, and one item on that list is the I/O rail — the supply that feeds the controller's digital and safety I/O terminals. The board gives that rail a fixed window to settle within tolerance. If it is still moving, sagging or noisy when the window closes, the boot aborts with C200A24.

Two things follow. First, the code is a timing self-test, not a corrupted safety configuration: your safety planes, limits and tool settings are untouched, and a boot that passes with the camera removed proves the safety system itself is healthy. Second, anything that loads or disturbs the controller's supplies during those seconds is a suspect — which is exactly what a camera that is present only at boot can be. The UR5 service manual's remedy for this code is short: run a complete rebooting sequence first, then check the supply and the control board.

Keep this separate from a mid-shift failure. If the camera boots fine and the vision system drops out hours later, that is a different fault with its own fix, covered in Vision system down error on a robot controller: fix the USB layout.

Why a wrist camera trips it at boot

The same camera that runs all day without a complaint does its heaviest electrical work at power-up. Bulk capacitors charge, the illumination strikes at full current, and the port enumerates the device. A healthy camera settles inside the port's budget within moments. A failing camera board draws abnormal current or cycles its own connection, and a marginal cable makes the port see the camera drop and re-enumerate — stacking transients on top of transients.

All of that lands during the same seconds in which the safety board is timing its I/O rail. Enough load or enough repetition inside that window, and the stabilization check runs out of time: C200A24, every restart, only while the camera is connected.

Support channels that handle this exact pattern report the camera's circuit board as the usual culprit, with a faulty cable responsible in a minority of cases. That ranking is where the tests below start. For power faults that show up as LED states on the wrist instead of boot errors, see Wrist camera and gripper wiring: fix red LED power faults.

Likely causes, ranked

1. Camera electronics drawing abnormal start-up current. The most common cause behind this pattern. Test 1 narrows it, and Test 3 confirms it.
2. A fatigued or damaged USB cable. Less common, but a documented cause of the same signature. Any cable that has lived on a rotating wrist is a suspect; Test 2 clears it.
3. Stacked load on a shared port. A camera behind an unpowered hub next to other devices can exceed what the port sequences cleanly at boot. The same budget arithmetic that decides how many USB cameras one controller can feed applies here.
4. The control board's own supply stage. Least likely while the fault is camera-dependent, and first suspect once the fault appears with nothing connected — the bare-boot case at the end.

Test 1: three boots with the camera, three without

1. Power the control box down at its main switch — not a soft restart — wait 10 seconds, and power up. Record the result. Run three full cycles with the camera connected.
2. Disconnect the camera at the control box port and run three more full cycles.
3. If the fault follows the camera, connect it once, 30 to 60 seconds after the robot reports ready, and run the rest of the shift that way.

Read the results one line at a time. Fault with the camera at boot and clean boots without it: the power path is confirmed as the trigger. Clean for the whole shift after the late connection: the camera's steady draw is fine and only the boot window is the problem, so the hub fix below is the cure rather than a new camera. A fault even after a late connection, or a port that drops the camera mid-shift: the camera board itself is failing, and the camera goes back through the vendor's support channel.

Test 2: swap the cable before you blame the camera

A cable on a rotating wrist flexes through thousands of cycles a day. Office-grade patch cable fails exactly there: conductors crack at the strain relief, shields open up, and the port starts seeing connection transients at every power cycle. Before sending a camera in for repair, inspect the run — connector locks seated, no kinks at the wrist — then swap in a known-good, drag-chain-rated cable and repeat Test 1.

For a wrist mount, the data cable needs high-flex, drag-chain construction built for continuous motion:

The LS-CBL-0219 is a 3 m USB 3.0 camera cable in exactly that construction. Three meters covers a wrist run with slack for the dress pack, and a cable that has already spent a year on the joint is due for replacement even if it passes today. The swap itself — same fault, different cable — is the same isolation method used when a camera has power but is not detected; that guide adds the full set of post-swap link checks. The camera data cables page and the accessories finder filter cables by type and length.

Test 3: move the camera to a powered hub

A powered hub sources the 5 V for its downstream ports from its own wall adapter. The robot's port then carries signaling with almost no power load, and the camera's entire start-up draw lands on the hub supply — outside the controller's budget and outside the timing window the safety board watches. Plug the hub directly into the control box port, the camera into the hub, and repeat Test 1's three boots.

Three rules keep this a permanent fix rather than a masked one:

• Use a hub with its own adapter. A bus-powered hub pulls its power back through the robot port you are trying to unload and changes nothing.
• One hub, plugged in directly. Chaining a second hub in front of the camera multiplies the very transients you are removing.
• Size the adapter before you buy; the worked example below gives the number.

If three boots pass with the hub in place, keep it installed — this is a legitimate permanent arrangement, not a workaround. If C200A24 returns with the camera on a correctly sized hub, the camera board is generating transients on its own uplink, and the camera goes back through support. The hub must also carry the camera's bandwidth; budgeting that side is covered in USB hub drops camera frame rate: budget the bandwidth first.

Worked example: hub supply for one USB 3.0 wrist camera

The inputs, and where each comes from:

• Unit load: the USB 3.0 specification budgets 900 mA at 5 V per SuperSpeed port — 4.5 W. A camera that enumerates at USB 2.0 instead has a 500 mA (2.5 W) budget, so sizing for the USB 3.0 number covers both cases. The case here is a single camera; read the port class off the camera's own data sheet for a specific model.
• Headroom: 20% over the unit load — a rule of thumb covering converter efficiency and the current surge while the camera's light strikes at boot.
• Second device: none in this case; a dedicated hub for the camera. A scanner or sensor sharing the hub counts as a second full unit load.

The rule in words: the hub's wall adapter must source, at 5 V, every downstream unit load plus headroom. The arithmetic:

• Per camera: 5 V × 0.9 A = 4.5 W
• With headroom: 4.5 W × 1.2 = 5.4 W minimum adapter output
• Practical single-camera adapter: 5 V × 2 A = 10 W, a margin of 10 W ÷ 4.5 W ≈ 2.2 times the load
• Camera plus one more full-load device: (4.5 W + 4.5 W) × 1.2 = 10.8 W, so 5 V × 2.5 A = 12.5 W or larger

The decision: one wrist camera on its own powered hub needs a 5 V, 2 A (10 W) adapter or larger. Add any second full-load device and the threshold moves to 5 V, 2.5 A (12.5 W) or larger. A hub rated below 10 W for a camera-only load fails the margin, and a bus-powered hub fails both cases by definition — its entire 4.5 W comes back through the robot port.

The fix for each test result

When it is not the camera

A C200A24 that survives a bare boot — no camera, no hub, nothing on the USB ports — moves the fault to the manual's second line: check the I/O supply and the control board. One more suspect shares that rail by name: anything wired to the controller's I/O terminals. A shorted sensor line or an overloaded output loads the very supply the board is timing, so disconnect the user I/O block for one boot before condemning the board. If the fault persists with a bare controller and empty I/O terminals, book the control board for service and stop power-cycling past it; each failed start stresses the supply stage the board has already flagged.

Prevention: keep camera power off the boot path

• Give every camera a powered hub or its own host from commissioning day. The robot's USB ports are for occasional service access, not for carrying a camera's supply through every boot.
• One high-draw device per port. Where a depth camera, a scanner and the wrist camera share one host or hub, run the budget arithmetic from Depth camera timeout with other USB devices: one shared controller and Multiple USB cameras on one host: bandwidth and power budget before anything is plugged in.
• Drag-chain cable on every moving axis, and treat a wrist cable as a consumable with a yearly replacement.
• Sequence the start-up: robot first, camera power second. Once the camera lives on its own host, the boot order in Auto-start your vision system at robot controller boot keeps the two from waking together.
• After any camera, cable or hub change, demand three clean full-power boots before calling the line ready.

The long-term answer for a camera that earns its keep is its own host: the camera draws from the host's supply, and results reach the robot over Ethernet, so the robot's USB ports stay empty at every boot. A vision controller does that in one box:

A host with two USB 3 ports, four built-in light channels and its own storage carries the camera, its light and the inspection stack, and the robot sees only a network connection at boot. Compare the range on the vision controllers category page. If you are speccing a camera's cable and accessories from scratch, the build-a-system configurator starts at the extras step, and more start-up and USB fault patterns sit on the systems topic page.