On this page
In brief: A dependable PLC–robot interface is an agreed state machine: every request is acknowledged, every job ends in “complete” or “fault”, every wait has a timeout and every restart has explicit conditions. A handful of bits with loosely matched timing works until the first interruption.
Why loose bits fail
Two controllers that exchange signals do not share a clock or a program cycle. The PLC and the robot controller each read inputs, run logic and write outputs at their own rate, and the fieldbus between them adds its own update interval. A signal that one side sets and clears quickly may never be seen by the other; a signal that is left on may be read twice. In normal running these effects are rare, which is why an interface built from a “start” bit and a “done” bit can pass a demonstration. The trouble comes after a stop, a reset or a communication loss, when the two controllers no longer agree about what was requested and what was finished.
Define the contract as states
Describe the exchange as states with an owner, not as a list of tags. One illustrative sequence is idle/ready, request, accepted, busy, complete and fault. These names are teaching examples; they are not a standard and not any vendor’s signal list. For each transition, write down which controller causes it, which condition makes it valid, how long the other side may take to respond and what happens when that time runs out.
The basic pattern is a four-step exchange: the PLC raises a request, the robot acknowledges it, the PLC removes the request, and the robot removes the acknowledgement. Holding each state until the other side responds avoids dependence on catching a short pulse. It does not remove timing requirements: define communication cycles, watchdogs, acknowledgement deadlines and what each side does if the exchange stops progressing.
Prevent stale and duplicate commands
A request held on through a reset can be mistaken for a new command after restart. Require a defined return-to-idle sequence before accepting another request. Echo the job or recipe identifier so the requested operation is clear, but do not use it alone to identify a particular execution: repeated parts can use the same recipe. Where the interface supports it, add a command sequence identifier and define its persistence, rollover and restart/session rules. Specify how duplicates and uncertain completion are reconciled. After a restart, establish the actual equipment and part state—gripper occupied or empty, fixture loaded or not—before resuming automatic operation. Identifiers alone cannot prove that a physical operation completed exactly once.
Keep safety and ordinary control apart
A ready bit, a heartbeat or a flag called “safe to enter” that travels over the standard interface is ordinary control data. It is not a safety function, whatever its name. Protective stops, access protection and other safety functions are designed and validated separately, on the basis of the risk assessment of the complete robot application, the subject of ISO 10218-2:2025. The handshake should still report safety events as information, so that an operator can tell a process fault from a safety stop and choose the right recovery. Manual recovery is non-routine work, and OSHA notes that many robot accidents occur during non-routine operating conditions.
Test the interrupted cases
Witness more than normal running: requests in quick succession, a communication interruption, a power cycle of each controller in the middle of a job, missing gripper feedback and a controlled manual recovery. Log events with timestamps on both controllers so that their order can be reconstructed. For vocabulary, PackML (ISA-TR88.00.02), developed by OMAC and adopted by ISA, is a published machine state model. It describes machine states, not robot signals.
Checklist before committing budget or scope
- A signal ownership table and a state transition diagram agreed by both programmers.
- A timeout and a defined reaction for every wait.
- A rule for stale and duplicate requests, with a job identifier where useful.
- A restart procedure after either controller, or both, has rebooted.
- Safety functions assessed and validated separately from the handshake.
- A FAT record of the interrupted cases, with alarms and operator actions.
What this guide does not establish
This is a planning aid. It defines no standard signal list, describes no specific robot or PLC and reports no tests. How outputs behave on a stop, on loss of the bus and on restart differs between products and must be taken from the manufacturers’ documentation. Nothing here replaces the risk assessment or the validation of safety functions, which must be carried out on the real system by suitably qualified people.
Sources and further verification
- ISO — ISO 10218-2:2025, Robotics — Safety requirements — Part 2: Industrial robot applications and robot cells (catalogue page; 2025-02; accessed 2026-10-11).
- OMAC — PackML: overview page describing PackML as developed by OMAC and adopted by ISA as TR88.00.02 (undated; accessed 2026-10-12).
- OSHA — Robotics: overview page stating that many robot accidents occur during non-routine operating conditions (undated; accessed 2026-10-12).
Next useful step
If you are specifying a PLC–robot interface, draw the state diagram and the signal table before any code is written, then see the Robotics & Automation page. Projects that start there are scoped and delivered through Eurobots/ReBots, and an evaluation begins with feasibility and responsibility boundaries rather than an assumed turnkey installation. The engineering background behind these guides is in the AYXWORKS portfolio.
Image credit: ayxworks — Original / rights held.
