MES and quality systems
Per-part results, defect classes and reject counts published over OPC UA or MQTT, keyed to the order, lot or serial number your MES already tracks.
Platform integrations
A reject signal your PLC can trust
A verdict that reaches the reject gate after the part has passed is worse than no verdict. We design the handshake, the data feeds and the work-order link as part of every project, on protocols your controls team already supports.
Integration is the job
Why machine vision PLC integration decides whether a project works
Inspection projects rarely fail because the model can't see the defect. They fail at the boundary: a trigger that fires twice on a wobbling part, a result that lands one part late after a line-speed change, a reject gate that nobody confirms actually fired. The model was right; the part still shipped.
We treat integration as engineering with its own specification. Before we build anything, your controls engineer and ours agree a signal list, a timing budget from trigger to reject gate, and what every component does when something fails. That specification is tested at factory acceptance in our lab and again, with forced faults, at site acceptance on your line.
The same discipline applies upstream. Results flow to your MES and historian, alerts become work orders in your CMMS, and users sign in through your own identity provider.
Protocols
Industrial protocols Gatepoint supports
| Protocol | Typical use | Gatepoint role | Notes |
|---|---|---|---|
| Digital I/O | Triggers, reject outputs, stack lights, interlocks | Isolated inputs and outputs on every Gatepoint | The most deterministic path for reject timing |
| EtherNet/IP | Cyclic trigger, result and status data with PLCs on CIP networks | Adapter (I/O device), described by an EDS file | Common in North American plants |
| PROFINET | Cyclic result and status words with PLCs on PROFINET networks | IO-device, described by a GSDML file | Common on European-built machinery |
| Modbus TCP / RTU | Older PLCs, meters, drives and compressors; RTU over RS-485 | Client or server | No built-in security, so we keep it inside the cell's network zone |
| OPC UA | Results, counts, asset states and alarms to SCADA, MES and historians | Server; client for reading line context | Signed and encrypted sessions with certificate-based authentication |
| MQTT with Sparkplug B | Telemetry and events to your broker or unified namespace | Edge node publishing to your broker | Birth and death messages give subscribers reliable state awareness |
| REST and webhooks | CMMS work orders, ticketing and custom applications | Client and server over HTTPS | JSON payloads, documented per integration |
PLC handshakes
Four handshake patterns we use on every line
Most vision-to-PLC problems are timing problems, and these patterns make the timing explicit. Our field note on encoders, handshakes and reject gates goes deeper.
-
Trigger
A photo-eye or a PLC output fires a hardware trigger into the Lensnode, which exposes in sync with its strobe. The PLC passes a part or sequence number with the trigger, so every result is matched to the part that produced it — never just to the next one in line.
-
Encoder tracking
Decision time varies by a few milliseconds; conveyor speed can vary by much more. Results are queued against encoder counts between camera and reject gate, so the right part is rejected after a speed change, a stop or a restart. Tracking lives in the PLC or the Gatepoint, whichever your controls team prefers to maintain.
-
Reject confirmation
A sensor at the gate or reject bin confirms that the rejected part actually left the line. A missing confirmation raises an alarm or stops the line, as agreed, and every confirmation is logged against the reject image in Line View.
-
Heartbeat
The Gatepoint toggles a heartbeat bit and the PLC watches it. If the heartbeat stops — power loss, cable fault, software hang — the PLC moves to a fail state you chose in advance, such as diverting everything, holding for manual inspection or stopping.
Plant systems
MES, historian and CMMS connections
We connect to the systems you already run. None of this requires you to change vendors.
Historians
Condition scores, process values, energy and machine states streamed into your historian beside the tags it already holds, so analysis happens in the tool your engineers know.
CMMS work orders
We connect to CMMS platforms such as IBM Maximo, SAP PM, Fiix, Limble and UpKeep through their APIs. A verified alert opens a work order with the asset, fault, evidence and suggested check, and the closure code flows back to label the alert.
Product names on this page describe compatibility only. They are trademarks of their respective owners, and Perflens is not affiliated with or endorsed by them.
IT systems
Built to pass an IT review
Single sign-on
Perflens Console signs users in with SAML 2.0 or OpenID Connect against your identity provider, and roles map to the groups you already maintain.
Syslog to your SIEM
Device security events, logins and Console audit entries forward over syslog to the SIEM your security operations team already watches.
Defined network zones
Gatepoints sit in a defined OT zone with a documented list of ports and directions. No inbound connection from the internet is ever required.
Time and certificates
Devices synchronize time from your NTP sources, and certificates can be issued from your own PKI where your policy requires it.
Scoping
How a typical integration is scoped
Integration is scoped during the Proof of Value or the deployment proposal, in a workshop with your controls, IT and quality leads. The written specification that comes out of it covers the items below.
- Signal list and I/O map, with an owner for every bit and tag
- Timing budget from trigger to reject gate at maximum line speed
- Fail states for power loss, network loss, camera fault and model fault
- Protocols, tag names and data types for MES, SCADA and historian feeds
- CMMS fields, asset IDs and the rules that turn an alert into a work order
- Network zone, ports, firewall rules and SSO groups, reviewed by your security team
- Changes to your PLC program, who writes them and who approves them
- FAT and SAT test cases, including forced-fault tests
FAQ
Questions we hear often
Do you write the PLC logic?
Either way works. We can write and test the PLC-side handshake in your controller's programming environment, or hand a tested specification to your controls engineer or system integrator and support them while they implement it.
Which PLCs do you work with?
Any controller that speaks EtherNet/IP, PROFINET, Modbus TCP/RTU or OPC UA, or that can read and write discrete I/O. That covers the controllers found in most plants.
Our line has no PLC. Can you still integrate?
Yes. Gatepoint digital I/O can drive a reject mechanism and stack light directly, and machine states can be captured from equipment with no controller at all. See Vision Retrofit and OEE tracking.
Does integration create a path from the internet to our PLCs?
No. Fieldbus traffic stays inside the cell zone, and the only optional external connection is outbound-only remote support that you can switch off. See the Security & Trust Center.
How long does integration take?
It is part of deployment, which typically takes 6–12 weeks per line or site. The specification is written before hardware arrives, so time on site goes into testing rather than discovery.
Bring your controls engineer to the first call
The person who owns your PLC program is the most useful person on a discovery call. We'll sketch the handshake, the fail states and the data feeds together.