PLC Integration for Vision Systems, Explained
PLC integration is the process of connecting a vision inspection system's output to a programmable logic controller so a detected defect can trigger an automated action on the line. The vision system sends a pass or fail signal, typically over an industrial ethernet protocol; the customer's own integrator usually owns the PLC-side programming that acts on it. Leaving this connection until late in a project is one of the most common causes of a stalled deployment.
Last updated: 29 August 2026
What a PLC Actually Does on a Production Line
A programmable logic controller, or PLC, is the industrial computer that runs a line's automation logic: sequencing machine steps, controlling actuators, and reacting to sensor inputs in real time. A vision inspection system does not replace this controller. It acts as another input to it, providing a pass or fail signal the PLC's existing logic can act on, the same way it already reacts to any other sensor on the line. This is a deliberate design choice, not a limitation: the PLC remains the single source of truth for what the line does, and the vision system stays scoped to producing an accurate signal.
How a Vision System Sends a Signal to a PLC
The vision system's software makes a pass or fail decision, then sends that result to the PLC as a discrete signal or a structured network message, depending on which protocol the plant's automation uses. From the PLC's perspective, this looks like any other input: a defined signal it can read and act on according to logic the automation team already controls.
Common Industrial Ethernet Protocols Used for This
Modbus TCP, EtherNet/IP and PROFINET are the protocols most commonly used to connect a vision system to plant automation, alongside simple discrete digital I/O for straightforward pass or fail signals. Which protocol applies depends entirely on what the existing PLC and network already support; a vision vendor needs to work within the plant's existing standard, not introduce a new one.
Who Owns Which Side of the Integration
A clear division of responsibility avoids most integration problems: the vision vendor is responsible for producing an accurate, timely signal, and the customer's own integrator or automation team is responsible for the PLC-side logic that acts on it. A vendor unwilling to state this division plainly, or unclear about which side they handle, is a signal worth taking seriously during vendor evaluation.
What Happens When a Defect Is Found
Once the PLC receives a fail signal, what happens next is entirely defined by the plant's own automation logic, not by the vision system. Common actions include diverting the part to a reject bin, stopping the line at that station, or logging the event for a supervisor to review. The vision system's job ends at delivering the signal; the response is the automation team's existing logic, configured the same way any other reject action on the line already is.
Common Integration Mistakes
Treating PLC integration as a final step rather than a core part of the project is the most common mistake, since it hides connection problems until the deployment is nearly finished. A second common mistake is assuming the vision vendor will also handle PLC programming, when in most engagements that stays with the customer's own integrator. Confirming both points before a project starts avoids the majority of integration delays.
Testing the Signal Before Going Live
A vision system that produces a technically correct signal can still fail in production if the timing does not match what the PLC expects, such as a signal that arrives too late relative to the part's physical position on the line. Testing the full signal path, from image capture through to the PLC's physical response, under real line speed conditions, catches this class of problem before it causes missed rejects once the system is fully deployed.
What to Ask About Before Committing to a Vendor
Confirming which specific protocol a vendor supports, whether that matches your plant's existing standard, and getting a plain answer on who handles PLC-side programming are the three questions that prevent the most common integration delays. A vendor who cannot answer these specifically for your plant's automation, and instead gives a general answer about supporting "standard protocols," has not yet done the work of understanding your actual setup.
Planning PLC Integration Before a Vision Deployment Starts
Confirming which protocol your plant already uses, and identifying who on your side will own the PLC-side logic, are two of the most useful things to settle before evaluating specific applications like die cast component inspection or sheet metal inspection. A feasibility review covers this alongside your part and defect types. You can request a free feasibility audit to work through it for your line.