FANUC Robot to AutomationDirect Productivity PLC: EtherNet/IP UOP I/O, Custom DI/DO, and Turck Safety Block Cell Integration
Connecting a FANUC robot controller to a Productivity2000 P2-550 PLC over EtherNet/IP lets the PLC command the robot (start, stop, reset, home) and read its status (running, faulted, at home) through the standard UOP (User Operator Panel) signal set — no separate hardwired I/O needed between the cell controller and the robot cabinet. The P2-550 has EtherNet/IP built into its onboard port, so no add-on module is required.
This guide covers that basic two-device UOP link first, then extends it to the way most real production cells are actually built: a custom application-specific DI/DO handshake for pick-and-place and conveyor logic beyond what fixed UOP bits can express, a Turck hybrid safety/fieldbus block for door interlocks and sensor I/O, working ladder logic for the conveyor-robot handshake, and a commissioning checklist for the full multi-device cell.
Prerequisites
- FANUC R-30iA/R-30iB (or Plus) controller with the Ethernet/IP software option installed. If it's not present, contact FANUC — it's a licensed option, not free with every controller.
- AutomationDirect P2-550 CPU (Productivity2000), with Productivity Suite software installed on your PC.
- FANUC Ethernet/IP EDS file (optional — the P2-550 doesn't require an EDS import the way Rockwell software does; you configure it directly, covered below).
- Both devices on the same subnet, connected via switch or direct cable (the P2-550's ports are auto MDI/MDI-X, so either cable type works).
- A defined signal list before you start: which UOP bits you actually need. Most cells only use a handful — see the mapping table below.
Part 1: FANUC Controller Setup
Enable Ethernet/IP and check network settings
- On the teach pendant: MENU > SETUP > Host Comm (or equivalent Ethernet setup screen). Confirm the controller has a valid IP address on the same subnet as the P2-550.
- Ping the robot's IP from a PC on the same network to confirm connectivity before going further.
Configure the Ethernet/IP adapter connection
- MENU > I/O > Ethernet/IP.
- Select the connection you want to use (a robot can have more than one EIP adapter connection defined).
- Press F4 – CONFIG.
- Enter the Input and Output sizes you want to exchange. For a standard UOP set, 4 words (8 bytes) each direction is typical and matches the example used throughout this guide — adjust if your application needs more.
- This size must match exactly what you configure on the P2-550 side. A mismatch is the single most common cause of a failed connection.
Configure UOP I/O routing
- MENU > I/O > UOP > IN/OUT > CONFIG.
- Set the following:
- Go to System > Config and set Enable UI Signals to TRUE (this hands UOP control to the network connection instead of requiring hardwired panel signals).
- Return to the Ethernet/IP adapter screen, cursor to ENABLE, and press the (F) softkey to set it TRUE. If you need to change word sizes later, set ENABLE to FALSE first, make your changes, then set it back to TRUE.
- Cold-start the controller if prompted (MENU > Restart Controller > Cold Start) — some Ethernet/IP and UOP settings only take effect after a restart.
Part 2: P2-550 Setup (Productivity Suite)
The P2-550 can act as EtherNet/IP Scanner (initiates the connection — what you want here, since the PLC is the one reading/writing the robot) or Adapter (responds to a scanner). For this setup the P2-550 is the Scanner and the FANUC controller is the Adapter.
Add the EtherNet/IP device
- Open your project in Productivity Suite, go to Setup > Hardware Configuration.
- Add a new EtherNet/IP device (Scanner-side connection) to the configuration.
- Enter the IP address of the FANUC controller.
Configure the Input data (robot → PLC, "T→O" — Target to Originator)
This is the data the P2-550 receives from the robot (UOP outputs: RUN, HOME, fault, etc.).
SettingValue Connection PointSet to match the robot's configured connection number (matches what you set on the FANUC Ethernet/IP CONFIG screen) Size8 bytes (matches the 4-word size configured on the robot) Connection TypeUnicast (or Multicast if you need multiple listeners — Unicast is simpler and covers most single-PLC cells)Configure the Output data (PLC → robot, "O→T" — Originator to Target)
This is the data the P2-550 sends to the robot (UOP inputs: START, HOLD, RESET, etc.).
SettingValue Connection PointMatches the robot's configuration Size8 bytesP2-550-specific gotcha: the Productivity2000 CPU always requires a Run/Idle header on the Output (O→T) data — this adds 4 bytes on top of your actual data size in the Forward Open calculation. If the robot side doesn't have a "Run/Idle header" option to match, you may need to account for this by requesting the connection point size as robot-data + 4 bytes, or you'll get error 0x01/0x0127 – Invalid Originator to Target Size. This is the most common configuration mismatch specific to pairing a P2000 with a non-Rockwell adapter, since Rockwell PLCs handle this automatically and most non-Rockwell integration guides don't mention it.
Configuration data connection point
Most devices, including FANUC, use a fixed-size (often zero-length) Configuration data connection. Leave this at the default unless the robot's documentation specifies otherwise. If the FANUC side rejects the connection with an "Invalid Configuration Application Path" error, try removing the Configuration Connection Point from the Forward Open — there's a checkbox for this in the P2-550's EtherNet/IP device setup.
RPI (Request Packet Interval)
The P2-550 will accept a minimum RPI of 10ms, but it can't actually produce data faster than its ladder scan time — set RPI to something reasonable for your application. 10–50ms is typical for UOP-style handshaking; you don't need sub-10ms for start/stop/status signals.
UOP Signal Mapping Reference
Once the connection is live, use Pack Bits (PLC → robot) and Unpack Bits (robot → PLC) instructions in ladder logic to break the 32-bit words into individual tags. Standard FANUC UOP bit assignments:
BitInput (PLC → Robot)Output (Robot → PLC) 0INITIMSTP (Immediate Stop status) 1CSTOPI (Cycle Stop)CSTO (Cycle Stop status) 2HOLDHOLD (status) 3SFSPD (Safe Speed)SFSPD (status) 4RESETRESET (status) 5STARTRUN (running status) 6HOMEHOME (at home status) 7ENBL (Enable)ENBL (enabled status) 8–15ReservedReserved 16–31User DefinableUser DefinableVerification Checklist
- Ethernet/IP option present and licensed on the FANUC controller
- Robot and P2-550 can ping each other
- Robot UOP configured: Rack 89, Slot 1, Start 1
- "Enable UI Signals" set TRUE on the robot
- Robot Ethernet/IP adapter ENABLE set TRUE, correct connection number selected
- Input/Output sizes match exactly on both sides (account for the 4-byte Run/Idle header on the O→T path)
- P2-550 configured as Scanner, not Adapter, for this connection
- Connection Point values match on both sides
- RPI set to 10ms or higher
- Pack/Unpack Bits logic built in ladder to break out individual UOP signals
Troubleshooting
Connection won't establish at all:
- Check cabling/link lights, confirm same subnet, ping test both directions.
- Confirm the robot's Ethernet/IP ENABLE bit is actually TRUE (not just configured).
"Invalid Originator to Target Size" (0x01/0x0127) or "Invalid Target to Originator Size" (0x01/0x0128):
- Your Input/Output byte sizes don't match between the two devices. Remember the P2-550's Run/Idle header adds 4 bytes to the O→T side — this is the #1 cause of this error when pairing with a P2000.
Connection establishes but data looks wrong:
- Verify Connection Point values match on both sides — a mismatched connection point can connect successfully but hand you the wrong data block.
- Double check word-swap/byte-order settings if values look byte-reversed.
"Owner Conflict" (0x01/0x0106):
- Another scanner (e.g., a second PLC, or a leftover connection from a previous session) already owns this connection point on the robot. Power-cycle the robot controller or wait for the stale connection to time out.
Beyond UOP: Application-Specific Digital I/O for Pick-and-Place and Conveyor Cells
Everything above uses FANUC's standard UOP (User Operator Panel) signal set — INIT, HOLD, START, RESET, HOME, and friends — which is the fastest path to a working start/stop/status link and the right choice if that's all you need. Real production cells usually need more: the PLC has to tell the robot exactly when a part is physically present, whether the destination box is clamped and ready, and whether the conveyor is actually moving, while the robot needs to tell the PLC precisely when it has cleared the conveyor's physical interference zone so the belt is safe to run again. That level of detail doesn't fit the fixed UOP bit layout, so most integrators build a second, application-specific DI/DO block alongside (or instead of) UOP, using the robot's general-purpose digital I/O and a separate pair of EtherNet/IP assembly instances.
This is implicit cyclic I/O, same as UOP, just addressed differently: instead of the fixed Rack 89/Slot 1 UOP mapping, you assign the robot's digital inputs and outputs to two assembly instances — a common working pair is Instance 151 for PLC→Robot (Originator to Target) and Instance 101 for Robot→PLC (Target to Originator), each sized to whatever number of words your signal count needs (4 words / 8 bytes each direction is a typical, comfortable size for a pick-and-place-with-conveyor cell).
Example Signal Set: Pick-and-Place with Conveyor Interlock
The table below is a real working example from a robot-plus-conveyor cell — a box-filling or palletizing-style application — mapped against Productivity Suite array tags. Adapt bit positions to your own application; what matters is the pattern, not the exact bit numbers.
SignalDirectionPLC Array TagPurpose DI[1] Pick ReadyPLC → RobotTo_Robot[0].0PLC confirms a part is detected at the pick nest DI[2] Box ReadyPLC → RobotTo_Robot[0].1PLC confirms the destination box/container is present and clamped DI[3] Conv RunningPLC → RobotTo_Robot[0].2PLC confirms the conveyor motor/VFD is actually active DI[8] Collision ResetPLC → RobotTo_Robot[0].7PLC/HMI pulse to clear a soft collision-detection fault DI[16] Test ModePLC → RobotTo_Robot[1].7Commands the robot into dry-run/zero-speed motion test DI[17] Cycle StartPLC → RobotTo_Robot[2].0Remote cycle start from HMI or a physical Master Start pushbutton DI[18] Cycle StopPLC → RobotTo_Robot[2].1Controlled pause at the end of the current routine DI[19] Fault ResetPLC → RobotTo_Robot[2].2Master reset to clear a robot alarm state DI[20] AbortPLC → RobotTo_Robot[2].3Forces cancellation of the active TP program DO[1] Pick DoneRobot → PLCFrom_Robot[0].0Robot has gripped the part and retracted — PLC advances the conveyor DO[2] Box DoneRobot → PLCFrom_Robot[0].1Robot filled the box/pallet — PLC indexes the out-feed conveyor DO[3] Row DoneRobot → PLCFrom_Robot[0].2Robot finished a row — indexes a separator tray if used DO[8] CollisionRobot → PLCFrom_Robot[0].7Collision detect tripped — PLC sounds an alarm DO[9] VacRobot → PLCFrom_Robot[1].0Vacuum switch feedback from the end effector DO[17] RunningRobot → PLCFrom_Robot[2].0Robot program is currently executing motion DO[18] FaultedRobot → PLCFrom_Robot[2].1Robot controller is in an alarm state — system interlock DO[19] ClearRobot → PLCFrom_Robot[2].2Critical: robot arm has physically exited the conveyor's interference zone DO[20] TP OnRobot → PLCFrom_Robot[2].3Teach pendant enabled — Auto disabled, operator in manual mode DO[21] AutoRobot → PLCFrom_Robot[2].4Mode switch in Auto with teach pendant off DO[22] T1Robot → PLCFrom_Robot[2].5Teach 1 mode active (limited to roughly 250mm/s jog speed) DO[23] T2Robot → PLCFrom_Robot[2].6Teach 2 high-speed manual jog activeNotice DO[19] Clear is marked critical for a reason: it's the single bit a conveyor interlock rung should actually gate on. "Robot Running" isn't the same thing as "robot is out of the conveyor's physical path" — a robot can be between motion commands, paused, or executing a move that doesn't cross into the interference zone. Interlocking the conveyor on the wrong status bit is a common design mistake that either creates nuisance stops (over-cautious) or, worse, lets the belt run while the arm is still in the zone (unsafe) — always confirm with your integrator or programmer exactly which bit the robot program sets and when, rather than assuming "Running" or "Auto" implies "clear."
Scanner Configuration for a Custom DI/DO Connection
The scanner-side setup mirrors the UOP configuration in Part 2 above, with different connection points:
- In Productivity Suite's Hardware Configuration, drag a Generic Client into the workspace rather than relying on an EDS import — FANUC's implicit I/O doesn't require one.
- Set the Target IP Address to the robot controller's address, and give the device a clear name (labeling it something recognizable, like the robot's cell-floor name, saves confusion later when a cell has more than one robot on the network).
- Add an I/O Message (Implicit) connection:
- T→O (Input, Robot to PLC): Connection Point = 101, Type = Byte, Elements = 8, tag = From_Robot
- O→T (Output, PLC to Robot): Connection Point = 151, Type = Byte, Elements = 8, tag = To_Robot
- Config: Connection Point = 100, Size = 0 (a zero-length configuration instance, same pattern as the UOP link above)
- Set the RPI — 20ms is a comfortable default for this kind of handshake I/O; faster than that rarely buys you anything for pushbutton/status-bit signals and just adds network load.
- Compile and transfer to the CPU, then confirm the connection comes up (see the commissioning checklist below) before wiring any of this into production logic.
This custom DI/DO link and the standard UOP link from Part 1/2 aren't mutually exclusive — a robot controller can run both simultaneously as two separate EtherNet/IP connections if your application genuinely needs UOP-level cycle control alongside a richer application-specific handshake. Most cells, though, pick one pattern and stick with it: UOP alone for simple start/stop/home cells, or a custom DI/DO block alone once the application gets complex enough to need part-specific and station-specific signals like the ones above.
Extending the Cell: Adding a Turck Hybrid Safety/Fieldbus Block
Once a conveyor, door guarding, and sensors enter the picture, most cells add a Turck TBIP or TBEN hybrid I/O block — a single fieldbus node that combines standard 24V sensor/actuator I/O with certified safety I/O (SIL3/PLe rated) on one Ethernet-connected device. It joins the network as a second EtherNet/IP Adapter alongside the robot, with the PLC scanning both.
Example Cell Network Layout
DeviceEtherNet/IP RoleExample IPFunction PLC (Productivity2000/3000)Scanner (Master)192.168.20.10Central controller — sequencing, interlocking, conveyor logic FANUC RobotAdapter (Slave)192.168.20.101UOP or custom DI/DO implicit I/O, as configured above Turck Hybrid BlockAdapter (Slave)192.168.20.254Door interlocks (safe inputs), safety cut to robot (safe output), conveyor sensors and VFD control HMI (e.g. C-more/EA9)Client192.168.20.50Operator pushbuttons, manual jog, fault alarms, status displayAll devices share one subnet through a managed industrial Ethernet switch. Keep an IP address map like this one documented and posted at the panel — it's the first thing anyone troubleshooting the cell six months from now (possibly you) will need, and re-deriving it from a live network scan is a needless waste of a service call.
Turck Block Scanner Configuration
Add the Turck block the same way as the robot's Generic Client above, using its own connection points per the specific TBIP/TBEN module's manual — a typical configuration uses T→O (input) at connection point 103 and O→T (output) at connection point 104, sized to match your block's actual channel count (commonly 4 bytes each direction for a modest mixed I/O block). Assign clear tag names — Turck_In[4] and Turck_Out[4] are self-explanatory and keep the ladder logic below readable. If Turck provides an EDS file for your exact block, importing it is usually more reliable than hand-configuring connection points, since it pre-fills the correct sizes and instance numbers for your specific hardware variant.
Wiring: Safety I/O (SIL3/PLe Rated)
- Door 1 safety switch: dual-channel OSSD or dry-contact switch wired to the Turck block's safe inputs (e.g. FDI 0/1).
- Door 2 safety switch: dual-channel switch wired to a second pair of safe inputs (e.g. FDI 2/3).
- Safety cut to the robot: a safe, redundant output (FDO) from the Turck block wired directly into the FANUC controller's dual-channel Safety Fence/External E-Stop input pair (commonly EAS1/EAS11 and EAS2/EAS21 on the CRMA15 connector or equivalent panel board) — this is a hardwired safety-rated connection, not a network signal.
Wiring: Standard I/O (Non-Safety)
- Pick-position photoeye: a 24V DC PNP optical sensor wired to a standard input on the Turck block's M12 port.
- Box-in-position sensor: an inductive proximity sensor wired to a standard input channel.
- Conveyor motor control: a standard output channel switches 24V DC to the VFD's Run Forward terminal, or to a 24V interposing relay if you're driving a motor contactor directly instead of a VFD.
Safety Rule: Hardware vs. Network Interlocks
This is the single most important principle in the entire cell, and it's worth stating as its own rule rather than burying it in a wiring list: door interlocks and any other safety-rated stop function must kill the robot through a hardwired, safety-rated circuit — Turck safe output directly into the FANUC controller's safety input board — never through the EtherNet/IP network connection alone. The PLC's network I/O (UOP bits, custom DI/DO status bits, HMI status displays) can and should reflect door and safety status for sequencing, diagnostics, and operator information, but it must never be the sole mechanism that removes power or motion from the robot when a guard opens. A standard implicit I/O connection has no certified safety rating, can silently drop or delay under network congestion, and provides none of the fault-detection (cross-fault monitoring, discrepancy timing) that a real safety circuit requires. If your process needs a certified safety function — SIL3/PLe or otherwise — it goes through dedicated safety-rated hardware and wiring, full stop, regardless of how convenient it might seem to just flip a network bit instead.
Example Ladder Logic: Conveyor Interlock, Jam Watchdog, and Robot Handshake
The rungs below show a working pattern for tying the conveyor, the robot's custom DI/DO handshake, and the Turck sensors together. Adapt tag names to your own PLC's addressing, but the logic pattern — interlock on the robot's actual "clear" status, watchdog the conveyor for jams, and gate the "part ready" signal on both sensor and safety state — is directly reusable.
// RUNG 1: Conveyor Run Command — interlocked on Robot Clear, gated by part sensor and jam timer Auto_Mode From_Robot.Clear Pick_Done_Trig Part_At_Nest Conveyor_Jam_Tmr.DN --[ ]----------[ ]------------------[ ]--------------[/]-------------[/]------------( Conveyor_Motor_Run ) | | +--[ Conveyor_Motor_Run ]---------------------------------------------------------+ // Conveyor runs (and self-latches) until the Turck photoeye (Part_At_Nest) sees a new // part arrive, provided the robot has confirmed it is CLEAR of the interference zone. // RUNG 2: Jam Watchdog Timer — protects the belt and motor from a stalled/jammed run Conveyor_Motor_Run [ TON: Conveyor_Jam_Tmr ] --[ ]------------------------------------------[ Preset: 6.0 Seconds ] [ Current: Conveyor_Jam_Tmr.ACC ] // If the conveyor runs continuously for 6.0s without a new part reaching the nest, // Conveyor_Jam_Tmr.DN trips and Rung 1 drops the motor — a jam, not normal operation. // RUNG 3: Tell the Robot a Part Is Ready — gated on sensor, conveyor stopped, AND safety Part_At_Nest Conveyor_Motor_Run Doors_Closed_Safe --[ ]---------------[/]-------------------[ ]----------------------------( To_Robot.Pick_Ready ) // Only asserts DI[1] when a part is physically present, the conveyor has actually // stopped, and the safety enclosure is confirmed intact. // RUNG 4: Conveyor Running Feedback to Robot Conveyor_Motor_Run --[ ]-----------------------------------------------------------------( To_Robot.Conv_Running ) // RUNG 5: HMI Remote Cycle Start / Fault Reset HMI_Cycle_Start_PB From_Robot.Auto From_Robot.Faulted --[ ]-------------------[ ]------------------[/]-----------------------( To_Robot.Cycle_Start ) HMI_Fault_Reset_PB --[ ]-------------------------------------------------------------------( To_Robot.Fault_Reset )A few details worth calling out: Rung 1 interlocks on From_Robot.Clear specifically, not a general running or auto status, for the reason covered above. Rung 2's jam timer exists because an un-watchdogged conveyor motor run condition that never gets satisfied (a part jammed short of the sensor, a failed photoeye) will otherwise run the belt and motor indefinitely against a stall — 6.0 seconds is a reasonable starting preset for a short pick-nest run distance, but size it to your actual belt travel time between stations. Rung 3 stacks three conditions specifically so the robot never receives a "part ready" signal based on stale or partial state — sensor, motion, and safety status all have to agree.
Commissioning and Troubleshooting a Multi-Device Cell
Once the robot's UOP or custom DI/DO link, the Turck block, and the HMI are all configured, work through this sequence in order — each step assumes the previous one passed, and skipping ahead when an earlier step is actually broken just relocates where the confusion shows up.
StepTestExpected ResultIf It Fails 1Network ping testFrom the FANUC teach pendant's Host Comm/ping screen, pinging the PLC's IP returns SuccessCheck switch link LEDs, confirm all devices share the same subnet, check cable termination 2EtherNet/IP connection statusThe robot's EIP status screen shows the connection state as RUNNINGRe-verify assembly/connection point numbers and byte sizes match exactly on both ends 3Door safety cutOpening either guard door immediately trips the robot's Fence Open/E-Stop alarm — through the hardware safety circuit, not the networkCheck the Turck safe output's 24V wiring to the robot's safety input terminals (EAS1/EAS11 etc.); verify with the door open and the network link physically disconnected — the safety trip must still work 4Sensor-to-input testInterrupting the pick-position photoeye sets the corresponding bit in the PLC's robot input tag and lights the matching signal on the teach pendant's I/O screenCheck for a byte-order/word-swap mismatch in the generic client configuration, and confirm the sensor's PNP/NPN wiring matches the Turck input channel's expected type 5Robot-output-to-conveyor testManually toggling the robot's "Pick Done" output starts the conveyor; the conveyor stops again once a part reaches the sensorVerify the corresponding From_Robot bit and the jam-timer preset in the PLC ladder logicStep 3 deserves special emphasis: test the safety cut with the network cable physically unplugged from the switch at least once during commissioning. If the door alarm stops working when the network link drops, the safety function is — incorrectly — dependent on the network, and the wiring needs to be corrected before the cell goes into production, not discovered later during a network outage with an operator's hand near the guard opening.
Notes on Connection Budget With a Multi-Device Cell
Adding a Turck block and an HMI to the network means the PLC's connection budget covers more than just the robot link discussed in the base UOP section above — each EtherNet/IP adapter device (robot, Turck block) consumes its own CIP connection slots, and the HMI typically opens a separate client-side connection to read/write PLC tags rather than consuming a scanner-side slot. Recheck your specific Productivity CPU's connection limits against the full device count once you're past a simple two-device robot-and-PLC link, and budget spare capacity for a second robot, a barcode scanner, or another fieldbus block before you're forced to re-architect the network mid-project.
Notes on P2-550 Connection Limits
The Productivity2000 supports up to 4 TCP, 4 EtherNet/IP, and 4 CIP connections total (up to 4 CIP connections per EtherNet/IP device, so up to 16 CIP connections across 4 devices). If you're running multiple robots or other EtherNet/IP devices off the same P2-550, plan your connection budget accordingly — a single robot UOP connection only uses one of these slots.