Industrial Communication — Ch.09: PLC Integration [EN]

STATERA Library · Series 07 · Volume 07 · Chapter 09 · EN
Source: https://github.com/Statera-Library/07_Vol_07_Industrial_Communication/blob/main/Chapter_09_PLC_Integration/Chapter_09_PLC_Integration_EN.md

Volume 07. Industrial Communication

Chapter 09. PLC Integration

09.01. IEC 61131-3 Languages

IEC 61131-3 defines a standardized programming model for programmable logic controllers and related industrial automation systems. Its purpose is to make control software more structured, portable, and understandable across different PLC platforms. Rather than prescribing one programming notation, the standard establishes several complementary languages that allow engineers to express logic according to the nature of the control problem.

The IEC 61131-3 language model is particularly important in PLC integration because industrial control applications combine discrete logic, sequencing, numerical processing, timing, state management, and equipment coordination. A single representation is rarely ideal for every task. The standard therefore provides graphical and textual approaches that can coexist within the same automation project while following common concepts for variables, data types, functions, and program organization.

Ladder Diagram, commonly abbreviated as LD, represents control logic through graphical networks resembling traditional electrical relay circuits. Contacts describe logical conditions and coils typically represent resulting states or outputs. Because signals are evaluated through visually connected paths, technicians familiar with electrical schematics can understand machine interlocks, start-stop circuits, sensor conditions, alarms, and actuator commands without interpreting conventional software syntax.

Function Block Diagram, or FBD, represents control functions as interconnected blocks through which signals and data flow. Each block performs a defined operation, while connections describe relationships between inputs and outputs. FBD is well suited to applications containing reusable control functions such as timers, counters, PID controllers, signal conditioning, motor functions, valve control, analog processing, and equipment modules that naturally form interconnected functional networks.

Structured Text, abbreviated ST, is a high-level textual language designed for control algorithms that become cumbersome when represented graphically. Its syntax supports expressions, assignments, conditional statements, loops, function calls, and structured data processing. ST is therefore effective for mathematical calculations, coordinate transformations, state evaluation, communication processing, parameter management, array operations, and other algorithm-oriented functions used in increasingly software-intensive automation systems.

Sequential Function Chart, or SFC, provides a structured representation of processes that progress through identifiable operating stages. A sequence is organized around steps, transitions, and associated actions, allowing engineers to describe when a machine enters a state and what condition permits movement to the next state. This approach is useful for assembly sequences, material handling, robot cells, charging operations, docking procedures, inspection cycles, and coordinated production processes.

IEC 61131-3 has historically also included Instruction List, or IL, as a low-level textual programming language resembling assembly-style instructions. IL was useful on earlier PLC systems with limited computational resources, but modern automation engineering generally favors more structured representations. Consequently, IL has been deprecated in newer editions of the standard, while LD, FBD, ST, and SFC form the practically important language set for contemporary PLC development.

These languages should not be regarded as competing alternatives that require an entire project to use only one representation. A PLC application can use LD for straightforward interlocks, FBD for reusable control blocks, ST for complex algorithms, and SFC for machine sequencing. This mixed-language approach allows each control problem to be represented in the form that most clearly expresses its behavior while maintaining an integrated PLC application architecture.

A central concept supporting this integration is the Program Organization Unit, commonly called a POU. Programs, function blocks, and functions provide different forms of reusable software organization. Functions generally calculate outputs from supplied inputs, while function blocks can preserve internal state between executions. Programs coordinate larger application behavior. These constructs encourage engineers to separate hardware handling, reusable device logic, sequence control, communication, and supervisory functions.

IEC 61131-3 also standardizes fundamental software concepts such as variables and data types. Boolean values represent logical states, integer and real types support numerical processing, and time-related types support timers and sequence management. Arrays, structures, enumerations, and user-defined types can organize increasingly complex automation data. Stronger data organization becomes particularly valuable when PLC applications exchange structured information with robots, drives, sensors, HMIs, gateways, and manufacturing systems.

PLC execution is generally cyclic. Inputs are acquired, application logic is executed according to configured tasks, and resulting outputs are updated. IEC 61131-3 programming must therefore be understood together with scan-cycle behavior and task scheduling. Logic that appears sequential in source representation operates within this repetitive execution model, making execution order, timing, retained state, edge detection, and deterministic response important considerations in real industrial control applications.

Timers and counters illustrate how the standardized language model connects software abstraction with physical automation behavior. On-delay and off-delay timers can represent temporal requirements, while counters track repeated events such as produced parts or completed cycles. These elements can be used directly in graphical languages or incorporated into more complex software structures, enabling engineers to represent both logical conditions and time-dependent behavior within a consistent PLC environment.

In robot integration, IEC 61131-3 languages frequently implement the deterministic supervisory logic surrounding robot controllers rather than replacing the robot\'s own motion-control software. PLC logic may validate safety-related prerequisites, request robot operations, monitor busy and completion states, supervise fixtures, control conveyors, and coordinate upstream or downstream equipment. The robot controller can then concentrate on trajectory generation, kinematics, servo control, and manufacturer-specific motion functions.

This division becomes especially useful in AMR and factory automation systems. A PLC may coordinate doors, conveyors, elevators, charging stations, machine tools, or material-transfer equipment, while an AMR controller performs localization, planning, navigation, and obstacle avoidance. Communication interfaces connect these domains, but IEC 61131-3 logic provides deterministic machine-side conditions such as permission to enter, transfer readiness, docking confirmation, process completion, and fault recovery.

Industrial communication therefore interacts closely with PLC programming. PROFINET, EtherNet/IP, EtherCAT, Modbus TCP, IO-Link, and OPC UA may deliver process variables and device states to the PLC application, but the communication protocol itself does not define the machine\'s operational logic. IEC 61131-3 programs interpret those values, apply control conditions, generate commands, and coordinate equipment behavior, forming the software layer between networked industrial devices and the required automation sequence.

Effective IEC 61131-3 engineering requires more than knowing individual language syntax. Engineers must define clear variable naming, interface boundaries, state ownership, fault behavior, initialization, timeout handling, and recovery mechanisms. Reusable function blocks should encapsulate device behavior, while higher-level sequences should avoid unnecessary dependence on low-level hardware details. Such separation improves testing, commissioning, maintenance, and migration when equipment or network interfaces change.

For Physical AI and advanced robotics, IEC 61131-3 remains relevant because intelligent systems still interact with deterministic industrial infrastructure. AI may perform perception, prediction, planning, or adaptive decision-making, while PLC software enforces explicit operational conditions and coordinates conventional automation equipment. The resulting architecture combines probabilistic intelligence with deterministic control, allowing advanced robots to participate safely and predictably in established factory processes and industrial communication environments.

09.02. PLC Robot Interface Design

A PLC--robot interface defines the structured communication boundary between a programmable logic controller and an industrial robot controller. The PLC normally supervises production equipment and coordinates machine-level sequences, while the robot controller manages robot-specific motion, kinematics, trajectory execution, and servo functions. A well-designed interface separates these responsibilities while providing deterministic commands, status information, and fault handling.

The interface should be designed around explicit ownership of each signal. Commands such as Start, Stop, Reset, Cycle Request, Home Request, or Program Select are normally generated by the PLC, while signals such as Ready, Busy, Cycle Complete, At Home, Fault, or Program Running originate from the robot controller. Clearly defining the producer and consumer of every signal prevents conflicting commands and simplifies commissioning and diagnostics.

A basic robot handshake uses command and acknowledgement signals rather than relying on a single transient trigger. For example, the PLC asserts a Cycle Request only after confirming that the robot is ready and all external conditions are satisfied. The robot acknowledges the request, begins execution, reports Busy, and eventually indicates Cycle Complete. The PLC then removes the request and waits for the interface to return to its defined idle condition before starting another cycle.

Handshake design should account for timing differences between PLC scan cycles, industrial networks, and robot controller execution. A short pulse may disappear before the receiving controller detects it, particularly when communication updates are slower than local control cycles. Level-based request and acknowledgement signals are therefore often preferable. Signals remain asserted until the corresponding state transition is confirmed, producing communication that is easier to verify and more tolerant of timing variations.

Robot operating states should be represented independently from individual commands. Typical states include Not Ready, Ready, Running, Hold, Fault, Emergency Stop, and Maintenance or Manual operation. The PLC can use these states to determine whether a requested operation is permissible. Separating state information from command signals also makes supervisory logic clearer because the PLC evaluates the current robot condition before issuing the next operation request.

Program selection is another important part of the PLC--robot interface. Instead of creating a dedicated Boolean signal for every robot routine, an integer or structured command value can identify the required operation. The PLC writes the requested program or job identifier, verifies that the robot has accepted the value, and then initiates execution. This approach scales more effectively when one robot performs many manufacturing, handling, inspection, or tool-related operations.

Interlocks ensure that robot motion occurs only when required machine conditions are satisfied. A robot may need confirmation that a fixture is clamped, a conveyor is stopped, a door is in the required condition, a part is present, or another machine has cleared a shared workspace. These conditions should be explicitly defined at the interface boundary so that responsibility for permitting an operation is not ambiguously distributed between the PLC and robot program.

Normal control interlocks must be distinguished from safety functions. Production logic may request that a robot stop or remain outside a work area, but safety-related functions require an appropriate safety architecture using safety PLCs, safety-rated robot functions, certified devices, and safety communication where applicable. The standard PLC--robot process interface should therefore coordinate operation without being treated as a substitute for the independent safety control system.

Fault handling requires more information than a single general Fault bit. A general fault indication is useful for immediate sequence control, but diagnostic information should identify the fault category or code whenever possible. The PLC or supervisory system can then distinguish robot faults, communication faults, tooling problems, process failures, and external interlock conditions. Structured diagnostic information significantly reduces troubleshooting time during production and commissioning.

Reset behavior must also be explicitly designed. A PLC Reset Request should not automatically cause uncontrolled motion or restart an interrupted robot sequence. The robot controller should clear only conditions that are permitted to be remotely reset and then report its resulting state. After recovery, the PLC should reevaluate machine conditions and determine whether the process should restart, resume from a defined recovery point, or require operator intervention.

Industrial Ethernet networks commonly transport PLC--robot interface data. PROFINET, EtherNet/IP, EtherCAT, or other supported fieldbus technologies can exchange cyclic command and status data with predictable update behavior. The protocol provides communication transport, while the actual meaning of Start, Ready, Busy, Complete, Fault, program numbers, and diagnostic values must still be defined as part of the application-level interface between the PLC and robot.

Interface data should be organized into logical command and status structures rather than scattered across unrelated network addresses. A PLC-to-robot structure can contain command bits, mode requests, program identifiers, parameters, and sequence numbers, while a robot-to-PLC structure contains acknowledgement bits, operating states, execution results, diagnostics, and actual values. Consistent structures improve readability and make interfaces easier to reuse across multiple robot cells.

Sequence numbers can strengthen interfaces when repeated commands or communication interruptions must be handled reliably. The PLC associates a transaction identifier with a command, and the robot returns the corresponding identifier with its acknowledgement or result. This allows both controllers to distinguish a new request from stale data remaining after a restart or network interruption and becomes especially valuable in complex automated production and inspection systems.

Communication supervision should detect loss of cyclic data or failure to receive an expected response within a defined time. Watchdogs, connection status, and application-level timeouts allow the PLC to distinguish a slowly executing robot operation from an actual interface failure. Timeout values should reflect realistic robot and process behavior rather than being arbitrarily short, and recovery behavior should be explicitly defined for each communication failure condition.

The PLC--robot interface becomes more complex when peripheral devices are involved. Grippers, tool changers, vision systems, fixtures, conveyors, and inspection equipment may be controlled by either the PLC or robot controller. Ownership should be selected according to system architecture and timing requirements. Regardless of ownership, the opposite controller should receive sufficient status information to coordinate the overall sequence without duplicating low-level device control.

For an AMR connected to a robot cell, the same interface principles can be extended to mobile material transfer. The PLC may report Cell Ready, Transfer Permission, Load Ready, or Unload Complete, while the AMR or fleet system provides Arrival, Docked, Mission Active, Transfer Complete, and Fault states. The interface should isolate navigation and fleet-management logic from deterministic machine sequencing while maintaining an explicit handshake at the physical transfer boundary.

Higher-level systems such as MES, WMS, or OPC UA applications may provide production orders, material identities, recipes, and reporting requirements, but they should not unnecessarily replace the deterministic PLC--robot handshake. The PLC can translate higher-level production intentions into controlled machine operations, while the robot executes defined tasks. This layered architecture separates enterprise information exchange, machine coordination, and robot motion into clearly managed functional domains.

A robust PLC--robot interface should ultimately be treated as a formal software and communication contract. Signal names, ownership, data types, valid states, transition conditions, timeouts, initialization behavior, fault responses, and recovery procedures should be documented before commissioning. When these rules are consistent across robot cells, integration becomes easier to test, reuse, diagnose, and extend to factory automation, AMR systems, and increasingly complex Physical AI environments.

09.03. Safety PLC Integration

Safety PLC integration establishes a dedicated control layer for safety-related functions within industrial automation and robotic systems. Unlike a standard PLC that primarily manages production sequences, a safety PLC executes certified safety logic intended to reduce risk when hazardous conditions occur. It evaluates safety devices, determines whether operation remains permissible, and commands equipment toward a defined safe state when required.

A safety PLC should be understood as part of the overall safety architecture rather than simply as a more reliable conventional PLC. Its hardware, firmware, engineering environment, communication mechanisms, and diagnostic functions are designed according to functional safety principles. The required architecture depends on the risk assessment and applicable machinery standards, including considerations such as Safety Integrity Level, Performance Level, diagnostic coverage, and fault tolerance.

Safety inputs originate from devices that detect hazardous conditions or confirm safety-related operating states. Typical examples include emergency-stop switches, guard-door interlocks, light curtains, safety laser scanners, enabling devices, pressure-sensitive equipment, and safety-rated position sensors. The safety PLC continuously evaluates these signals and executes predefined logic to determine whether motion, power, or another potentially hazardous function may continue.

Safety outputs connect the evaluated safety logic to mechanisms capable of establishing the required safe state. These may include safety contactors, safe drive inputs, motor power isolation devices, pneumatic dump valves, or safety functions integrated into servo drives and robot controllers. The required response is application dependent because a safe state may involve removing torque, performing a controlled stop, limiting motion, or preventing unexpected restart.

Redundancy and diagnostics are fundamental characteristics of safety PLC architectures. Safety input channels may use dual-channel wiring so that open circuits, short circuits, contact faults, or discrepancies between channels can be detected. The safety controller performs internal self-tests and monitors connected devices for abnormal behavior. Safety integrity therefore depends not only on redundant hardware but also on the ability to detect dangerous faults before they compromise the safety function.

Emergency-stop integration illustrates the difference between process control and safety control. A normal PLC may monitor an emergency-stop status for diagnostics or production sequencing, but the actual safety function should be executed through the safety-rated control path. When an emergency stop is activated, the safety PLC evaluates the input and commands the predefined safe response independently of whether the normal production PLC or supervisory software continues operating correctly.

Guarding systems use similar principles. A safety door switch can indicate whether access to a hazardous robot or machine area is permitted. Opening the guard may initiate a safety stop, while closing it does not necessarily authorize automatic restart. The safety PLC must evaluate additional conditions such as reset requests, machine state, and absence of other safety demands before allowing hazardous operation to become enabled again.

Reset logic requires particular attention because resetting a safety function and restarting a machine are different operations. A safety reset acknowledges that the conditions required to restore the safety function have been satisfied, but it should not automatically initiate hazardous movement. Production restart should occur through a separate operational command after the normal PLC and machine controllers have confirmed that the process is ready to continue.

Modern drives and robot controllers provide integrated safety functions that can be commanded through safety PLCs. Safe Torque Off prevents torque-producing energy from being applied to a motor, while other functions can support controlled stopping, safely limited speed, safe direction, or safe position monitoring depending on the equipment. Using these functions can reduce reliance on complete power removal while supporting more flexible machine and collaborative robot operation.

Safety communication extends the safety architecture across industrial networks. Technologies such as PROFIsafe, CIP Safety, and FSoE allow safety-related data to be transported over communication systems that may also carry ordinary process data. The safety protocol adds mechanisms for detecting communication errors such as corrupted, repeated, delayed, lost, or incorrectly addressed messages, allowing distributed safety devices and controllers to participate in a coordinated safety system.

The use of a shared physical network does not mean that ordinary communication automatically becomes safety rated. Safety integrity is established by the safety protocol, certified devices, validated configuration, and complete safety function rather than by Ethernet or a fieldbus alone. Standard process data and safety data can therefore coexist on the same infrastructure while remaining logically separated according to their different integrity requirements.

Integration between a standard PLC and a safety PLC requires a clearly defined boundary. The safety PLC determines safety permission and safety-related states, while the standard PLC manages production sequencing and normal equipment coordination. Safety status may be provided to the standard PLC so that production logic can react appropriately, but ordinary PLC commands should not be capable of bypassing or overriding an active safety demand.

Robot integration commonly requires coordination between the safety PLC and safety functions embedded in the robot controller. Emergency stops, protective stops, guard conditions, enabling devices, and safety zones can be exchanged through hardwired safety interfaces or certified safety communication. The robot controller then performs the corresponding safety-rated motion response while the standard PLC handles non-safety commands such as program selection, cycle requests, and production handshakes.

Safety laser scanners are particularly important for mobile robots and flexible manufacturing cells. They can define protective fields around hazardous equipment and generate safety outputs when a person or obstacle enters a monitored region. A safety PLC may combine scanner states with machine operating modes, speed conditions, or zone information to determine the required response, provided that the complete implementation satisfies the intended safety function and validation requirements.

AMR integration introduces additional challenges because the hazardous system itself can move through the environment. Safety functions may involve emergency stops, safety scanners, bumper devices, drive safety functions, and independent motion inhibition. The normal AMR controller may perform localization, navigation, and obstacle avoidance, while the safety control layer provides independently implemented protective functions intended to bring the vehicle to a safe condition when required.

Safety zones can also be coordinated between stationary automation and mobile robots. For example, an AMR approaching a robot cell may exchange ordinary docking and transfer information through the process-control interface, while entry into hazardous areas is governed by separate safety conditions. This separation prevents mission planning, fleet communication, or ordinary PLC handshake logic from becoming an unintended substitute for safety-rated access control.

Diagnostics remain essential because a safety system must detect faults without making troubleshooting unnecessarily difficult. The safety PLC can provide diagnostic states identifying channel discrepancies, device failures, communication faults, activated safety functions, or reset requirements. These diagnostic values may be forwarded to an HMI or supervisory system for maintenance purposes while ensuring that diagnostic communication cannot modify the safety decision itself.

Safety PLC software should be structured so that individual safety functions are clearly identifiable and traceable to safety requirements. Emergency stopping, guard monitoring, speed supervision, zone control, and restart prevention should have defined inputs, logic, outputs, and expected responses. Configuration management is equally important because unauthorized or uncontrolled changes to safety logic can invalidate assumptions established during risk assessment and system validation.

Verification and validation complete the integration process. Engineers must confirm that every safety function responds correctly under normal operation, device activation, wiring faults, communication failures, power transitions, controller restart, and relevant single-fault conditions. The objective is not merely to demonstrate that the safety PLC program executes, but to establish that the complete sensor--logic--actuator safety chain achieves the required risk reduction.

In advanced factory automation and Physical AI systems, safety PLCs provide a deterministic protective layer around increasingly intelligent equipment. AI controllers may perform perception, planning, navigation, or adaptive decision-making, while safety-rated control remains independently responsible for defined protective functions. This architectural separation allows robots, AMRs, and intelligent machines to gain greater autonomy without making probabilistic AI behavior the sole mechanism responsible for personnel safety.

09.04. PLC Fieldbus Selection

Selecting a fieldbus for PLC integration is an architectural decision that affects control performance, device compatibility, diagnostics, safety, maintainability, and future expansion. The communication network must match the behavior of the connected equipment rather than simply provide sufficient raw bandwidth. Sensors, drives, robots, remote I/O, safety devices, and supervisory systems impose different timing and data requirements on the PLC communication architecture.

The first selection criterion is the type of information exchanged between the PLC and field devices. Simple digital sensors may require only a few cyclic bits, while servo drives exchange command values, actual positions, status words, and synchronization information continuously. Robot controllers may combine cyclic handshake data with configuration and diagnostic information. Understanding these traffic characteristics helps determine the required fieldbus capabilities.

Determinism is particularly important when communication participates directly in machine control. A network used only for diagnostics may tolerate variable message latency, whereas synchronized motion control requires predictable update intervals and tightly bounded jitter. The required cycle time should therefore be derived from the control function. Selecting an unnecessarily fast network increases complexity, while insufficient timing performance can compromise machine behavior.

PROFINET is widely used for PLC-centered industrial Ethernet architectures, particularly in automation ecosystems built around compatible controllers, remote I/O, drives, robots, and distributed devices. Its real-time communication capabilities support conventional factory control, while higher-performance configurations can address more demanding synchronized applications. Device integration, diagnostics, engineering tools, and safety extensions should be evaluated together rather than considering network speed alone.

EtherNet/IP uses the Common Industrial Protocol, or CIP, over standard Ethernet and provides a unified object-oriented communication model for industrial devices. Cyclic I/O data can be exchanged through implicit messaging, while explicit messaging supports configuration and diagnostics. EtherNet/IP is frequently selected when PLCs, drives, robots, and other equipment already belong to an ecosystem with strong CIP support, reducing integration and engineering effort.

EtherCAT is particularly effective for applications requiring short communication cycles, low jitter, and synchronization across many distributed nodes. Frames are processed efficiently as they pass through devices, making the technology suitable for servo networks, coordinated motion, high-speed I/O, and robotics. EtherCAT should nevertheless be selected according to actual control requirements because its performance advantages may not provide significant benefits for slower supervisory or process-oriented equipment.

Modbus TCP offers a comparatively simple Ethernet-based communication method using a register-oriented data model. It is commonly supported by industrial devices such as meters, power equipment, gateways, environmental sensors, and auxiliary controllers. Its simplicity can make integration straightforward, but register maps, data representation, polling behavior, timeout handling, and device-specific conventions must be carefully defined to maintain a reliable PLC interface.

IO-Link addresses a different part of the automation architecture. It provides point-to-point communication between an IO-Link master and intelligent sensors or actuators, allowing process values, parameters, identification data, and diagnostics to be exchanged. The master then connects these devices to the higher-level PLC network. IO-Link is therefore complementary to industrial Ethernet fieldbuses rather than a direct replacement for networks coordinating entire machines or robot cells.

Safety requirements also influence fieldbus selection. When safety-related information must be exchanged over a network, an appropriate safety communication mechanism is required. PROFIsafe can operate within PROFINET-based architectures, CIP Safety complements CIP-based networks, and FSoE supports safety communication associated with EtherCAT systems. The complete safety function must be assessed rather than assuming that the underlying industrial Ethernet network itself provides functional safety.

Device compatibility is often more important than theoretical protocol superiority. A factory may already contain PLCs, robot controllers, servo drives, remote I/O modules, safety equipment, and engineering tools optimized for a particular network family. Choosing a fieldbus that is natively supported across these devices can reduce gateways, protocol conversion, configuration effort, troubleshooting complexity, and lifecycle risk while improving access to manufacturer-supported diagnostics.

Topology requirements should be evaluated according to machine layout. Industrial networks may use line, star, tree, or combinations of these structures depending on the protocol and infrastructure. Distributed conveyors, robot cells, AMRs, remote I/O stations, and machine tools can create very different cabling requirements. Switch placement, cable length, connector selection, environmental protection, redundancy, and service access should therefore be considered during network selection.

Diagnostics are critical because communication faults can stop an entire automated process. A suitable fieldbus should provide information about device presence, connection state, configuration errors, communication quality, and device-specific faults. Integration with the PLC engineering environment and HMI can allow maintenance personnel to identify the affected node rapidly. Strong diagnostics frequently deliver more operational value than marginal improvements in nominal network bandwidth.

Engineering workflow is another practical selection factor. Device-description mechanisms such as GSDML for PROFINET and EDS for EtherNet/IP help engineering tools understand connected equipment and its communication parameters. EtherCAT devices similarly provide standardized device information for network configuration. Consistent device descriptions reduce manual mapping and help maintain repeatable configurations when machines are duplicated, modified, commissioned, or serviced.

PLC scan time and fieldbus update time should be considered together. Increasing network speed provides little benefit if application logic executes much more slowly, while a fast control task can be constrained by an inadequately configured communication cycle. Engineers should analyze sensor acquisition, network transport, PLC task execution, output transmission, and actuator response as one end-to-end control path rather than optimizing each component independently.

Robot interfaces usually require moderate amounts of deterministic cyclic data rather than extremely large bandwidth. Commands such as Cycle Request, Program Select, Reset, and parameters travel from the PLC to the robot, while Ready, Busy, Complete, Fault, and diagnostics return from the robot. Network selection should prioritize reliable cyclic exchange, vendor support, clear diagnostics, and integration with the surrounding factory architecture.

Servo motion creates more demanding requirements because multiple axes may need synchronized command and feedback exchange. EtherCAT or appropriately configured real-time industrial Ethernet systems can provide the timing characteristics required for coordinated motion. However, many industrial robots perform their internal servo control within the robot controller, meaning the PLC network only supervises robot operation and does not need to transport individual joint control loops.

AMR integration introduces another boundary between deterministic machine communication and higher-level mobile networking. A stationary PLC may use PROFINET, EtherNet/IP, EtherCAT, or another industrial network inside a machine cell, while the AMR communicates through wireless Ethernet with a fleet system or gateway. At docking and material-transfer points, clearly defined handshake information connects these communication domains without requiring them to use identical protocols.

Gateways can connect otherwise incompatible fieldbus domains, but they should be introduced deliberately. Protocol conversion adds configuration, data mapping, latency, diagnostics, and another potential failure point. A gateway is valuable when legacy equipment or vendor-specific interfaces must be retained, yet a new system should avoid unnecessary protocol diversity when a common network can satisfy the technical and organizational requirements.

Cybersecurity increasingly influences PLC fieldbus architecture because industrial Ethernet connects control equipment to broader networks. Segmentation, managed switches, controlled routing, access management, configuration protection, and monitoring should complement protocol selection. A fieldbus should not be considered secure merely because it operates inside a factory. Connections toward OPC UA, MES, WMS, engineering stations, remote maintenance, and enterprise networks require clearly controlled boundaries.

A practical fieldbus decision therefore balances control timing, topology, device ecosystem, safety requirements, diagnostics, engineering tools, lifecycle support, cybersecurity, and total integration effort. There is no universally superior PLC fieldbus for every application. The appropriate architecture may combine several technologies, using high-performance communication for motion, conventional industrial Ethernet for machine coordination, IO-Link for smart sensors, and OPC UA for higher-level information exchange.

For robotics and Physical AI systems, this layered approach becomes increasingly important. AI computers may use Ethernet for perception, planning, and high-level decision exchange, while PLC and fieldbus networks continue to provide deterministic interaction with drives, robots, sensors, safety systems, and factory equipment. Fieldbus selection should therefore support a clear boundary between intelligent computation and dependable machine control while allowing both domains to cooperate within one automation architecture.

09.05. AMR PLC Handshake Protocol

An AMR--PLC handshake protocol defines the deterministic exchange of commands and status information between an Autonomous Mobile Robot and stationary factory automation. The AMR manages navigation, localization, obstacle avoidance, and mission execution, while the PLC controls machines, conveyors, doors, fixtures, and transfer equipment. The handshake creates a clear operational boundary where these two control domains coordinate physical interaction.

The protocol should be based on explicit state transitions rather than loosely coupled messages. Each participant must know whether a transfer request has been issued, accepted, executed, and completed. Persistent request and acknowledgement states are generally more reliable than short pulses because PLC scan cycles, wireless communication, AMR software tasks, and gateway update periods may operate at different rates.

A typical interaction begins when the AMR approaches a designated workstation or transfer point. The AMR reports its arrival and requests permission to enter or dock. The PLC evaluates machine conditions such as conveyor state, fixture availability, transfer-zone occupancy, and process readiness. Only when these conditions are satisfied does the PLC provide an entry, docking, or transfer permission signal.

Arrival and docking should be treated as different states. Arrival may indicate that the AMR has reached the vicinity of a station, whereas Docked confirms that the vehicle has achieved the position and orientation required for physical interaction. A docking confirmation may depend on localization, mechanical alignment, proximity sensors, charging contacts, fiducial detection, or other station-specific verification mechanisms.

After docking, the PLC and AMR establish whether material transfer can begin. For loading, the PLC may indicate Load Ready after confirming that the material and transfer mechanism are prepared. For unloading, it may provide Unload Permission or an equivalent state. The AMR acknowledges the transfer request before operating onboard conveyors, lifts, rollers, manipulators, or other payload-handling mechanisms.

The transfer sequence should distinguish command acceptance from physical completion. An AMR may acknowledge a transfer request immediately but require several seconds to execute the operation. During this interval, a Transfer Active or Busy state informs the PLC that the transaction remains in progress. Transfer Complete should be asserted only after the AMR has verified that the commanded material movement has actually finished.

The PLC should independently confirm machine-side completion where appropriate. For example, an AMR may report that its onboard conveyor has completed unloading, while the PLC verifies that a pallet or container is detected on the stationary conveyor. Completion of the overall transaction can therefore require agreement between robot-side and machine-side observations rather than relying exclusively on one controller.

A robust handshake normally returns to a defined idle state after completion. Once both sides recognize Transfer Complete, the initiating request can be removed and the corresponding acknowledgement released. The PLC can then issue permission for departure, and the AMR can leave the station. Explicitly returning all transaction signals to their idle conditions prevents the previous cycle from being mistaken for a new request.

Sequence numbers or transaction identifiers can improve reliability when identical missions are repeated. Each new transfer receives an identifier that is echoed in acknowledgements and completion information. After communication loss, controller restart, or AMR reconnection, both sides can determine whether stored data belongs to the current transaction or an earlier operation, reducing the risk of accidentally repeating a physical transfer.

Timeout supervision is essential because neither controller should wait indefinitely for the other. Different stages may require different timeout values for arrival, docking, transfer preparation, physical transfer, acknowledgement, and departure. A timeout should generate a defined fault or recovery state rather than automatically assuming success. Values must reflect realistic mechanical and communication behavior of the installation.

Communication loss requires particularly careful handling because an AMR commonly relies on wireless networking while the PLC may use deterministic wired industrial Ethernet. If connectivity disappears during an active handshake, both systems should preserve enough transaction state to recover consistently. The response may involve stopping the transfer, maintaining the current state, aborting the mission, or requiring controlled operator recovery depending on the process.

Fault information should identify the reason that a transaction cannot continue. Useful categories include AMR fault, docking failure, station not ready, transfer mechanism fault, material detection failure, communication timeout, mission cancellation, and PLC equipment fault. A general Fault signal can stop the sequence immediately, while an associated fault code or diagnostic value provides information required for maintenance and recovery.

Reset and recovery must not cause unintended material movement. Clearing a communication or equipment fault should restore the controllers to a known state but should not automatically repeat a loading or unloading operation. The PLC and AMR should first reconcile their transaction states and determine the actual physical location of the payload before deciding whether to resume, restart, cancel, or manually recover the mission.

The handshake protocol should distinguish ordinary process coordination from functional safety. Signals such as Station Ready, Docked, Load Ready, and Transfer Complete coordinate production but are not automatically safety-rated. Emergency stops, protective fields, safety scanners, safe motion functions, and access to hazardous machine areas require a separate validated safety architecture using appropriate safety devices and safety communication.

This distinction becomes important when an AMR enters a robot cell or automated machine area. The process handshake may indicate that the cell is ready to receive the AMR, while independent safety logic determines whether physical entry is permitted from a personnel-protection perspective. Mission software, wireless communication, or normal PLC logic should not unintentionally become the sole mechanism preventing hazardous movement.

Communication architecture can include several layers. The PLC may communicate with factory equipment through PROFINET, EtherNet/IP, EtherCAT, or another industrial network, while the AMR communicates through wireless Ethernet with a fleet management system. A gateway, edge controller, OPC UA interface, or dedicated integration service can translate information between domains while preserving the defined handshake state machine.

Fleet management should remain separated from station-level deterministic coordination. A fleet manager can assign missions, select robots, optimize traffic, and direct an AMR toward a workstation. Once the AMR reaches the station, the local handshake determines whether docking and transfer may proceed. This division prevents higher-level scheduling decisions from directly commanding machine mechanisms without confirmation of local process conditions.

Data structures should organize handshake information consistently across stations. AMR-to-PLC information can include Robot ID, Arrival, Docked, Transfer Active, Transfer Complete, Fault, and transaction number. PLC-to-AMR information can contain Station Ready, Entry Permission, Transfer Request, Load or Unload mode, Departure Permission, fault information, and transaction acknowledgement. Standardization makes additional stations and AMRs easier to integrate.

The protocol should also support commissioning and diagnostics. HMI or supervisory displays can visualize the current handshake state, active transaction, robot identity, station readiness, timers, and fault codes. Engineers can then determine whether a stopped transfer is waiting for the AMR, PLC, machine, or communication system. State-based diagnostics are considerably more useful than observing isolated Boolean signals without sequence context.

In Physical AI environments, an AMR may use AI-based perception, world models, or adaptive planning to reach and interact with equipment, but the final machine interface still benefits from a deterministic handshake. Intelligent planning determines how the robot accomplishes its mission, while the PLC interface defines when physical transfer is permitted and how completion is confirmed. This separation connects adaptive autonomy with predictable industrial automation.

A well-designed AMR--PLC handshake therefore functions as a formal transaction protocol between mobile and stationary automation. Clear ownership, persistent states, acknowledgements, sequence identification, timeouts, fault handling, recovery rules, diagnostics, and independent safety functions make material transfer repeatable and verifiable. Standardizing these principles provides a scalable foundation for AMR fleets, robot cells, smart factories, and future Physical AI systems.