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 sorts devices into three classes by what they can do on the network. 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 only and do not exchange real-time I/O data, such as configuration and diagnostic tools.

In a typical handling cell, 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. A robot can also 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 often catches 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 moves two kinds of traffic, and a robot connection normally uses both:

  • Implicit, or I/O, messaging moves application data at regular intervals. It uses UDP over IP, which has low protocol overhead and allows one producer to multicast to many consumers. The CIP connection mechanism supplies timeout detection, so a consumer knows when data stops arriving. 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).

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.

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.

The robot and PLC teams should therefore 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 data is placed on the network for a connection. On a Logix controller, I/O values update at the RPI asynchronously to the execution of logic, so the RPI is chosen for the application, not for the fastest 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, makes sure the logic always has current data.
  • Do not set it faster than needed. An RPI faster than the application requires wastes network 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.

For a heavy-handling cell, the robot's status rarely needs to update faster than the conveyor or car it coordinates with can react, so a moderate RPI is usually right. 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 adds five times the network load 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. 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 to buffer I/O data:

  • Copy the I/O tag into a buffer tag at a defined point, and reference the buffer tag, not the I/O tag, in the rest of 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, so the whole robot status block is taken from one transfer rather than mixed from two.
  • 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, which can hurt controller performance.
  • Where a user-defined structure represents the robot's signals, add logic that copies the I/O data into the structure members.

A robot connection of several words of status bits and registers is exactly the case this guidance is written for. 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. In a heavy-handling cell, the PLC usually 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. Logix 5000 controllers organize code into continuous, periodic, and event tasks; 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. 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. 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; ODVA PUB00138R8-2024).

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

Yes, but only as CIP Safety, not as ordinary I/O bits. EtherNet/IP supports functional safety through CIP Safety implemented in devices, which lets safety data share the physical network with standard data while being produced, checked, and consumed by safety-rated devices. An emergency stop or gate signal copied into a standard I/O word is not a safety signal, however fast the network.

On the Allen-Bradley side, a GuardLogix 5580 or Compact GuardLogix 5380 controller runs the safety functions:

  • Only the safety task can be used for safety functions. There is one safety task per controller, and it is a periodic timed task.
  • Ratings. A GuardLogix 5580 primary controller with a safety partner is rated up to SIL 3 and PL e, Cat. 4; without the partner, it is rated up to SIL 2 and PL d, Cat. 3.
  • Standard data into safety logic. Standard tags can be mapped to safety tags, and their values are copied at the start of the safety task, but changes made inside the safety task are not reflected back to the standard tag. Adding mapped tags can increase scan time.
  • Safety exchange with other devices. Safety-produced values are sent to consuming safety controllers at the end of the safety task scan.

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; Rockwell Automation 1756-RM012J-EN-P-2025).

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

Every CIP Safety connection has a Connection Reaction Time Limit (CRTL), the maximum age of safety packets on that connection. If a valid packet is not received within the CRTL, the connection times out and its data goes to the safe, off state. Rockwell Automation gives the equations:

  • Input CRTL = Input RPI × (Timeout Multiplier + Network Delay Multiplier)
  • Output CRTL = Safety Task Period × (Timeout Multiplier + Network Delay Multiplier − 1)

The defaults are an input RPI of 10 ms, a timeout multiplier of 2, and a network delay multiplier of 200 percent, giving an input CRTL of 10 ms × (2 + 2) = 40 ms. Rockwell Automation states that the timeout multiplier must not be set lower than 2 for any safety connection. The safety task period is set between 2 and 500 ms.

A worked example, with the assumptions stated:

  • Inputs: defaults on the light-curtain input connection; a 20 ms safety task period; defaults on the output connection to the drive or robot safety input.
  • Input CRTL: 10 ms × (2 + 2) = 40 ms
  • Output CRTL: 20 ms × (2 + 2 − 1) = 60 ms
  • Assumption: the other terms of the system reaction time, the sensor, the actuator, and the stopping of the robot or axis under load, come from their manufacturers' data and are added separately.

These network terms add to the overall stopping time used to position the light curtain or scanner; ISO 13855:2024 sets how safeguard distance is calculated from the approach speed of the human body and that stopping time. Raising an RPI or a multiplier to cure nuisance trips therefore moves the guard farther out, and the new CRTL must be used in the safety reaction time calculation (Rockwell Automation 1756-RM012J-EN-P-2025; 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 the industrial robot itself as partly completed machinery; ISO 10218-2:2025 covers the robot application and the robot cell, including integration, commissioning, and operation, and incorporates most of the requirements of ISO/TS 15066:2016, the collaborative-application specification formerly published separately. In the United States, ANSI/A3 R15.06-2025 is the national adoption of ISO 10218-1:2025 and ISO 10218-2:2025. The general machinery standards also apply: ISO 12100:2010 for risk assessment and risk reduction, ISO 13849-1:2023 for the design of safety-related parts of control systems, and IEC 60204-1:2016 for the electrical equipment of the machine.

For the EtherNet/IP connection, the practical effect 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.

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).

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

The recurring faults are predictable and mostly avoidable at design time:

  • RPI set as fast as possible. An RPI faster than the application needs wastes network 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 word is not a safety function; only the safety task can be used for safety functions.
  • Nuisance safety timeouts. For applications with safety I/O, the default CRTL can result in connection loss to the safety I/O modules; when the values are raised, the new CRTL must go into the reaction-time calculation.
  • 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, so a robot holding a heavy part must be brought to a safe state and locked out before anyone enters.

Most of these faults show up only under production load, which is why they belong in the factory acceptance test (Rockwell Automation 1756-RM094N-EN-P-2025; Rockwell Automation 1756-RM012J-EN-P-2025; 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. A practical sequence is:

  • 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, safety task period, and CRTL values, and confirm that the stopping-distance calculation uses them.
  • Monitor in service. Trend connection faults, safety timeouts, handshake time-outs, and cycle times; a rising count of any of them points to network, switch, or cabling problems before they stop production.

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; Rockwell Automation 1756-RM012J-EN-P-2025).

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.
  • Rockwell Automation 1756-RM012J-EN-P-2025: GuardLogix 5580 and Compact GuardLogix 5380 Controllers Safety Reference Manual. 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 (Ed. 6.0): Safety of Machinery -- Electrical Equipment of Machines -- Part 1: General Requirements. International Electrotechnical Commission, 2016.
  • 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