Earlier this year we spent several weeks commissioning a cell that had a FANUC M-20iD handling a pick-and-place operation, an ABB IRB 6700 doing a weld, and a Siemens S7-1500 PLC coordinating the lot. The FANUC side wanted to talk EtherNet/IP for its I/O signals. The plant's MES expected OPC-UA from the cell controller. The ABB arm published diagnostic data via its own OPC-UA server. All of this had to coexist on the same network switch.
Most protocol selection guides treat OPC-UA and EtherNet/IP as competing answers to the same question. They are not. They were designed to solve different problems, and running both in the same cell is not unusual. What is unusual is understanding the failure modes before you are standing on the floor at 11pm watching a timeout cascade. This post is what we wrote up afterward.
Where These Two Protocols Solve Different Problems
EtherNet/IP is the Common Industrial Protocol (CIP) mapped onto standard Ethernet. ODVA designed it for deterministic I/O exchange between controllers and field devices. Implicit messaging (Class 1) runs at a configurable RPI, the Requested Packet Interval, which can go as low as 1ms on capable hardware. That is why FANUC uses it for robot I/O, conveyor triggers, and part-present signals. The whole point is that you can count on a signal arriving within a bounded time window, every cycle.
OPC-UA is a publish-subscribe and client-server framework designed for information-model-based data exchange. It has built-in security (certificates, signing, encryption), a browseable address space, and supports complex data types. The Unified Architecture part means it is designed to cross the IT/OT boundary cleanly. Subscription publish intervals in real deployments typically run 100ms to 500ms. Some implementations can go lower, but sub-10ms OPC-UA subscriptions require careful server tuning and are still not a substitute for hard real-time I/O.
These two live at different levels of a control hierarchy. EtherNet/IP is at the field level, moving short, time-critical signals between controllers and devices. OPC-UA is at the supervisory level, moving richer, less time-critical data up to MES, historians, and SCADA systems. Problems start when someone asks one protocol to do the other's job.
The First Thing That Breaks: Using OPC-UA for Motion Coordination
In the cell above, an early integration attempt routed the cycle-start handoff from the PLC to the ABB arm through the ABB OPC-UA server. The PLC would write a "ready" node value, the ABB would read it, and start the weld program. In the RobotStudio simulation this worked fine. In the live cell it introduced 80ms to 300ms of jitter on that handoff, depending on network load.
The ABB OPC-UA server was configured with a 100ms minimum publish interval. Even if the PLC wrote the node value immediately, the ABB client would not see the update until the next publish cycle. Add in the fact that the PLC's OPC-UA client polling was also asynchronous, and the timing guarantees were effectively gone. The FANUC arm, which was waiting for the ABB to confirm start before retracting to its home position, was now timing out intermittently.
The fix was straightforward: route that handoff signal through a PLC output coil and a hard-wired I/O connection to the ABB's safety PLC digital input, or use EtherNet/IP implicit messaging between the PLC and the ABB I/O board. OPC-UA stayed in the picture for diagnostic data and production counters, which have no real-time requirements. The lesson: if your cell logic depends on knowing the exact moment a state changes, OPC-UA publish-subscribe is the wrong channel for that signal.
The Second Problem: Authoritative State Gets Muddied
The S7-1500 was acting as both an EtherNet/IP scanner and an OPC-UA server. That combination is common and generally fine, but it creates a subtle data freshness issue. The PLC's EtherNet/IP scanner was reading the FANUC I/O at a 4ms RPI. The OPC-UA server was publishing that I/O data at a 200ms interval to the MES historian.
This meant the MES was always seeing a 200ms-old picture of cell state. For production reporting, that is irrelevant. But the MES at this plant also had a feature that sent production order updates in response to I/O events, specifically a "part rejected" signal. Because the MES was polling via OPC-UA, its response to a rejection event was 200ms to 400ms behind real time, by which point the FANUC arm had already started picking the next part. The result was out-of-order production records that required manual correction.
The real problem was not the protocol latency itself. It was that nobody had explicitly documented the latency chain from I/O event to MES update, so the assumption in the MES logic was that the signal was essentially real-time. Mapping out the full timing chain before writing the MES integration logic would have caught this.
The Protocol Boundary That Works
After working through several of these failures, the configuration that has worked reliably is: EtherNet/IP handles all real-time I/O between the PLC and robot controllers, all conveyor and sensor signals, and all safety interlocks. OPC-UA carries everything going upward to the MES, historian, or any IT-facing system. There is no direct OPC-UA write path that triggers robot motion. The PLC is the sole authority over motion commands, and it gets those commands from its EtherNet/IP connections.
Within this boundary, OPC-UA is excellent for what it was designed for. The address space browsing makes it easy to connect a new historian or analytics tool without custom integration work. The security layer is genuinely useful when the cell network connects to a corporate IT network, which is increasingly common. The information model survives controller firmware updates better than raw register maps do.
Sancho sits at this boundary in an explicit way. The connector layer maintains protocol-appropriate channels for each vendor: the FANUC connector communicates via the FANUC Robot Interface protocol or EtherNet/IP depending on what the signal requires. Supervisory data gets published upstream via OPC-UA or MQTT depending on what the MES or historian expects. The configuration makes these channel assignments explicit, which means a new engineer looking at the cell map can see why a given signal is routed through a given protocol without having to reverse-engineer the integration.
One Thing We Are Not Saying
We are not saying EtherNet/IP is better than OPC-UA, or that you should avoid OPC-UA in industrial settings. The OPC-UA Foundation has done serious work on time-sensitive networking profiles (TSN over OPC-UA, the Field Level Communications initiative) that are bringing OPC-UA capabilities closer to hard real-time. On new installations with compatible hardware, those profiles are worth evaluating.
What we are saying is that in today's installed base, and on the hardware most manufacturing plants have on the floor right now, the two protocols have meaningfully different latency characteristics. The integration mistakes we described are not edge cases; they are predictable consequences of applying a supervisory-layer protocol to a field-level problem. Knowing which layer a signal belongs to before you wire anything saves the kind of debugging that happens at 11pm during first-part runoff.
Read next: Why Mixed-Vendor Workcells Break Down at the Handoff Layer