A 6-axis robot arrives on your dock. If the controller is built into the arm, you unbox one unit, run one power cable, and begin programming within an hour. If the controller ships in a separate cabinet, you clear 0.6 square meters of floorspace, pull three-phase power and signal cables through conduit, and spend half a day wiring before you touch the teach pendant. Neither architecture is wrong — but each optimizes for a different set of priorities. This article lays out what changes when the controller moves into the robot, and what you give up in exchange.
Two Architectures, One Goal
Built-in controller architecture integrates the servo drives, main CPU, safety PLC, and I/O into the robot arm's base or forearm casting. Power enters through a single connector. The teach pendant connects directly to the arm. This is the architecture of most collaborative robots and increasingly of small-to-mid 6-axis industrial robots (payloads under 25 kg).
Separate controller architecture houses the drives, CPU, safety logic, and I/O in a floor-standing or wall-mount cabinet. A multi-conductor cable set — typically motor power, encoder feedback, and brake signal — runs from cabinet to arm. This is the architecture of the ABB IRC5 and most industrial robots above 50 kg payload.
Floorspace, Cooling, and the Cabinet You Didn't Plan For
A separate robot controller cabinet occupies 0.4–0.8 m² — roughly the footprint of the robot itself. It needs clearance on all four sides for airflow: 100 mm minimum at the rear, 200 mm at the door swing side. In a cell with four robots, four cabinets consume 2–3 m² of floorspace that produces nothing.
Built-in controllers eliminate the cabinet. The drives are cooled by conduction through the arm casting or by a small integrated fan. The trade-off: maximum continuous power is thermally limited. A separate cabinet can house larger heat sinks and forced-air cooling, supporting higher sustained torque at the robot's sixth axis. If your application runs at 80% of rated payload for hours, the thermal headroom of a separate controller matters.
I/O and Expansion: Where Separate Controllers Pull Ahead
- Built-in controller I/O
- Typically 8–16 digital inputs, 8–16 digital outputs, 2–4 analog channels, 1–2 Ethernet ports. Enough for a gripper, a vision camera, and basic cell safety. Expansion requires external fieldbus modules.
- Separate controller I/O
- A full rack with slots for digital/analog/communication modules. 64–128 digital I/O points, 8–16 analog channels, dedicated encoder inputs for conveyor tracking, multiple fieldbus interfaces. Processes that need force/torque sensing, multiple gripper stations, and auxiliary axis control benefit from the expansion headroom.
Multi-Robot Coordination
When two or three robots share a workpiece — one holding a part while another welds, or two robots loading a press in alternating sequence — a separate controller architecture allows one controller to run multiple arms. The ABB IRC5, for example, supports MultiMove: one control cabinet driving up to four robots with coordinated motion paths in a single kinematic model. Built-in controllers are almost always one-controller-per-arm, coordinating over a real-time Ethernet fieldbus rather than a shared backplane. The fieldbus approach works, but adds 1–2 ms of synchronization latency that matters at high path velocities above 2 m/s.
Deployment Speed and Maintenance
A built-in controller robot goes from pallet to production in under two hours: unbox, bolt down, connect power, configure IP address, teach points. No cabinet to position, no interconnect cables to route, no auxiliary power to pull. For high-mix low-volume shops that reconfigure cells monthly, this speed compounds.
But when a built-in drive fails, the entire arm may need to ship back for service — the drives are not field-replaceable in most designs. A separate cabinet lets maintenance swap a drive module in 20 minutes without disturbing the robot's mechanical zeroing or tool calibration. A modular PLC architecture in the control cabinet follows the same principle: hot-swappable modules reduce mean time to repair.
| Factor | Built-in Controller | Separate Cabinet |
|---|---|---|
| Deployment time | 1–2 hours | 4–8 hours |
| Cell floorspace | Arm footprint only | Arm + 0.4–0.8 m² cabinet |
| Max continuous payload duty | Typically 60–70% rated | 80–100% rated |
| Multi-arm coordination | Via fieldbus (1–2 ms latency) | Shared backplane (<0.5 ms latency) |
| Field repair | Return to manufacturer | Module swap on site |
Can I mix built-in and separate controller robots in the same cell?
Yes — most modern robot brands support a common fieldbus (PROFINET, EtherNet/IP, EtherCAT) across both architectures. The challenge is not communication but programming: the built-in robot's teach pendant environment and the separate controller's environment may differ in look, menu structure, and coordinate frame conventions. If your maintenance team already knows one platform, mixing architectures increases training load. Limit mixed-architecture cells to applications where each robot type serves a distinctly different function (e.g., a built-in cobot for manual load assist alongside a separate-controller welding robot).
Which architecture handles high-vibration environments better?
Separate cabinets win here. You can position the cabinet outside the vibration zone — on an isolated pad or mezzanine — while only the arm endures the shaking. A built-in controller shares every vibration cycle the arm experiences, which accelerates solder joint fatigue and connector fretting on the drive electronics. For foundry robots, forge tending, and heavy press loading, plan on a separate controller with the cabinet located in a conditioned enclosure.
