Read smart camera results over OPC UA into your control system

Your PLC wants pass/fail verdicts, part coordinates and class probabilities from a smart camera, and you would rather not maintain a second serial telegram or a block of Modbus registers to carry them. OPC UA solves that in one connection: the vision side runs a server, the control side runs a client, and every result arrives as structured data with a timestamp and a quality flag. This guide walks the server set-up, the prepare-and-start workflow with the standard method names, the latency arithmetic that sizes your publishing interval, and the security policy to run on a plant network. You finish able to choose where the server lives and to decide between OPC UA, hardware I/O or serial for your cycle time.

The decision: results over OPC UA, timing over wire

Use OPC UA when the receiving system already speaks it — most current PLCs, SCADA packages and MES platforms ship a native client — and your inspection runs at about 8 parts per second or slower. One subscription then carries verdicts, measurements, statistics and health for every camera in the cell, and the same address space appears on every compliant vision system, so your client code survives a camera change. Keep part triggering and sub-millisecond pass/fail handshakes on hardware I/O. OPC UA is the control and reporting plane; the wire is the timing plane. For how the rest of a line integration fits around the vision system, pair this with the machine vision PLC integration guide.

What the vision side publishes on port 4840

An OPC UA server exposes an address space the client browses like a file system. For machine vision that space is standardized: the companion specification OPC 40100, OPC UA for Machine Vision, defines a Vision System object with device identity, a configuration list, a recipe list, result management, status variables such as image counters, and result events. Any compliant client sees the same tree on any compliant vision system, which is why the companion specification is worth the hour it takes to read before you write a line of client code.

The transport is opc.tcp on port 4840 by default, so a camera at 192.168.1.50 advertises the endpoint URL opc.tcp://192.168.1.50:4840. Results carry what the inference produced per ROI: class label, probability, timestamp and a quality flag. The same tree carries the status and statistics variables, which is what the vision diagnostics to PLC alarm-mapping guide turns into structured maintenance data.

The result workflow, step by step

1. Save the camera settings that suit the product as a named configuration, and save the inspection task — ROIs, classifier, thresholds — as a named recipe. You create both on the vision side's own interface; the OPC UA client only selects and starts them later.
2. Connect the client: endpoint URL, security policy, message security mode and a user account. On success you can browse the address space and read device information such as name and serial number.
3. Call GetConfigurationList. It returns a ResultCount and one InternalId per configuration — conf_classifier.json in a minimal set-up. Call ActivateConfiguration with the InternalId you want; the ActiveConfiguration node then shows the change.
4. Call GetRecipeListFiltered with IsPrepared = 2, the don't-care value, to list what is stored. PrepareRecipe with the recipe's InternalId makes it the active task. Only one recipe per vision app can be prepared at a time, so call UnprepareRecipe first when switching products.
5. Subscribe to events: point a subscription at the Vision System event notifier and enable the event fields you need. Do this before starting jobs, or the first result passes unseen.
6. Call StartSingleJob once per part. The server answers with a ResultReadyEvent holding every ROI's label and probability. For continuous running, call it from the PLC's part-present pulse; for software-hosted tests, the start an inspection from a custom program guide shows the equivalent from code.

Timing: set the publishing interval from your cycle budget

Worked example, carton line at 60 parts per minute, so T_budget = 1000 ms. Take a 6 MP mono frame, assuming 3072 × 2048 pixels at 8 bits: 3072 × 2048 × 8 = 50.3 Mb. Over GigE at a practical 950 Mb/s, T_transfer = 50.3 / 950 ≈ 53 ms. Add a 5 ms strobed exposure and 30 ms of inference — a fair first number for a small classifier, later replaced by your measured worst-case part — and the result is ready 5 + 53 + 30 = 88 ms after the trigger. With a 100 ms publishing interval the event lands at the PLC within 188 ms worst case, 18.8% of budget; at 2 parts per second the same numbers take 37.6% and still fit.

The rule that follows: keep the worst case under half the cycle budget. Up to 2 parts per second, a 100 ms interval is comfortable. At 3-5 parts per second, shrink the interval to 20-50 ms — ordinary for a server on a dedicated VLAN — which puts worst case near 108-138 ms. Past about 8 parts per second, the 88 ms of capture, transfer and inference alone takes 70% of a 125 ms cycle, so move the pass/fail handshake to hardware I/O and let OPC UA publish traceability asynchronously. Subscribe rather than poll: polling adds a full poll period and risks acting on stale data, while a subscription pushes within one interval of the result being ready.

Where the server lives: sensor, smart camera or vision controller

Two hardware roles cover every set-up. In the sensor role the device runs the inspection itself and OPC UA carries only compact results, so the traffic fits even a Fast Ethernet port. In the smart-camera role the camera streams frames over GigE and the server runs either in the camera's own vision software or on a vision controller beside it. Browse the smart cameras category or its camera finder with that role in mind.

Vision controllers as the server host

A vision controller takes the server role once the cell grows past one camera: it aggregates results from several GigE cameras behind one endpoint, and its built-in channels can drive the lights so trigger and illumination stay inside the same timing domain. Choose by camera count, PoE need and memory headroom for the vision software.

All 3 share: Certification CE, KC. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

Keep illumination on a dedicated strobe controller so the exposure stays short and deterministic. The light controllers category covers the range; a 4-channel, 200 W, 24 V digital box with RS232 such as the LS-CTL-0070 suits a single-camera cell.

Security policy: Basic256Sha256 with SignAndEncrypt

Set the security policy to Basic256Sha256 and the message security mode to SignAndEncrypt, and leave them there. The policy was written for high-security configurations, and PLC vendors' own integration guidance lands on the same pair for secure endpoints. On first connect the two ends exchange certificates — the client trusts the server certificate, the server approves the client certificate — and after that the session is signed and encrypted end to end. Sign in with a dedicated user account for the machine, not a shared administrator login.

If the client refuses to connect after a policy change, the cause is almost always a certificate mismatch or a mode the server does not offer; the Basic256Sha256 SignAndEncrypt client setup walkthrough lists the usual failure points in order.

When OPC UA is the wrong transport

Three cases argue against it. Above roughly 8 parts per second, the publish path costs more latency than a wired handshake — trigger, expose and pass/fail over I/O, then publish results asynchronously for traceability. If the PLC side only speaks Modbus TCP, do not bolt a gateway in between: a vision controller speaks Modbus to the PLC directly, and the register map is simpler than any bridge. When a legacy host expects a fixed serial telegram instead, the fixed-position RS232 telegram pattern stays the answer with the fewest moving parts. And if the deliverable is the image itself — training sets, archives — OPC UA is not the pipe; the camera's own stream or file path is.

Checks before you commit

• Confirm the vision side's server implements OPC 40100 and the methods you plan to call — GetConfigurationList, PrepareRecipe, StartSingleJob — before the hardware ships, not after.
• Measure inference time on your worst-case part and put that number, not the demo number, into the timing math.
• Check the PLC client offers Basic256Sha256 with SignAndEncrypt, and that certificates can pass your VLAN and firewall on port 4840 in both directions.
• For moving parts, prefer a global shutter; a short strobed exposure on a rolling shutter can illuminate the frame row by row.
• Count the concurrent clients you need — line PLC, SCADA, historian — and confirm the server's session limit covers them.
• Agree recipe naming with the controls team before the first recipe is saved; renaming after a PLC references an InternalId breaks the call.

Set the whole chain up in one pass with the vision system configurator, or send us the layout through the quote form and we will check the timing numbers with you. More integration guides sit under the systems topic page.