OPC-UA and EtherNet/IP PLC Integration for Machine Vision
Connecting AI inspection systems to PLCs via OPC-UA and EtherNet/IP without disrupting existing ladder logic or introducing latency at the reject signal interface.
When you're connecting an AI-powered vision system to an existing PLC-controlled line, the integration question isn't theoretical. It's immediate, and it has a hard deadline: the inference result must reach the PLC before the part arrives at the reject station. Miss that window, and you either let a bad part through or kick a good one. Neither is acceptable on a production floor.
In our experience integrating AI inspection systems with mid-size manufacturers across the US, this timing constraint is where most first deployments stumble. Not because the AI doesn't work. Because the signal path wasn't designed with the physical line in mind.
The Reject Window: Why 80-200ms Is Non-Negotiable
Parts move fast. On a typical conveyor at 0.3 meters per second, a part travels roughly 24 centimeters per second. If your reject station sits 40 centimeters downstream from the camera, you have about 160ms from when the image is captured to when the PLC needs to fire the rejection actuator. Add 20-30ms for camera exposure and image transfer, another 40-80ms for AI inference on an edge GPU, and you're consuming most of that window before the protocol handshake even begins.
That budget is fixed. It doesn't care about your integration architecture preferences. This is why the choice between OPC-UA and EtherNet/IP matters more than most people realize when they're evaluating AI inspection platforms.
Concrete numbers: in deployments we've seen, round-trip latency for a well-tuned EtherNet/IP implicit messaging connection typically runs 2-8ms. A well-configured OPC-UA subscription can achieve 10-50ms under low-load conditions. Under contention, OPC-UA can spike above 100ms. That's the practical difference.
EtherNet/IP for Time-Critical Reject Signals
EtherNet/IP uses two messaging modes: explicit and implicit. Explicit messaging is request-response, similar to Modbus TCP. It's fine for configuration and diagnostics. For reject signals, you want implicit messaging, which establishes a pre-allocated connection and sends data cyclically at a fixed RPI (Requested Packet Interval), typically 2-10ms. The PLC never has to ask. The signal just arrives.
Here's the thing: implicit I/O in EtherNet/IP is designed for exactly this kind of hard real-time use case. Rockwell Allen-Bradley PLCs in particular handle this natively. The vision system publishes its output assembly, the PLC consumes it, and the ladder logic evaluates the bit on every scan cycle.
The challenge is that your AI inference system needs to act as an EtherNet/IP adapter device, which means implementing the CIP object model. Most industrial vision platforms have SDKs for this, but if you're building on top of a general-purpose AI inference framework, you'll need a CIP gateway layer. Open-source options exist, but we've found the most reliable path is purpose-built adapter hardware or a well-tested library like Python's pycomm3 for prototyping, stepping up to a certified adapter for production.
OPC-UA: Better Information, Slower Signals
OPC-UA is architecturally richer than EtherNet/IP. It has a proper information model, security built in (certificates, encrypted sessions), and excellent support for structured data like inspection records, defect classifications, and variant metadata. For everything other than the reject signal, OPC-UA is often the right choice.
The OPC-UA subscription mechanism lets the PLC or SCADA subscribe to nodes and receive change notifications. This works well for aggregate metrics: overall defect rate, inspection counts by shift, active model variant. It's not designed to guarantee sub-10ms response to a single trigger. The publish interval can be set as low as a few milliseconds, but OPC-UA's threading model and TCP connection overhead mean you don't get the deterministic latency of EtherNet/IP implicit I/O.
Fact: using OPC-UA subscriptions for reject signals on lines running above 30 parts per minute is a recipe for intermittent escapes. The latency isn't always a problem. But sometimes it is, and you won't catch it in testing because it's load-dependent.
Our recommendation: use EtherNet/IP implicit messaging for the reject bit, and OPC-UA for everything else. The two protocols can run simultaneously on the same vision system.
Protecting Existing Ladder Logic: Start as Read-Only
Quality engineers on mature production lines have one universal concern: don't break what's working. The ladder logic running the line has been tuned over years. It controls interlocks, safety circuits, production counts, and alarm logic. Introducing a new device that can write to the PLC is a significant change. It needs engineering review, change control documentation, and validation.
The approach we've found works well is to start the vision system as a read-only data source during initial integration and validation. The AI system reads line state from the PLC (part present sensor, conveyor running, recipe active) but does not write anything. The reject signal goes to a separate output module that the PLC reads as an input, not a write from the vision system into the existing logic.
This means adding one input card to the PLC, not modifying existing rungs. It's additive. The original ladder logic is untouched. The new rung reads the vision system input and drives the reject actuator. Quality engineers can validate that rung independently before connecting it to the main control flow.
Simple as that. One new input. One new rung. Validated separately.
Common Integration Mistakes
Polling is the most frequent one. Teams familiar with database architectures or REST APIs default to a polling pattern: the PLC reads the vision system on a timer, every 50ms or 100ms. The problem is that polling creates sampling uncertainty. If a part arrives and is inspected between poll cycles, the result sits in the vision system's register until the next poll. On a 100ms cycle, that's potentially 100ms of added latency on top of everything else. On a fast line, you'll miss reject windows reliably.
Use change-of-state or event-driven notification. EtherNet/IP implicit messaging solves this automatically. For OPC-UA, set the subscription sampling interval to match your line cycle time, and set deadband to 0 so every change triggers a notification.
The second common mistake is signal timing assumptions. Teams map out the reject window on paper and confirm it's achievable. What they don't model is the full jitter distribution. In our tracking of early-stage integrations, inference time varies by roughly 15-25% around the mean, depending on image complexity and GPU load from the active learning pipeline running in background. A 60ms mean with 20% jitter means 72ms in the 95th percentile. If your window is 80ms total, you're fine on average and failing intermittently. Plan for the worst-case inference time, not the average.
Third mistake: deploying OPC-UA without proper certificate management. The first time a certificate expires or a network change invalidates it, the OPC-UA session drops. If you've built your reject signal path over OPC-UA (which you shouldn't, see above), the line goes to fail-safe mode or starts accepting everything. Either way, a production incident.
Change Management: Getting Quality Engineering Buy-In
The integration is half the problem. The other half is the validation process. Quality engineers need to answer: does this new inspection system match or exceed the performance of the prior inspection method? That requires a formal comparison period, usually 2-4 weeks of parallel operation where the AI system logs its results but the existing inspection method drives the reject decision.
Honestly, this is the part that determines whether a deployment succeeds or stalls. A technically sound integration that skips the parallel validation period will face pushback from quality teams, and rightly so. Their ISO certification and customer audit obligations require documented evidence that the new process is validated.
What we've seen work: provide the quality team with a daily comparison report during parallel operation. AI call vs. prior inspection call, per part, with defect images attached. When the agreement rate holds above 98% and the AI catches escapes the prior method missed, the quality team has the data they need to justify the changeover. Without that report, you're asking them to take your word for it.
A Practical Integration Order
Based on integrations we've worked through, this sequence minimizes risk:
- Install the vision system and confirm it can image parts reliably. No PLC connection yet.
- Connect PLC I/O read-only: part-present sensor, conveyor speed, active recipe. OPC-UA works fine here.
- Measure actual inference latency under production load. Confirm it fits within the reject window with margin.
- Wire the reject output to a new PLC input card. Program a new rung, disconnected from the main reject logic.
- Run parallel operation: log AI results, compare to existing inspection, report daily. Minimum 2 weeks.
- After quality engineering sign-off, connect the new rung to the reject actuator. Decommission prior inspection method.
Step 3 is where most projects discover their timing doesn't work as planned. Better to find it then than after step 6.
Protocol Choice Recap
| Use Case | Protocol | Why |
|---|---|---|
| Reject signal (hard real-time) | EtherNet/IP implicit I/O | 2-8ms deterministic latency, cyclic delivery |
| Defect records, inspection metadata | OPC-UA subscriptions | Structured data model, SCADA integration |
| Line state read-back (part present, recipe) | OPC-UA or EtherNet/IP explicit | Not time-critical, either works |
| Shift reports, aggregate metrics | OPC-UA or REST | Latency irrelevant, use what your SCADA prefers |
The goal isn't to pick one protocol. It's to use each protocol for what it's actually good at. Reject the part on time. Record why later.
If you're planning an AI inspection integration and want to talk through the signal timing specifics for your line, reach out to our team. We've worked through this at enough different conveyor speeds and PLC configurations to have an honest read on where the friction points are.
