PLC Integration for Robot Cells: Structured Text, PROFINET, and Safety Design

Does a PLC control the robot's motion? No — and this is the single most common misunderstanding in robot-cell integration. The robot controller (FANUC, ABB, KUKA, or similar) owns the trajectory, the joint interpolation, and the servo loop. The PLC's job is to coordinate everything around the robot: conveyors, fixtures, vision triggers, part-presence sensors, and the safety chain. The interface between the two is a small, well-defined set of signals — not a stream of motion commands.

A PLC coordinates the cell around the robot; the robot controller owns the motion.

Dividing responsibility: PLC vs. robot controller

A robot controller such as a FANUC R-30iB (or its later R-30iB Plus / R-30iB Mate variants) is a closed, real-time motion system: it reads its own encoders, closes its own servo loops, and executes its own teach-pendant program. A PLC such as a Siemens S7-1500, running in TIA Portal, is a general-purpose sequencer: it scans I/O, runs the cell's logic, and talks to other stations. Neither system should try to do the other's job. Trying to stream individual joint targets from a PLC to a robot controller is unusual, fragile, and rarely how commercial cells are built — the exchange is almost always a handful of handshake bits and a small number of integers (program number, part ID, fault code).

This separation also matters for maintainability: a robot programmer can change the internal motion program without touching PLC logic, as long as the handshake contract at the boundary stays the same, and vice versa.

Choosing a communication link: PROFINET, EtherNet/IP, or discrete I/O

Most modern robot controllers offer an optional fieldbus card so the controller appears to the PLC as an I/O device on the network. Siemens PLCs commonly use PROFINET; Allen-Bradley/Rockwell PLCs commonly use EtherNet/IP. The robot vendor's option catalog determines which protocols are actually available for a given controller and firmware version — always confirm the exact option code with the robot vendor before assuming a protocol is supported.

Whichever link is chosen, treat it as a data source that can be stale or absent — never assume the network guarantees delivery at a fixed rate. That assumption belongs in the handshake design, covered next.

Designing the handshake signal set

Regardless of the physical link, most PLC-robot interfaces converge on a similar signal set. Naming varies by integrator, but the functions below appear in nearly every cell:

A frequent design mistake is treating "Cycle Done" as reliable proof that the robot is safe to approach or that the part is good. It only proves the program ran to completion — separate sensors (part-present, vision confirmation, torque feedback) should confirm the actual outcome.

Structured Text example: a handshake state machine

The following is a simplified Structured Text (ST) sketch, one of the languages defined by IEC 61131-3 alongside Ladder Diagram, Function Block Diagram, and Sequential Function Chart. It illustrates the shape of a handshake state machine, not a vendor-specific, production-ready block — adapt tag names, timers, and fault handling to the actual PLC platform and robot I/O map.

TYPE CellState : (IDLE, WAIT_ROBOT_READY, REQUEST_START, WAIT_DONE, FAULT);
END_TYPE

VAR
    state          : CellState := IDLE;
    robotReady     : BOOL;      // Robot -> PLC
    robotBusy      : BOOL;      // Robot -> PLC
    robotDone      : BOOL;      // Robot -> PLC
    robotFault     : BOOL;      // Robot -> PLC
    cycleStart     : BOOL;      // PLC -> Robot
    faultReset     : BOOL;      // PLC -> Robot
    heartbeatIn    : BOOL;      // toggled by robot side
    heartbeatOut   : BOOL;      // toggled by PLC side
    hbTimer        : TON;       // link-loss watchdog
    hbTimeout      : BOOL;
END_VAR

// Toggle our own heartbeat every scan the program is healthy
heartbeatOut := NOT heartbeatOut;

// Watchdog: if the robot's heartbeat hasn't changed, start the timer
hbTimer(IN := NOT heartbeatIn, PT := T#2S);
hbTimeout := hbTimer.Q;

CASE state OF
    IDLE:
        cycleStart := FALSE;
        IF robotReady AND NOT hbTimeout THEN
            state := REQUEST_START;
        END_IF;

    REQUEST_START:
        cycleStart := TRUE;
        IF robotBusy THEN
            cycleStart := FALSE;
            state := WAIT_DONE;
        END_IF;

    WAIT_DONE:
        IF robotDone THEN
            state := IDLE;
        ELSIF robotFault OR hbTimeout THEN
            state := FAULT;
        END_IF;

    FAULT:
        cycleStart := FALSE;
        // Operator or higher-level logic must clear the root cause first
        IF faultReset AND NOT robotFault AND NOT hbTimeout THEN
            state := IDLE;
        END_IF;
END_CASE;

Three details matter more than the syntax itself: the watchdog transitions to FAULT on its own, the PLC never asserts cycleStart without first checking robotReady, and clearing a fault requires both an explicit operator action (faultReset) and confirmation that the underlying condition is actually gone.

Safety architecture: what stays outside the standard PLC

The handshake logic above runs in the standard, non-safety part of the PLC program. It must never be the only thing standing between a person and a moving robot. Emergency stop, guard-door interlocks, and any speed- or force-limiting function belong in a safety-rated controller, safety relay, or safety I/O module, architected to the category and performance level the cell's risk assessment calls for (per ISO 13849-1 concepts such as Category 3 and Performance Level d, or the equivalent SIL framework under IEC 62061). Which category and PL apply is a risk-assessment output, not a fixed number that transfers automatically from one cell to another.

In practice, most cells use hardwired safety relays or a safety PLC for the e-stop chain and guard monitoring, with the standard PLC and robot controller handling only the production handshake. The two systems typically share status information (e.g., "safety circuit OK") so the standard logic can react gracefully, but the safety function itself does not depend on the standard PLC program executing correctly.

Common integration failures

Commissioning checklist

1. Confirm which fieldbus options are actually licensed and installed on the specific robot controller and firmware version — not just what the vendor catalog lists in general.
2. Map every handshake signal by name on both sides (PLC tag and robot I/O point) before writing logic, and keep that map as a living commissioning document.
3. Test loss of network/fieldbus communication deliberately; confirm the cell reaches a defined, safe state rather than freezing on stale data.
4. Verify the safety chain (e-stop, guard doors) functions with the standard PLC program stopped or faulted — safety must not depend on standard logic running.
5. Confirm the robot's "Ready" and "Fault" outputs actually reflect controller state under test conditions (forced fault, mode switch, program stop) rather than assuming the documentation is accurate for this specific configuration.
6. Record firmware versions, fieldbus option part numbers, and I/O maps for both the PLC and the robot controller as part of the handover documentation.

Sources

For current specifications, confirm directly with the manufacturer documentation rather than relying on a summary: the Siemens S7-1500 product page, the FANUC R-30iB controller page, the IEC 61131-3 standard for programming languages, the ISO 13849-1 information page for safety-related control system categories, and PROFINET / PI International for fieldbus specifications. Standards editions and product options change; verify the current revision before specifying a cell.

Related robot-arm guides

Continue with the ROS 2 robot control guide, the robot arm safety standards overview, and the gripper design guide. Together with this article, they cover the control, communication, and mechanical decisions in a typical industrial robot cell.

Frequently asked questions