Robot Communications

Two separate jobs, often confused

Getting a robot talking to the rest of the cell is two distinct pieces of work, and keeping them separate in your head makes both simpler. The first is the data link — the physical and logical connection that carries your handshake signals between the robot controller and the PLC. The second is external automatic operation — configuring the robot so the PLC can start it, select programs, reset it and monitor it without anyone touching the teach pendant.

The signals themselves were already defined in Part 5. Every "robot ready", "start cycle" and "pallet complete" on your I/O schedule now needs a physical route and an address at both ends. That is all this part is: giving the signals you already designed somewhere to live.

Choosing the link: hardwired or fieldbus

For a handful of signals, hardwired I/O between the robot controller and the PLC is completely legitimate. Modern controllers have onboard I/O or accept cheap I/O modules, and a dozen cores of multicore cable is testable with a multimeter and understood by every electrician on the planet. If your handshake is run, ready, done and fault, do not let anyone talk you into a fieldbus you do not need.

Above roughly a dozen signals — or where you need program number selection, diagnostics, or room to grow — a fieldbus earns its place. One network cable replaces a loom, and adding a signal becomes a configuration change rather than a wiring job. On one of our cells the robot exchanges over forty signals with the cell controller through a single bus coupler; hardwiring that would have been a full day of panel work and a fault-finding liability for the next decade.

• PROFINET — the default choice with Siemens PLCs, widely supported by every major robot brand
• EtherCAT — common with Beckhoff-based control systems; the robot typically connects via a bus coupler
• EtherNet/IP — the default in Rockwell environments
• DeviceNet — legacy, but you will meet it on older KUKA controllers and second-hand robots, and it still works perfectly well

The honest selection rule: use whatever fieldbus your PLC platform speaks natively. The robot will support it. Choosing an exotic combination because a forum post benchmarked it faster is how you end up alone with a gateway device nobody can configure.

Mapping the I/O — where the confusion lives

Here is the thing that catches almost everyone the first time: the PLC and the robot describe the same signal with different addresses. A Beckhoff or Siemens PLC thinks in bytes and bits — output byte 0, bit 3. The robot thinks in numbered I/O — a KUKA sees $IN[1] to $IN[4096]. The fieldbus simply carries a block of bytes between the two, and the mapping defines which byte and bit lands on which robot input.

The pattern is mechanical once you see it: each PLC byte carries eight robot signals in sequence. Byte 0 bit 0 is robot input 1, byte 0 bit 7 is robot input 8, byte 1 bit 0 is robot input 9, and so on up the range. Program number bits sitting at robot inputs 33 to 38 therefore live in PLC byte 4, bits 0 to 5. Work it out once, then never trust mental arithmetic again — build the conversion table.

That table — every signal, both addresses, one row — is the single most valuable document of this whole stage. It is what you will hold during point-to-point testing in Part 8, and it is what the next engineer will beg you for in five years. Produce it as a spreadsheet, keep it with the I/O schedule from Part 5, and update it every single time the mapping changes.

On the KUKA side the mapping is done in WorkVisual: add the fieldbus device to the bus structure from its device description file, then wire the fieldbus bytes to $IN/$OUT ranges in the I/O mapping editor, and deploy the project to the controller. On the ABB side the equivalent lives in RobotStudio's configuration editor — define the industrial network, the device, and then each signal with its device mapping, either directly on the controller or offline and deployed. Different menus, same concept: bytes on a wire, mapped to numbered signals.

Automatic External — letting the PLC drive

Out of the box, a robot runs programs when a person selects one on the pendant and presses start. That is no use in production. Automatic External (KUKA's name; ABB achieves the same with system inputs and outputs) is the interface that hands those pendant actions to the PLC as signals.

On a KUKA, the interface is a defined set of signals you assign to your mapped I/O in the Automatic External configuration screen. The ones that matter:

• PGNO bits, PGNO_PARITY and PGNO_VALID — the PLC presents a program number in binary, a parity bit, and then a strobe to say the number is valid. This is how the PLC selects which routine the robot runs
• $EXT_START — the PLC's start command, and CONF_MESS to acknowledge resettable messages remotely
• $DRIVES_ON / $DRIVES_OFF and $MOVE_ENABLE — the PLC's control over the drives, conditioned by the safety circuit being healthy
• $RC_RDY1 and PERI_RDY back to the PLC — the robot telling the cell it is ready and its drives are on. Wire these to your stack light logic; an operator can see at a glance why the cell has not started

The start-up sequence then becomes a small PLC routine: safety healthy → drives on → wait for peripheral ready → present program number → valid strobe → external start. Get this sequence working once on the bench and save it; it is identical on every KUKA cell you will ever build. On the ABB side you assign the equivalent system inputs — Motors On, Start at Main, Reset Emergency Stop — to your mapped signals in the controller configuration, and the same PLC sequence applies with different names.

Prove the signals before you program anything

Before a single line of robot code exists, prove every mapped signal end to end. Force each PLC output on and watch the corresponding input change on the robot's I/O display; set each robot output from the pendant and watch it arrive in the PLC. Both KUKA and ABB give you live I/O monitors on the pendant for exactly this. An hour of methodical point-to-point checking here saves days of chasing "the program doesn't work" faults that are actually one transposed bit in the mapping — and in our experience, the first fault on a new cell is a mapping fault far more often than a code fault.

Common mistakes

• Byte and bit arithmetic done in heads, not in a table. One-off errors here produce faults that look like program bugs
• Forgetting the parity bit on KUKA program number selection, then losing an afternoon to PGNO_VALID doing apparently nothing
• Overlapping mapped ranges — two devices writing to the same robot inputs produces intermittent faults that only appear in production
• Running safety functions over the standard bus because the terminals were there. Part 3 defined where safety lives. It has not changed
• Not saving the WorkVisual project or controller backup after the mapping is proven. The mapping is configuration, and configuration that only exists on the controller is one hardware failure from gone

Next in the series

Robot Programming — coming soon

→