Specify Robot I/O Handshakes, Faults, and Restart Behavior

Start with a signal contract

A wiring list says where a signal goes; an integration contract says what it means. For every interface, record direction from a named device's perspective, producer, consumer, active meaning, update rule, expected response, and fault behavior. Replace vague names such as ready with a precise statement: ready to accept a new job under defined local conditions, or finished processing the current job. Those meanings must not be silently interchangeable.

Universal Robots' PolyScope SW5.21 I/O Setup documentation describes naming signals and assigning program-related actions. It is a useful controller-specific reference, checked September 5, 2026. Use the actual robot and PLC manuals to implement your contract, because the editorial signal model here does not define a vendor protocol. Agree on a common vocabulary before either programmer creates logic. Review it with the person who will diagnose the interface when one device reports a different state from the other.

References: I/O Setup, PolyScope SW5.21

Verify electrical and functional boundaries

Have qualified electrical personnel verify interface type, supply arrangement, reference, isolation, load compatibility, and protection against the exact equipment documentation. Do not infer compatibility from connector shape or a shared signal name. The cited Universal Robots General Purpose Digital I/O page is explicitly from SW5.25.1 and distinguishes ordinary I/O from configurable channels used for safety. Its described machine interface has specific electrical assumptions; do not transfer them to unrelated controllers.

Keep safety-related functions in the validated safety design and its documented interfaces. A software ready bit, communication heartbeat, or learned perception result cannot replace that design. Record which team owns each boundary and which tests require isolation or a controlled commissioning state. This article is a specification checklist, not a wiring procedure. Any change to field connections, output loads, or safety configuration should follow the responsible integrator's approved engineering and verification process.

References: General Purpose Digital I/O, SW5.25.1 manual page

Make request and acknowledgement explicit

Describe a job as a transaction with a beginning, acknowledgement, active phase, and completion. Decide whether the request remains asserted until acknowledged or follows another documented protocol. Specify how the receiver identifies a new request, how the sender learns that it was accepted, and how both return to a state that allows the next job. A short pulse without a capture guarantee is an assumption about timing, not a complete interface specification.

For a hypothetical transfer station, the following names are an editorial example rather than a standard register map. Give every transition a defined owner and include a way to distinguish a current completion from a previous one. Where the chosen protocol supports transaction identifiers, define their lifecycle and restart handling. For a discrete-bit interface, document the equivalent state sequence and test it under the approved commissioning plan.

References: I/O Setup, PolyScope SW5.21

Distinguish a command from evidence of the process

Separate the instruction to act from confirmation that the intended physical condition exists. An output requesting gripper closure establishes that a command was issued; it does not by itself establish that an object was retained. Define which sensor or validated process condition establishes completion and how uncertain or contradictory evidence is handled. Record the expected sequence of evidence so that a stuck signal cannot look like a fresh successful operation.

For each process confirmation, specify freshness, applicability to the current job, and the state in which it may be trusted. A sensor active before the action may have a legitimate explanation, but the program should not silently interpret it as a new transition. Design the review around observable disagreements: command sent but no confirmation, confirmation present without a command, or conflicting indications. Qualified integrators should decide the controlled response for each case using the complete machinery design.

References: I/O Setup, PolyScope SW5.21 · General Purpose Digital I/O, SW5.25.1 manual page

Define delays, timeouts, and fault responses

Specify the origin of each timeout and what happens when it expires. Distinguish waiting for acceptance from waiting for physical completion, and identify which participant reports the fault. Set durations from process requirements and measured behavior under the approved design, rather than copying arbitrary values from an example. A timeout should produce a diagnosable state with the relevant request and observation retained, not an endless automatic retry loop.

When a ROS 2 gateway is involved, verify its communication assumptions separately from the PLC handshake. The official Jazzy QoS documentation explains compatibility and policies for delivery, freshness, and liveliness. These mechanisms help characterize communication; they do not define the physical response of your application. State how the gateway rejects stale data, reports lost communication, and recovers its internal state. A restored connection should not automatically authorize replaying an old command whose physical consequences are uncertain.

References: Quality of Service settings, official ROS 2 Jazzy documentation source

Design stop and restart semantics before normal cycling

Write separate behavior for pause, ordinary stop, fault, communication loss, controller reboot, and approved recovery. Identify retained variables and outputs that change with program state. In SW5.21, Universal Robots documents configurable input actions and output behavior tied to running or stopped programs. Therefore, inspect the actual installed configuration instead of assuming every output drops or every request is forgotten when a program stops.

Consider a restart in the middle of a job. The robot may hold a part while the coordinator has lost its transaction record, or the coordinator may retain a request after the robot resets. Define how the system reconciles physical and logical state before accepting new work. Require an approved recovery decision for ambiguous conditions. Prevent reset from becoming an implicit restart, and review external start behavior with the qualified team responsible for the cell's commissioning and safety validation.

References: I/O Setup, PolyScope SW5.21

Worked hypothetical example: a stale completion signal

Imagine the robot completes a job and asserts completion, then communication fails before the coordinator acknowledges it. After reconnection, the coordinator issues a new request while the old completion remains visible. This is an invented scenario. A poorly specified sequence could count the new request as already finished. The contract should instead explain how completion belongs to the previous transaction and how both participants reach an agreed state before new work begins.

Review that scenario first with a state model or simulated interface, then include the relevant controlled checks in commissioning. Test delayed acknowledgement, repeated requests, missing confirmations, and a restart at each meaningful phase. Do not create live hazards or defeat safeguards to inject faults. Record expected and observed behavior, the exact logic versions, and any unresolved mismatch. The useful result is evidence that the interface handles the defined cases, with clear boundaries on what has been tested.

References: I/O Setup, PolyScope SW5.21 · Quality of Service settings, official ROS 2 Jazzy documentation source

Hand over an interface someone can diagnose

Deliver the signal contract alongside the electrical documentation, program versions, approved state sequence, commissioning results, and recovery procedure. Include a troubleshooting view that shows the current transaction phase and the last relevant transition. Prefer precise fault messages such as acceptance not received for the current job over a generic robot error. Avoid exposing confidential network or access information in forum screenshots; keep the operational record accessible to authorized maintainers.

When either side changes, review the shared contract and repeat tests affected by that change. A renamed signal is minor only if its meaning, timing, and ownership truly remain identical. Preserve accepted versions so that backup and recovery can restore a compatible pair. End the handover with named ownership for unresolved faults and evidence limits. This specification discipline makes later cycle-time investigation possible because waiting states have an agreed meaning and a traceable cause.

References: I/O Setup, PolyScope SW5.21 · General Purpose Digital I/O, SW5.25.1 manual page

Checklist

• Define signal direction, ownership, meaning, freshness, and reset behavior.
• Have qualified personnel verify electrical compatibility against exact manuals.
• Keep ordinary process signals separate from the validated safety design.
• Specify request, acknowledgement, completion, and transaction reset transitions.
• Distinguish output commands from independent process confirmation.
• Define timeout ownership, diagnosis, and controlled recovery.
• Review pause, stop, reboot, and communication-loss cases before commissioning.
• Retain expected-versus-observed test evidence and compatible program versions.

Common questions