Change camera settings over OPC UA from your PLC

Half of vision integration is getting results into the PLC. The other half is the opposite: the line changes product, and the PLC must change the camera — exposure, gain, trigger delay, inspection threshold — without stopping the line or hoping the write landed. Done as a raw register write over OPC UA, that change is silent and unconfirmed. Done properly, it is a 30-40 ms confirmed handshake. This guide shows the object to build on the vision side, the PLC sequence to call it, a timing budget you can copy, and the tests that prove a change took before you trust it in production.

A write that returns Good has not changed anything

OPC UA gives you a clean write to any Variable. The service answers with a Good status code, and that code confirms one thing: the message arrived and the attribute was written. It says nothing about what the vision system did with the value, whether the value is legal for the camera, or whether the part in front of the lens was inspected with old, new or half-new settings.

Three failure modes follow when you map camera registers one-to-one:

• No validation. A camera exposure feature has a minimum and a maximum; a PLC that writes past them stalls or errors the acquisition at the worst moment.
• Frame races. An exposure or gain change takes effect at an acquisition boundary. A write that lands mid-part leaves you unsure which setting inspected the part.
• No confirmation. The PLC proceeds on Good status, and a setting that never reached the sensor fails hours later as mystery rejects.

So the decision up front: never expose raw camera features as the PLC-facing interface. Expose a small parameter object on the vision side that validates, applies the whole set, reads the values back and reports Ready only when the sensor confirms them.

The parameter object: Targets, one Apply Method, one State

The object has three kinds of members:

• One writable Target Variable per parameter — exposure in µs, gain, trigger delay in µs, inspection threshold in percent, recipe index. Each carries its unit, minimum and maximum in its definition, so a well-behaved client can clamp before writing.
• One read-only Applied Variable per parameter — what the camera is actually running now.
• One State Variable — Idle, Busy, Ready or Error — plus an ErrorText Variable and a single Apply Method.

OPC UA models state machines as a first-class construct, so build State as a proper state machine rather than a free-text string; a compliant client can then read the current state and see which transitions are allowed.

Apply runs one sequence: validate every Target against the camera's reported limits, wait until acquisition is idle, write the whole set to the camera and runtime, read each value back, and set Ready only when every read-back matches its Target. On any mismatch it sets Error and fills ErrorText. Ready therefore means "the sensor is running these values", not "a message arrived".

Keep one Apply for the whole set. If parameter three of five fails validation, the previous five values must stay in force — apply the set or none of it, and roll back on a partial failure.

Where the OPC UA server runs

For a single-camera station, the inspection runtime on a smart camera hosts the server itself: the parameter object, the results object and the camera sit in one process, and the PLC sees one endpoint.

For a multi-camera cell, run the server on a vision controller: every camera and every inspection program publishes behind one address, and the PLC keeps one connection and one parameter object per cell rather than one per camera.

Before you invent your own layout, check whether your vision software's server implements the machine-vision companion specification. The OPC 40100 series, developed with VDMA and released in 2024, defines a standard information model for vision systems from simple sensors to multi-camera cells: ObjectTypes, VariableTypes and DataTypes for results, parameters and state. The OPC Foundation publishes the current specification on its site. Use its objects where they fit, and add the apply-and-confirm behavior above wherever the standard leaves the effect of a write open — it defines the shape, your code defines the guarantee.

What you need

• A vision side with an OPC UA server: an inspection runtime on a smart camera, or a vision controller hosting the runtime and server for the cell.
• A PLC with an OPC UA client, on a switched 100 Mbps or faster network to the vision side.
• A parameter table: name, unit, minimum, maximum and default for each recipe.
• The machine's handshake plan: the signal that says no part is in view, which is your window to apply.
• Bench time to run the verification cycle below before the line does.

Build the vision side

1. List the parameters. Split them into camera features (exposure µs, gain, trigger delay µs) and algorithm parameters (thresholds, tolerances, recipe index). Fix unit, minimum, maximum and a safe default for each. For how exposure and gain trade against each other once the PLC owns them, the image quality settings guide walks the balance.
2. Define the object. Target and Applied per parameter, State as a state machine, ErrorText, one Apply Method. Mark Target writable and everything else read-only.
3. Expose the limits. Read each camera feature's minimum and maximum once at start-up and publish them as read-only Variables, so the PLC clamps before it writes instead of discovering the limit through an Error.
4. Implement Apply. Validate all Targets, gate on acquisition idle, write the set, read back, compare (exact compares for integer features), then set Ready or Error with ErrorText. A failed member leaves the old set running.
5. Persist and stamp. Save the applied set to non-volatile storage and publish a version and timestamp with it, so a power cycle restores what the PLC last approved. Settings lost after a power cycle are a classic silent failure; the same trap in a different guise is covered in keep camera bitrate settings after power cycle.

Worked example: switching exposure between two part types in a 200 ms handshake

The cell inspects two part types alternately. Part A exposes 2,000 µs, part B exposes 8,000 µs (example application values), and the robot handshake leaves a 200 ms window between parts. The camera is a 60 fps smart camera such as the LS-SMC-0063. The PLC and camera share a switched local network with the OPC UA session already open, and one transaction on that session takes 1-5 ms; plan on 5 ms.

The rule in words: switch time = write + Apply call + frame-boundary wait + confirm read. An exposure change takes effect at the next frame boundary, so the wait is at most one frame period.

The arithmetic: one write service call carries all Targets (5 ms); the Apply Method call does validation and the camera write inside the vision process, where the CPU cost is negligible, but the new exposure waits for the next frame boundary (up to 16.7 ms); the State subscription delivers Ready, or a 5 ms poll catches it (5 ms). Total 31.7 ms — call it 32 ms typical, under 40 ms with poll alignment.

The decision: at 32 ms the switch fits the 200 ms window seven times over, and even a 50 ms window holds it. Set the PLC timeout at three times the measured cycle — 100 ms here — and treat an exceed as Error. The same budget says what is impossible: a change between two consecutive frames of one part needs to complete inside 16.7 ms, which no confirmed OPC UA round trip meets at 60 fps. For that case, load both settings in advance and switch by recipe select inside the runtime, and change recipes over OPC UA only between parts. Note also that 8,000 µs collects 8,000 / 2,000 = 4× the light of 2,000 µs per frame — the image test below checks that.

Wire the PLC side

6. Connect and subscribe. Open an encrypted, authenticated session per your plant's OPC UA security policy, and subscribe to State, ErrorText and every Applied variable with data-change subscriptions.
7. Write the set. Write all Target variables in one write service call — a single transaction, as budgeted above.
8. Call Apply once. Start the 100 ms timeout with the call.
9. Act on State, not on the write result. Ready: log the Applied values and release the part. Timeout or Error: hold the part, write ErrorText into the line log, retry once. A Good status on the write or the Method call proves delivery, never application.

Prove the change took

Run the first three on the bench, the last two on the line:

• Range test. Write each parameter's minimum, its maximum, and one value past the maximum. Expect Ready, Ready, Error — and an acquisition that never stalls.
• Image test. Switch 2,000 µs to 8,000 µs and compare frames: the histogram midpoint moves up with the 4× light ratio. Assert on the camera's brightness metric, not on the runtime's acknowledgment, so you know the sensor took the value.
• Soak test. Toggle between the two recipes 1,000 times across a night of unattended running. Zero stuck-Busy states, zero mismatches between Target and Applied in the log.
• Power-cycle test. Cut power after a switch; the version and timestamp must come back with the applied set.
• Timing test. Log write-to-Ready in the PLC for every switch. The 95th percentile should sit near the 32 ms budget; investigate anything above 40 ms.

Once the pattern works, the vision side can tune itself live too: runtime camera parameter control covers exposure and white balance changes without stopping the pipeline. And when start-up code must rewrite settings into the camera after a restart, camera trigger overlap configuration shows how to check that those startup writes actually landed.

Common mistakes

• Trigger changes at runtime. Changing the trigger source or mode live is the riskiest write of all — a trigger arriving mid-switch can leave acquisition armed for one frame only. If the cell then stops after a single image, work through hardware trigger stops after one frame before blaming the network. Prefer recipe select over live trigger-mode writes.
• Auto-exposure fighting the PLC. If the runtime's auto-exposure stays enabled on a feature the PLC now owns, it re-adapts after every write and undoes the change. Turn auto off on PLC-managed features; auto exposure ROI instability from detection feedback shows how this kind of feedback loop misbehaves.
• Writing under a running runtime. Many runtimes cache camera features and rewrite them at start; a value written straight to the camera can be refused or overwritten after a reconnect — camera feature write-protect errors is that failure's signature. Change settings through the runtime's own interface, which your Apply Method does.
• No error path. A PLC that waits forever on Busy stalls the cell as surely as a wrong exposure. If your cell already gates on a ready signal for first images, hang the parameter handshake off the same gate; smart camera misses first images after load covers that gate.

Results flow the opposite direction on the same session — pass/fail, measurements and coordinates as subscribed Variables — and that companion flow is covered in read smart camera results over OPC UA into your control system. Build the parameter object once and the PLC changes camera settings over OPC UA with the same confidence it reads results. To pick hardware for the server, start from the smart camera and vision controller categories above, browse the systems topic for the surrounding guides, or reach us through the contact page with your cell's handshake timing.