Skip to main content

Connecting a FANUC Robot to an Allen-Bradley PLC over EtherNet/IP

A FANUC robot connects to an Allen-Bradley PLC over EtherNet/IP by acting as an I/O adapter that the PLC scans at a fixed interval, with safety signals carried separately by a safety controller. UTEC Industrial designs, engineers, machines, fabricates, and installs custom material handling systems for aerospace and heavy industry from its Spokane Valley, WA facility, integrating Allen-Bradley PLC and motion control with in-house CNC machining, heat treating, and stress relief. This article walks through the connection from the plant's side: the messaging types, how the robot is registered in the PLC, how the requested packet interval is chosen, how robot data is buffered and handshaked, and how safety connection timing feeds the cell's stopping-distance calculation. In a heavy-handling system the connection sits at the controls link of the chain, design → engineering → parts machining → fabrication → assembly → weld fatigue → stress relief → drives → controls → tuning → monitoring, where it ties the robot to the conveyors, cars, and positioners that feed it.

How does a FANUC robot exchange data with an Allen-Bradley PLC over EtherNet/IP?​

EtherNet/IP is the Common Industrial Protocol (CIP) carried over standard Ethernet, and it supports three device classes based on network communication capabilities. ODVA, which manages the technology, defines:

  • Scanner Class products, which originate I/O data connections. PLCs, PC-based controls, and robots are all listed as examples.
  • Adapter Class products, which are the targets of real-time I/O connections from a scanner. They cannot send or receive real-time I/O data unless a scanner requests it, and they do not store the parameters needed to set up the connection. ODVA lists robots that send and receive real-time data at the request of PLCs as examples.
  • Messaging Class products, which support explicit messaging and do not send or receive real-time I/O data, such as network configuration and diagnostic tools.

In the handling cell this article describes, an Allen-Bradley ControlLogix or CompactLogix PLC is the scanner and the FANUC robot controller is the adapter. The PLC opens the connection, sets its timing, and owns it; the robot answers. ODVA lists robots among both its scanner and its adapter examples; as engineering reasoning, a robot can act as a scanner of its own I/O devices, such as a gripper valve bank, while being an adapter to the PLC.

The class split has a practical consequence that can catch first-time integrators: because the adapter does not store or originate the parameters needed to establish the connection, the timing and size settings for the robot connection are made in the PLC project, which the scanner uses to open the connection (ODVA PUB00138R8-2024).

What is the difference between implicit and explicit messaging for a robot connection?​

EtherNet/IP supports two kinds of message, I/O (implicit) and explicit, and a robot connection can use both. The third bullet below covers unconnected messaging, one of the two forms of messaging ODVA describes (unconnected and connected):

  • Implicit, or I/O, messaging moves application-specific I/O data at regular intervals. It uses UDP over IP, which has low protocol overhead and makes multicasting to more than one destination possible. The CIP connection mechanism provides timeout mechanisms that can detect data delivery problems. In a robot connection, the robot's command bits, status bits, and register values travel this way.
  • Explicit messaging is request-and-response traffic between two nodes. It uses TCP/IP, which acknowledges every message and reassembles fragmented ones, and is generally used for configuration and diagnostic data. EtherNet/IP also uses TCP/IP explicit messages to set up the implicit connections themselves.
  • Unconnected messaging handles connection setup and infrequent, low-priority explicit messages through each device's Unconnected Message Manager (UCMM).

The rest of this answer is engineering practice. For a handling cell, the rule of thumb is to put anything the sequence depends on every cycle, such as "part gripped," "clear of conveyor," or "cycle start," into implicit I/O, and to reserve explicit messages for occasional reads such as a fault log or a program name. A failure mode to avoid is cycle logic built on explicit message reads, which are not scheduled and can arrive late when the network or the controller is busy (ODVA PUB00138R8-2024).

How is the FANUC robot registered as an adapter in the PLC's I/O configuration?​

On the PLC side, the robot is added to the I/O configuration under the controller's Ethernet port or communication module, with its connection timing and data sizes defined there, because the robot as an adapter does not store those parameters itself. On the robot side, the adapter connection is set up on the robot controller. For R-30iA and R-30iB controllers, the controller-side reference for this setup is FANUC's SYSTEM R-30iA and R-30iB EtherNet/IP Setup and Operations Manual (MAROC77EN01101E Rev G); the values entered on both sides should be taken from that manual and from the robot's actual configuration, not from a previous project.

As engineering reasoning, a failure mode to design out at this step is word and bit mapping drift: when the robot's I/O assignment is changed without updating the PLC's tag map, bits land in the wrong place and a "gripper open" command can arrive as a different signal.

As engineering practice, the robot and PLC teams should keep one signed-off I/O map that lists every word and bit, its direction, and its meaning (ODVA PUB00138R8-2024; FANUC MAROC77EN01101E Rev G-2016).

What requested packet interval should the robot connection use?​

The requested packet interval, or RPI, is the period at which I/O values update; Rockwell Automation describes the RPI value as the rate at which the controller attempts to communicate with the module. On a Logix controller the values update asynchronously to the execution of logic. As engineering reasoning, the RPI is chosen for the application, not as the fastest rate the network allows. Rockwell Automation's guidance is:

  • Set the RPI at 50 percent of the rate at which new data is needed. If the cell logic needs fresh robot status every 80 ms, set the RPI to 40 ms. Because the data is asynchronous to the scan, sampling twice as often, but no faster, ensures the logic has the most current data.
  • Do not set it faster than needed. An RPI faster than the application needs can waste network resources, such as ControlNet schedule bandwidth, network processing time, and CPU processing time.
  • Know the controller's transmission behavior. ControlLogix controllers transmit at the RPI configured for the module, while CompactLogix controllers transmit at powers of 2 ms; an RPI of 100 ms on a CompactLogix actually transfers at 64 ms.

As engineering reasoning, in a heavy-handling cell the robot's status may not need to update faster than the conveyor or car it coordinates with can react, so a moderate RPI can be enough. A worked example: a transfer car's PLC logic runs in a 20 ms periodic task and needs the robot's "clear of car" bit at least once per task execution. Applying the 50 percent guideline gives an RPI of 10 ms. Setting 2 ms instead sends five times as many packets for no gain in the car's response (Rockwell Automation 1756-RM094N-EN-P-2025).

Why must robot I/O be buffered in the PLC program?​

Because the robot's input data arrives asynchronously to the logic scan, an input tag can change partway through a program scan. As engineering reasoning, if the cell logic reads the same robot status bit in several rungs, it can see two different values in one scan and take contradictory actions, such as starting a conveyor index while also latching a "robot in zone" alarm.

Rockwell Automation's design guidance is that if an I/O tag is referenced multiple times, and the application could be impacted if the value changes during a program scan, the I/O value must be buffered:

  • Copy the I/O tag into a buffer tag, or use input parameters, and reference the buffer tag, not the I/O tag, in the code.
  • Use the synchronous copy (CPS) instruction for the copy. While CPS copies data, no I/O updates or other tasks can change the data.
  • Use CPS only where the buffered data is larger than 32 bits, or 4 bytes, and do not overuse it; tasks that try to interrupt a CPS are delayed until it finishes, and overuse can impact controller performance by keeping all other tasks from executing.
  • Where a user-defined structure represents the robot's signals, add logic that copies the I/O data into the structure members.

As engineering reasoning, a robot connection of several words of status bits and registers fits the case this guidance describes, and a related failure mode is writing robot output words from more than one task, which lets a lower-priority task overwrite a command that a higher-priority task has just set (Rockwell Automation 1756-RM094N-EN-P-2025).

How should the PLC-to-robot handshake and cell controls be designed?​

The I/O connection moves bits; the handshake gives them meaning. The rules below are engineering practice, except where a bullet names the Rockwell manual or the CIP connection timeout. In the heavy-handling cells described here, the PLC owns the cell sequence and the robot owns its own motion, so the two exchange commands and confirmations rather than raw motion data. A sound handshake follows a few rules:

  • Command and acknowledge. The PLC sets a request, such as "pick from car," and holds it until the robot acknowledges; the robot clears its acknowledge only after the PLC drops the request. Neither side acts on a single-scan pulse, which can be missed at the RPI.
  • Heartbeat. Each side toggles a bit at a known rate and checks the other's. The CIP connection itself times out if data stops, but a heartbeat also catches a robot program or PLC routine that has stopped running while the connection stays open.
  • Interlocks and permissives. The PLC withholds "enter zone" until the car is stopped and the encoder confirms position, a load cell confirms the expected weight, and part-presence sensors, or machine vision where parts vary, confirm the part is where the robot will grip it.
  • Task placement. In the Rockwell manual, Logix 5000 controller tasks can be configured as continuous, periodic, or event, and a periodic task executes at a constant period; putting the handshake and interlocks in a periodic task gives them a fixed update period that can be matched to the RPI.
  • Drives on the handling side. Robots on tracks and coordinated positioners are covered in the robot track and positioner article. The conveyors, cars, and positioners around the robot run on VFD or servo drives under the same PLC, so their stop and start ramps are part of the same sequence.

UTEC Industrial integrates FANUC robotic cells, including vision, with a FANUC design and engineering partner. As engineering reasoning, a failure mode to avoid is a handshake that relies on edge-triggered bits, which works on the bench and fails intermittently on the plant network when an edge falls between two packets (Rockwell Automation 1756-RM094N-EN-P-2025, Ch. 5 pp. 39 and 41; ODVA PUB00138R8-2024).

Can safety signals travel over the same EtherNet/IP network as the robot I/O?​

Yes, as CIP Safety rather than as ordinary I/O bits. ODVA lists support for functional safety with CIP Safety implemented in devices among EtherNet/IP's features. As engineering reasoning, an emergency stop or gate signal copied into a standard I/O word is not a safety signal, however fast the network.

Safety functions such as the emergency stop and guard interlocks can be realized by safety-related parts of control systems designed to ISO 13849-1:2023, which specifies a methodology and provides related requirements, recommendations and guidance for the design and integration of safety-related parts of control systems that perform safety functions, in high demand and continuous modes of operation.

As engineering reasoning, for a robot cell that means the robot's safety I/O, the cell's gate switches and light curtains, and the stop commands to conveyors and cars are handled on CIP Safety connections or hard-wired safety circuits, while the handshake stays on the standard connection. UTEC Industrial, a Rockwell Automation Recognized System Integrator, builds this standard and safety split into the Allen-Bradley controls of the handling systems it delivers (ODVA PUB00138R8-2024; ISO 13849-1:2023).

How does safety connection timing affect the robot cell's stopping distance?​

Network timing is one term in the cell's stopping time. EtherNet/IP supports functional safety through CIP Safety implemented in devices, and the CIP connection mechanism provides timeout mechanisms that can detect data delivery problems. As engineering reasoning, the time a safety signal takes to cross the network and be acted on adds to the time the sensor, the safety logic, the actuator, and the robot or axis under load take to respond and stop.

The terms to add up, with the source for each, are engineering practice:

  • Sensor response: from the light curtain or scanner manufacturer's data.
  • Network and safety-logic time: from the connection and task settings documented for the cell.
  • Actuator and stopping time: from the drive, brake, and robot manufacturers' data, for the robot or axis carrying the heaviest part the cell handles.

ISO 13855:2024 specifies requirements for positioning and dimensioning safeguards with respect to the approach of the human body or its parts towards hazards, and its approach speeds (walking speed and upper limb movement) are used to derive separation distances. Its scope excludes approaches such as running, jumping or falling, safeguards that can be moved by hand nearer the hazard zone than the separation distance, hazards from emissions, and failure of mechanical parts or gravity falls; it applies to protection of persons 14 years and older, and its separation distances do not apply to safeguards used solely for presence sensing. As engineering reasoning, the separation distance also depends on that overall stopping time, so changing a connection's timing settings to cure nuisance trips changes the stopping time, and the safeguard distance has to be recalculated with the new values (ODVA PUB00138R8-2024; ISO 13855:2024).

Which robot safety standards govern the integrated cell?​

The robot and the cell fall under two parts of one standard. ISO 10218-1:2025 covers safety requirements for the industrial robot itself, as partly completed machinery; ISO 10218-2:2025 covers the safety of the robot application and the robot cell, including integration, commissioning, and operation; the iso.org FAQ for Part 2 says it "complements standards such as ISO/TS 15066", the collaborative-robot technical specification (ISO/TS 15066:2016). In the United States, ANSI/A3 R15.06-2025 is the national adoption of ISO 10218 Parts 1 and 2. The general machinery standards also apply: ISO 12100:2010 specifies principles of risk assessment and risk reduction for machinery design; ISO 13849-1:2023 covers the design and integration of safety-related parts of control systems that perform safety functions, in high demand and continuous modes of operation; and IEC 60204-1:2016+AMD1:2021 applies to the electrical equipment of machines not portable by hand while working.

For the EtherNet/IP connection, the practical effect, as engineering reasoning, is a division of responsibility:

  • The robot manufacturer's documentation covers the robot's own safety functions and interfaces, under Part 1.
  • The integrator's documentation covers how the robot's safety interfaces are connected to the cell's gates, light curtains, conveyors, and cars, under Part 2 and the general standards.
  • The PLC network design, including which signals are standard and which are safety, is part of the cell design the integrator documents.

As engineering reasoning, a failure mode that this division exposes is an interface nobody owns, such as a conveyor stop that the robot integrator assumed the conveyor builder had made safety-rated (ISO 10218-1:2025; ISO 10218-2:2025; ANSI/A3 R15.06-2025; ISO 12100:2010; ISO 13849-1:2023; IEC 60204-1:2016+AMD1:2021).

What goes wrong most often when a FANUC robot is connected to a PLC?​

The faults below are engineering experience, not a sourced survey of how often each occurs, and each is avoidable at design time:

  • RPI set as fast as possible. An RPI faster than the application needs can waste network resources, such as ControlNet schedule bandwidth, network processing time, and CPU processing time.
  • Unbuffered robot data. Reading asynchronous I/O directly in many rungs lets values change mid-scan.
  • Edge-triggered handshakes. Single-scan pulses are missed at the RPI; hold-until-acknowledged logic avoids that.
  • Safety through standard I/O. An e-stop or gate bit in a standard I/O word is not a safety signal; safety data travels as CIP Safety, which EtherNet/IP supports in devices, or on hard-wired safety circuits.
  • A PLC stop treated as isolation. OSHA 29 CFR 1910.147 states that push buttons, selector switches, and other control-circuit-type devices are not energy-isolating devices. For servicing or maintenance the standard covers, where unexpected start up or release of stored energy could cause injury, a robot holding a heavy part must therefore be brought to a safe state and locked out before anyone enters.

As engineering reasoning, several of these faults may show up only under production load, which is a reason to test for them in the factory acceptance test (Rockwell Automation 1756-RM094N-EN-P-2025; ODVA PUB00138R8-2024; OSHA 29 CFR 1910.147-1989).

How is the robot connection tested, tuned, and monitored after startup?​

The connection should be tested as part of the cell, under realistic traffic, and then watched in service. The sequence below is engineering practice; only the controller-capacity limits come from the Rockwell manual:

  • Check controller capacity. Rockwell Automation lists limits for 5580 and 5380 controllers such as up to 255 produced tags, no more than 32 multicast produced tags out of the Ethernet port, up to 255 consumed tags, and a Class 3 connection pool for HMI and message traffic of up to 512 connections, split 256 incoming and 256 outgoing.
  • Load the network. Run the robot, HMI, and any vision or data-collection traffic together, and confirm that no connection faults or safety timeouts occur over a full shift of cycles.
  • Force the failures. Unplug the robot's network cable, stop the robot program, and stop the PLC routine, and confirm that the heartbeat and CIP timeouts put the cell in a safe, stopped state each time.
  • Record the timing. Document the final RPIs and safety connection timing settings, and confirm that the stopping-distance calculation uses them.
  • Monitor in service. Trend connection faults, safety timeouts, handshake timeouts, and cycle times; a rising count of any of them points to network, switch, or cabling problems before they stop production.

As engineering reasoning, monitoring closes the chain: the same data that shows a failing switch or cable also shows when a handling axis or robot cycle has drifted from its commissioned timing (Rockwell Automation 1756-RM094N-EN-P-2025; ODVA PUB00138R8-2024).

Related Articles

References​

  • ODVA PUB00138R8-2024: EtherNet/IP — CIP on Ethernet Technology. ODVA, 2024.
  • FANUC MAROC77EN01101E Rev G-2016: SYSTEM R-30iA and R-30iB EtherNet/IP Setup and Operations Manual. FANUC, 2016.
  • Rockwell Automation 1756-RM094N-EN-P-2025: Logix 5000 Controllers Design Considerations. Rockwell Automation, 2025.
  • ISO 13855:2024: Safety of machinery — Positioning of safeguards with respect to the approach of the human body. ISO, 2024.
  • ISO 10218-1:2025: Robotics — Safety requirements — Part 1: Industrial robots. ISO, 2025.
  • ISO 10218-2:2025: Robotics — Safety requirements — Part 2: Industrial robot applications and robot cells. ISO, 2025.
  • ANSI/A3 R15.06-2025: American National Standard for Industrial Robots and Robot Systems – Safety Requirements. A3/ANSI, 2025.
  • ISO 12100:2010: Safety of machinery — General principles for design — Risk assessment and risk reduction. ISO, 2010.
  • ISO 13849-1:2023: Safety of machinery — Safety-related parts of control systems — Part 1: General principles for design. International Organization for Standardization, 2023.
  • IEC 60204-1:2016+AMD1:2021 CSV (Ed. 6.1): Safety of Machinery -- Electrical Equipment of Machines -- Part 1: General Requirements. International Electrotechnical Commission, 2021.
  • OSHA 29 CFR 1910.147-1989: The Control of Hazardous Energy (Lockout/Tagout). Occupational Safety and Health Administration, 1989.

Ready to Discuss a Material Handling System?​

UTEC Industrial designs, engineers, machines, fabricates, and installs custom material handling systems for heavy industry, from the stress-relieved structure and drives to the Allen-Bradley PLC controls, tuning, and monitoring that run them, at its Spokane Valley, WA facility. Send UTEC the application, loads, and duty cycle to start a system review.

Request a Quote →

Questions? Call (509) 922-1832 or email sales@utec.co

Last updated on